BrainModular

I'm working on a drum machine patch designed to easily facilitate driving drum VSTs such as Battery and others that lack a sequencing interface of their own. I envision something like Tattoo (which has step sequencers available for modulating almost all of its params). In this version of the patch I am using EXD-80 (a free and interesting drum machine VST) so that anyone can test.

Right now I've been working on getting the 'pattern store' aspect of the patch working. For this part I've written two new scripts, 'Pattern Store' and 'Pass on Change (Array)'.

The good news is that I've managed to add in the pattern recall feature!

The bad news is that I don't know how to make the patterns persist.

How can I store the values in the Pattarn Bank so that they are recalled on next load, rather than reset? (Right now I initialize all values to 0 during the init procedure, if I don't it doesn't work. How/where can I store a three dimensional array that I can then load it back during init?

edited: I should have tried the patch on a more powerful machine, because I don't get the timing issues on my desktop.

Still, I wonder which of the two new scripts, or what aspect of the routing, is causing such a hit (though I never expected much from it for music, it's a pretty low-spec CPU).

For reference, here were the problems I encountered:

- the BPM is reporting at 30 and 120, flashing back and forth between them
- selecting a new pattern does not trigger only on 0 (could be related to above? to replicate quickly be sure to select a new pattern number when steps are very low)
- position bars are not in sync with each other

Also I want to mention that not only will I be sharing the patch and all of the scripts with the community, I will also write a blog series that introduces programming in Usine and how I developed/designed the patch.

You could modify a fastscript to store a configuration text file and read that back.
I have used these for patch-naming storage successfully. There is the default example in the scripts section for read/write.
Instead of placing code within the Process portion of the script you could write a Callback procedure and create an input pin for Load. This way you can specify another time besides just init in which you can bring values back into your scripts. I have found the Callback procedure most useful, keeps from over-burdening the patch and only executes when told to instead of constantly re-iterating.




-S

Are you using step switches for you position bars? I have found some sync issues between...some oddities regarding tying position from 1 and start serial chaining through the other of my sequence steps seems to sync tight....but the first one receiving direct synchro control always seems glitchy

Wow, file I/O for persistent data makes sense in a way but also seems way overkill. I'm thinking I might try a new invisible param that is set to save in presets and then just writing the entire three-dimensional array using setValue. And if it didn't work, then to put it up as a feature request.

In fact the preset option would be even better, because then you could have # of patterns X # of presets..

I agree with you regarding the callback procedure, it definitely helps keep the script relatively simple.

Re: the step switches -- I never had to wire them at all! I just set all their synchros to 'cycle' and they stay in sync (well, on the big computer )

In order to keep the pattern bank informed of when it should switch (as it will only load the new pattern when it starts the sequence over), I built a counter that increments on using the 'next step' of the first sequencer. To keep it in sync with the sequencer (ie so they both start at 0 when 'play' is pressed), I had to add a logical module that fires and resets the counter if the value of the counter is ever higher than the step sequencer. I felt pretty clever when I figured that out.

Then in the Pattern Bank callback, I check 'stepNum' and if it equals 31 then I load the new pattern that was chosen. Since it comes _after_ the sequencer arrives at the last step, it doesn't interfere with the last switch in the sequence, because that has already fired (or not) before the counter increments.

I actually began to post this info in your 'sync issues' thread last night but I wasn't totally sure it applied in your case. I hope it helps!