Firmware v0.56

@smrl: Bit-banged emulated ISP to rewrite the fuses and restore the bootloader? wow!

I was in a state of panic. It was all I could think to do! :wink:

the random patch is fun. thanks.

Yeah, I’m definitely noticing significant lagging now, performance-wise. Not even in “extreme” cases. I’m not sure if it’s more due to the notes or the clock. I suppose I could test further. For me, I preferred the possibility of dropped data with increased audio rendering performance. The effect ends up being not unlike Todd’s “jitter” effect on the WTPA; random durations between samples.

By the way, this may be an interesting effect worth pursuing - it’s kind of like a statistical detune. Hard to describe really, it makes the sound blurrier… Maybe it would make a cool new voice.

Anyway, I’m going to try to get a build environment set up under windows so I can change this back… I’ll let you know my progress.

Also, your code is easy to follow, and github is a great way to see what you’re up to! Thanks for the good style!

Here’s what I changed… When the CPU does not render audio, it scans buttons, displays stuff on screen, etc. (all those are “Tasks” in the main file). One of this Task is dedicated to MIDI processing.

Before the modification, the MIDI processing task only processed one byte of incoming data at a time, so it was like “render some audio, parse one byte of MIDI, render some audio, parse one byte of MIDI”, which means dropped bytes if the rate of entry in the MIDI task is slower than the rate of incoming MIDI data.

After the modification, the MIDI processing task processes all the incoming buffer, so it’s more like “render some audio, process everything received on the MIDI input while the audio was rendering, render some audio, process everything received on the MIDI input”. This would be the “right” solution (and a better choice lantecy-wise) if processing some MIDI messages wasn’t be so expensive. For example, if a bunch of notes quickly accumulate in the buffer while some audio is being rendered, they will all be processed in one single pass which can take more time than it takes to flush the audio buffer!

The change involved replacing a if by a while ; now the MIDI tasks really flush the incoming MIDI buffer: while (midi_io.readable()) { … }

I perfectly know what you mean by the buffer underrun effect - you should see the “!” on screen when it happens. I haven’t observed much of it while fooling around, but I’ll try to reproduce the problem tonight, with more heavy patches.

I see that “!” alot. I also get a squiggly horizontal line. I can consistently freeze up shruti by turning a knob on my micron. I’ll look into what midi data is being sent by the micron.

I’ll do more tests on my side but it looks like it’s something that will have to be reverted!

The squiggly line is when modulation wheel messages are received

I can control the sub osc level with one of the encoders on the micron. I can make it go from 0 to…right now the display reads 122. If I turn shruti’s sub osc encoder down to zero then turn it back to max 63 the sub osc level is lower in volume than it was when the lcd displayed 122. I just moved the micron encoder again and now I see a sub osc level of 232, but the volume is about the same as when it read 122. So it seems like the micron encoder can make the sub osc level louder than the shruti encoder, but beyond a certain point the numbers displayed on the lcd don’t correspond with the actual volume.

Another encoder is controlling another aspect of the shruti sound, but I have not figured out which one yet. It does change the timbre of the sound though.

I got some pretty cool sounds and was able to tweek knobs for a while before a freeze. anyway I’ll keep messing around…

Ok, so it looks like the micron is sending NRPNs, which explains why you get so weird results (including crashes) - because the implementation of NRPNs on the Shruti-1 is NOT hardened in any way - it’s directly poking bytes in memory, with all kind of fuck ups possible by writing out of range values. One option is to disable sending NRPN on the Micron (if possible) on your side to avoid this situation. Another option would be to harden the NRPN reception on my side so out of bounds values are checked. I’ll try to implement this and see how it goes… It’s not that I can’t do it, it’s easy indeed because the range of each parameter is stored in a table for the editor, it’s just that it’s likely to make the code too big :frowning:

There is no way to disable sending NRPN on the micron, but I can command my hands to not turn the knobs which is probably the easiest solution. It is not a problem, don’t worry about changing the code, especially if it is going to make it bigger.