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!
Statistics: Posted by ceasless — 09 Aug 2013, 15:46
]]>
]]>
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
Statistics: Posted by sephult — 09 Aug 2013, 12:33
]]>
]]>
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
Statistics: Posted by ceasless — 08 Aug 2013, 15:34
]]>