DSP Robotics Support

Sorry to start a separate thread for this question, but I've not found anything similar that I could tag onto.

I'm have a dilemma to solve [what new] ...

I've been working on a controller that links to a heavy taxing 'sampler' ... I can send single PRGCHNG commands [manually] without issue [sans for the steaming audio to have a few hiccups] but generally all settles down. fine.

I've now added a Preset Manager that can make all changes ... that works ... except, I'm now addressing several 'samplers', and putting out PRGCHNG commands is hitting all of them simultaneously. The CPU load is off the charts

I've just started using this PM idea, but now I have to look at a possible solution to make having it .... useful.

Is it possible to, maybe, stagger or stack delay the sending of certain parameters ???

If I could control the execution, I'd think, 1st ... send one PRGCHNG followed by it's User settings ... then the next PRGCH with its settings, next , next till they all are fulfilled.

Just thinking out loud on this, with no clear idea if something could be done for this.

Any insights are very much appreciated !! I'm also thinking of a 'Plan B' scenario that might be somewhat useful ... or render the entire PM function to lame to be of any use

Thanks for any consoling or words of advice as I try to formulate [or salvage] a solution.

Hi RJ,
Oddly enough I'm working on a similar problem at the moment - I have a new FX stomper for my bass, all SysEx programmable, but no handshaking and only a small buffer on the hardware - so I made a small MIDI 'buffer' unit for my controller's output so the messages don't get sent too quick
Whether it would work for you will depend on your setup - it has everything going via a single MIDI out ATM, so it might need some mods if you need to send on multiple outputs.


Since Ruby arrays can contain items of different types (including sub-arrays containing many values), you could potentially mix MIDI events with other kinds of data and then sort them at the output.

Oddly enough I'm working on a similar problem at the moment - I have a new FX stomper for my bass

Well ... drummers - bass players -synchronicity

I will definitely be looking at this when I return from my gig tonite !

With my project design, I've tried to maintain a modular approach ... so each controller 'section' has its own MIDI OUT ... these all get linked down the line, to finally a SINGLE MidiOUT for the plugin.

I'm early at suss'ing out this new issue, as I've just recently put the PM into use [1st time]. All the knobs, buttons, sliders, and menu are updating just fine ... its the changing of the actual sample presets [some which go through a real-time 'sample rate' conversion], that is killing the system when the full package changes

... early in the diagnoses

Well, as I had some troubleshooting time ... I think I have corrected the issue when the PM was recalling a bank of presets.

It seemed that I had some double triggers going on. I know that a couple GURU's here have made us aware of the potential issue they can cause, and it looks like I've tracked down the culprit.

I don't nearly have enough understanding how the particulars of the PM actually work ... especially the 'firing order' of a preset recall. There also seems to be few primitives that offer ways to actually analyze, let alone, intervene. Just trying to look at the data, via a text prim, was off limits.

Maybe all for the best, as it had me tweak the schematic for a leaner execution. [nothing wrong with that]

Happy that the PM system is looking to stay a feature, as this may prove useful to a user for favorite combinations, or as my intent, as an A:B comparison function ... yeah

Now to continue testing to be sure I didn't break something in the process