Firmware v0.56

Anybody interested in testing this?

Download:
http://mutable-instruments.net/static/firmware/

New stuff:

  • A new “Panic” feature has been added in case things go really wrong. It clears the note stack, shuts down all the envelopes, and resets the LCD.
  • While in the load/save page, a long press on the first button resets the current patch to the simple startup sound.
  • While in the load/save page, a long press on the second button sets the patch parameters to random values.

Here’s a summary of all the functions accessible by a long press:

  • A click/pop occurring in some cases when the sequencer stops counting steps has been fixed (it was a rare envelope bug).
  • The swing feature goes away and is replaced by a “groove pattern” feature. 5 groove patterns are available, each of them with 16 levels (from 0 to 15). The groove patterns are: *s*wing (ternary feeling), shu*f*fle (imbalance in the division of a 1/8th note), *p*ush (plays steps 0/4/8/12 ahead of time), *l*ag (plays some steps late and then catch up), and *h*uman (slight or not so slight randomization of step durations, but the 0/4/8/12 steps are still quite solid). The original swing feature is still covered by the settings s0 to s15 - you’re just losing resolution.
  • The MIDI messages are now processed more greedily. This makes the situation where the Shruti-1 drops MIDI bytes more unlikely ; at the risk of small glitches or discontinuities in audio playback (the ‘!’ of doom).

i will test it tomorow … time to sleep now :slight_smile:

Happy to do it tomorrow as well. Thanks for being so active.

Yes! And just in time for my show tomorrow. I’ll be using the arpeggiator a lot I think, so this should be good to experiment with!

thanks for running with the groove idea… Can’t wait to hear it

@smrl: you might want to do a bit of testing before your show, because the “greedy” MIDI handling is likely to matter a lot in your case. This is a whole new different trade-off between MIDI glitchiness and audio glitchiness.

I will test it toooonighhht :smiley:

great news patch reset is a great idea! so I don’t have to switch on/off every time I want to start from scratch!

AHHHHHHHHHHH!

OK, so I accidentally interrupted the MIDI update. Took down the whole synth in the process. So I removed the ATMega328, plugged it into an Arduino, and hooked up a Bus Pirate with the STK500mk2 firmware installed to the ISP header. Flashed via AVRDude. Wrote to/read from the chip and claimed success. Put it back in place, and it boots up fine, everything appears correct (it’s definitely V0.56 as displayed when it starts up). But MIDI no longer works! I’ve tried sending MIDI from my BCR-2000, and I’ve tried sending MIDI from my Motu MTP-AV.

Nothing’s going on! Nothing is displayed in the upper left corner of the screen. I double-checked MIDI channel assignment, and set it to “0” which should be rcv all channels.
The test note works… but nothing via MIDI.

Another weird quirk: I tried to downgrade via MIDI, and I go into the “ready for OS update” screen, and the display starts getting glitchy characters… before I even try to send MIDI. Of course, it’s not taking MIDI upgrades either. Could I have broken something while fiddling, or could this be some strange bug?

Also, my jumper is definitely in the right spot.

@smrl: a failure during the MIDI update should not cause any problem, because it’ll only screw up the firmware, not the bootloader! If something goes wrong during a MIDI update, you can restart the synth while pressing the load/save key and still enter the MIDI loader mode by pressing the load/save button while powering it on.

So now, why your chip is in this state? What I suspect is that you deleted the bootloader when flashing the firmware through ISP. A good test to check that is to put the chip on an Arduino and try using it from the Arduino environment… If you can’t upload sketches, the bootloader has been erased. It matters because some serial port initialization is done from the bootloader - which might explain why MIDI is not working.

Another test: what happens when you hold the load/save button pressed while powering up the Shruti-1? If nothing specials happen, it’s booting straight into the firmware and the bootloader has been erased. It should instead go into MIDI update mode…

The fix:

  1. Put the chip on an arduino.
  2. Write the bootloader using the ISP connector (make -f hardware/bootloader/makefile upload). You don’t need the ISP anymore.
  3. Write the firmware through STK500 (make upload in the makefile) ; or put the chip back on the Shruti-1 and do a MIDI update.

OK, right you are. I’ve got no more bootloader! It boots right into the synth with the save/load button held down.

I will try your fix! Thanks for the quick reply!

The improvements sound excellent Olivier - I’m away from home for a couple of days on business, but when I return I will try it all out Thank you for the frequent and impressive updates

Okay… I don’t know if this is going to work. I can’t seem to build it. It’s complaining that I don’t have a depends.mk.

Also I’m sure I’ll have to edit the makefile to point it to a different directory with avr tools. Is there a proper version of these tools that I should be working with? Do I have to duplicate what CrossPack uses?

I’m not on OSX, I’ve got windows or various builds of linux over here. Trying to do this in Ubuntu as I don’t even know where to begin trying to build stuff under windows without cygwin and a huge headache.

Otherwise, is there a way you can compile it and send it to me?

The pre-built bootloader hex is here:
http://mutable-instruments.net/static/firmware/muboot_0.54.hex
(it hasn’t changed since 0.54)

What you have to figure out from the makefile are the command line flags for avrdude

I’m sending the file with 9 and 11 lit and when I hit play 12 lights up a blinks rappidy upon recieving signal. When the file is done being sent, Shruti-1 returns to boot-up stage and shows v0.55. I never got a progress cycle. I’m using SysEx Librarian on osx.5.8. Used same setup for .55b version.

Wow. You saved my life (or at least my evening) there! NOT as easy as I thought. I was having difficulty with the bus pirate, so I ended up following instructions here

http://www.geocities.jp/arduino_diecimila/bootloader/index_en.html

and built an interface to burn the bootloader by bit-banging using the serial chip on the arduino! Fuses were set to the following:

Hfuse: DA
Lfuse: FF
Efuse: 00 (should this be 05?)
Lock: 0F to burn the bootloader, 3F after to lock.

Nevermind, I sent it through m-audio FireWire 410 the first time. Now I’m sending it through the 25-sl and get progress. Only now, when I finish sending update it seems the Shruti wants more. It stays lit except for lights 9 and 10. I’ll power it down and try again.

All good. Sorry to interrupt.

And for what it’s worth, I’m getting some !'s when I’m sending heavy heavy MIDI, but it’s practically in the audio modulation range at that point :wink: I wouldn’t really know what it SHOULD sound like…

So I’d say audio engine performance is not going to be an issue, but I’ll let you know how it goes for me as I get a little further into my work today…

After an hour of messing around with all the features (panic, init/random, swing), I have found no glaring issues. I’ll continue to play around during the course of the day.
Nice work on that patch randomizer!