Saving and Switching Patterns Problems

[electrofux]

Hi,

i have added a page to save and recall patterns for my compactsequencer template.
For each of the 8 Patterns i save all data from the StepNote (Stepnote.x, Division, Steps) and all the Sliders in a big array each.
Now switching and recalling works fine as long as the Pattern i switch to has a different (currently bigger) step number.

The current test Patterns have a step length of 14 and 16 and when i switch from the shorter to the longer pattern, the longer one is missing the triggers (but not the steps) for the last 2 steps. I really get mad because i stare at the code for two hours now. Simplified, can you see anything weird in this:

setattribute(StepNoteContainer.StepNote,'steps',stepsa); -- this sets the number of steps for the sequence i want to change to and it changes from 14 to 16
sub=subarray(selectedpattern,0,stepsa-1); -- this gets the triggers for the StepNote which are right at the start of the array
StepNoteContainer.StepNote.x=sub;-- this sets the triggers

I monitor all the values until just before the code above is executed. "stepsa" changes from 14 to 16 as expected when i switch the pattern but for whatever reason it only fills the first 14 Steps with triggers. All other steps have the right triggers.

I have made a button which fills the Steps again and then they all get filled nicely

On x:
StepNoteContainer.StepNote.x=subarray(P1,0,stepsa-1); -- P1 has the same values as "selectedpattern" from above.

This is really weird.

[Softcore]

After spending hours with the same problems here is my solution.....

Apparently, when changing more than one attribute of a step object (stepNote, StepSlider, etc etc) in ONE FRAME (i.e. in one script) problems arise....You see, the frame is "faster" than the actual object "switching" its state (not a scientifical explanation but that is what happens)...so when you set the length to a bigger one in a script, and the next line sets new xs, this new line is executed AS IF the object still had the fewer steps.

SOLUTION: USE PAD OBJECTS instead of switch objects.

Why?

PAD objects have a VERY handy function - the "release" function....this can act as a "delay" between scripts....SO...set the pad to a release time something like 0.2 seconds
Make the necessary length change "ON X RiSING from ZERO" (when the pad is first pressed)
Make the steps filling "ON X Falling to ZERO" (when the pad is released, and reaches to zero after 0.2 seconds)

This short delay of time, is enough for all the things to work properly!

You can find MANY such tricks in my CCequencer template.

[electrofux]

Man, you are the Boss

Starting to work now

[electrofux]

Do you also have a solution for quantizing pattern switches or chaining patterns, since then the pattern change is handled internally and not by pressing the Pads?
I am thinking about an onclock script and switching on different 64th pulses. But 1/64 is maybe too slow to work seamlessly.

[analog604]

I've run into this problem too. Just have to wait until the sliders have accepted new values.
What I did is put the contents to the sliders from a variable, then check to see if the two match.
If they don't then script schedule another try on the next frame.
Very messy.

However, the new technique is to replace multisliders with a multi-touch canvas setup to look like them, and then this problem goes away....
of course that creates a whole new set of problems to work out!

[electrofux]

Has 5.02 changed something? Cant check quickly because my templates all use the pad workaround. Would love to make a big drumsequencer with pattern chaining and stuff now that the timing seems to have improved.

[electrofux]

Just got answer from the devs on this problem and he sent me a template where this is actually working!

Can anyone of the guys that have the same problem figure out why this is working?

I am puzzled.

[oldgearguy]

not sure what's supposed to happen (don't have Lemur access during the day), but I notice the vector for both pads only contains 8 elements even though it it setting the number of steps to 10. Is the second pad supposed to have 10 elements?


In your original code, why is the subarray using stepsa-1? That's only 15 steps since that is the length parameter and not the end value. subarray (origArray, 0, 16) returns elements 0-15 of origArray.

[electrofux]

not sure what's supposed to happen (don't have Lemur access during the day), but I notice the vector for both pads only contains 8 elements even though it it setting the number of steps to 10. Is the second pad supposed to have 10 elements?


In your original code, why is the subarray using stepsa-1? That's only 15 steps since that is the length parameter and not the end value. subarray (origArray, 0, 16) returns elements 0-15 of origArray.

Yeah, that was a mistake i allways do. The third parameter is array length not endpoint. But that is not the solution.

The problem i and the other guys, who used different workarounds, had was that whenever we tried to fill in a sequencer object with values and in the same script changed the step count of that object, the new values would be ignored. Thats why we went into using a second script to fill in the values right after the step count has changed (with a little delay either by using pad release or onframe).

But in this simple example it seems to work.

[oldgearguy]

not sure what's supposed to happen (don't have Lemur access during the day), but I notice the vector for both pads only contains 8 elements even though it it setting the number of steps to 10. Is the second pad supposed to have 10 elements?


In your original code, why is the subarray using stepsa-1? That's only 15 steps since that is the length parameter and not the end value. subarray (origArray, 0, 16) returns elements 0-15 of origArray.

Yeah, that was a mistake i allways do. The third parameter is array length not endpoint. But that is not the solution.

The problem i and the other guys, who used different workarounds, had was that whenever we tried to fill in a sequencer object with values and in the same script changed the step count of that object, the new values would be ignored. Thats why we went into using a second script to fill in the values right after the step count has changed (with a little delay either by using pad release or onframe).

But in this simple example it seems to work.

I see what you have said, but as I pointed out - this example does not explicitly set steps 9 and 10. The hardcoded vector is only 8 elements even though the new step length is 10.

In general, I think an earlier post by softcore had the explanation of why some things don't work as expected -- Lemur's concept of executing things on the frame boundary means that a script is parsed, values are filled in, then the script is executed. The object's new state is most likely updated either at the end of the frame or at the start of the next one. So multiple changes to objects may not always appear to work even though the code looks correct. I also believe (haven't sat down to prove it) that system load, number of scripts, etc plays a part in the evaluation process and can affect how objects are updated.