Feature idea / patch nrpn snapshots


I’m building editor for Shruthi-1 using Max and currently TouchOSC (iPad). It uses nrpn’s to transfer parameter data in both directions. There is a one problem in this case: I cannot detect when patch is changed in Shruthi-1 or get data for new controller button and knob positions if patch is changed in Shruthi-1.

To make this this work it would be nice if there is couple of new features in some version of future firmware:

  • Request nrpn dump from Shruthi-1. This would be a maybe some sysex command, but Shruthi-1 would return a snapshot of current patch using nrpn’s. I believe there is a kind of alternative to this in current version, but reading sysex dump is a bit painful in Max and in any software without proper documentation of its contents.

  • In addition to previous one there might be an option in firmware to send program change messages, when patch is changed. Program change option would be useful in many other cases too.

These are of course only my considerations, but if this sounds reasonable maybe you could think about these…


OK to add:

  • a SysEx command to request a patch dump.
  • some code to systematically dump the patch when it is “touched” (eg after a load).

I don’t think a NRPN dump would be a good idea. While I have recently unearthed an optimization to yield 500 bytes of code, I’d rather fill those with some new features.The SysEx data is just the patch data packed into nibbles. The patch data is documented here . Let me know if you need some help.

Thank you this quick answer!

Header file looks pretty easy to read. I assume data structure which starts from line 91 contains relevant order and structure for sysex handling. Next I’ll create a simple parser patch in Max maybe utilizing javascript.


Best wishes with your project Oskari - I’m kind of working on the same thing here.

Because not all software hosts handle SysEx I’m trying to create a patch editor / extender scheme and front panel using Plogue’s Bidule. The front panel is working and allows e.g. the entire mod matrix to be visible for quick patch hacking, as well as (hopefully) assigning hardware knobs to Shruthi params via learn, but the patch saving scheme (implemented via Bidule’s presets) isn’t finished. Neither have I implemented receiving NRPNs from the Shruthi yet - it’s one way only so far. I’m hoping that eventually I can use it as a VST but I’m having two major problems:

1) CPU is already high.

2) Bidule is in (seemingly everlasting) beta and the available gui elements are limited, to say the least. Still, I know Bidule pretty well and it’s more of a proof-of-concept at this stage.

Finally it would be a great help here if my li’l Shruthi sent a Program Change when changing presets.

“Finally it would be a great help here if my li’l Shruthi sent a Program Change when changing presets.”

+1 on that

SysEx command to request a patch dump is now in v0.92.

I am not sure about the “redump the patch as a SysEx block everytime it is loaded” idea. The reason is that it will prevent several Shruthi to be chained in a normal “N mono units listening to a different channel”. The core of the problem: SysEx don’t have a channel number, so if a Shruthi in the chain does a dump, everybody else is going to get it. Good for polychaining, bad for multitimbral chaining.

That’s a very good point.

I just read 0.92 features and new midi program change messages will handle this case without “always send sysex”.

editor would simply do:
if (msgType==pgm) {

If there is a multitimbral chain, that’s still a problem, but when using an editor it is probably not very common case and there is always an option to use different midi ports for each unit. I wonder how this is handled with same kind of setups using another synths, hmm.

Sidetrack: I just tested polychaining with my Shruthies (three units) and it’s quite amazing system :slight_smile: