Order not working ?

[gentleclockdivider]

Something weird going on .
First order module , left outlet goes into value 1 ( which goes into pattern multiply port ) , right outlet goes into value 0 ( for selecting pattern nr 1 ) .
So , the speed is set first , then the pattern.
But when triggering the different strings , the multiply is ignored is kept the value of the previous trigger .
I reversed the order , but somehow it still keeps the muliply value of the last triggered pattern .
Here's the file
https://app.box.com/s/3ppkvmub5orq7qcm6tqqjqug250sfk43

[gentleclockdivider]

It's abit more clear in this example
I used the triggered row .
NOtice how pattern 1 still has the trigger array from pattern 2 .
It automatically retriggers the array( from the previous pattern ) when the sequencer reaches a new bar .
Here's the new file
https://app.box.com/s/e8m02eijhrtaoowj10a8vanljzsp106q

[gentleclockdivider]

Even happens without order module and using top bottom approach .
Set-up events is turned off for all modules , still changes occur on bar changes (faulty gate array)
First pattern 2 is triggered , then pattern 1
The print module clearly shows that the correct gate array is triggered when pattern 1 is excuted [0,1,0,1,etc...
BUt the pattern still has the gate array of pattern 2
Just press play and execute the "patterns"data modules (top of structure) and observe the wrong gate array when sequencer reaches new bar
https://app.box.com/s/limwxor7924ofq839f7rdugslqw1hzvu

[colin@loomer]

I've downloaded your patch and am on the case...

[gentleclockdivider]

Any news about the issue ?

[colin@loomer]

Sorry, just been travelling and have had sketchy internet. I'll get back to you regarding this later this afternoon.

[colin@loomer]

OK, I've got to grips with your preset. Can I just clarify the behaviour I am seeing, and what you expect to be seeing.

Starting from the initial state of the newly-opened "Order bug 3" preset, I click on "pattern 2", which does two things:
- Invokes the `[data]` module with the array of '1, 1, 1, 1, 1, ...`, which then sets the trigger row on the current write-selected pattern. By default, this is pattern 0, and so pattern 0's trigger row is updated
- the `[data]` module with value of `1` is invoked, which sets the current pattern 1

Then I click "pattern 1", which:
- Invokes the `[data]` module with the array of '0, 1, 0, 1, 0, ...`. This sets the trigger row on the current write-selected pattern, (which is now `1`), and so pattern 1's trigger row is updated
- Then, the `[data]` module with value of `0` is invoked, which sets the current pattern to 0

[gentleclockdivider]

Not entirely .
Make sure the pattern gui is focussed ( so yo can see the gate errors ).
-press play on the transport bar ( important )
-Invoke pattern 2 ( pattern 2 + gate data for pattern 2 is executed correctly )
-Invoke pattern 1 ( pattern 1+gate data for pattern 1 is applied )
Let the sequencer play , without invoking anything..after a few beats (sometimes instantly) the gate data for pattern 2 is automatically applied without invoking anything , or it could well be that the gate data for pattern 2 is still in memory .
The gate data is wrong , it should be that of pattern 1 [0,1,0,1,etcc] , instead of [1,1,1,1,etc..] , the console clearly shows that the correct info is send but it's not .
Just alternate click between pattern 1 and 2 ( while transport runs ) and look at the gate lanes , they don't match with the executed ones .

[gentleclockdivider]

Perhaps this example will make it more obvious ( I used velocity row instead of gate row)
Pattern 1(red box ) has uprising notes with increasing velocity from 10-80
Pattern 2 , same notes all with the same velocity value of 50
-Press play on transport bar and trigger pattern 1 (from the data box) .
-Let it play a few bars
-Now trigger pattern 2
When a new bar is reached , the invoked pattern will execute but the velocity data is that of the previous pattern
The result is obvious , the velocity data does not match up with the pattern but the console clearly shows that pattern index + velocity row are correctly send .
Doesn't matter if order module is used or not .
https://app.box.com/s/g375xmlb0fyimvq3gm96iaibqd0pfviu

[colin@loomer]

OK, yes, I think I see. Let me have a play with what you've uploaded and I'll report back.

[colin@loomer]

Progress, in the sense of I've seen what you've described happening. I believe it's something to do with the quantization of when pattern changes occur for reading and writing. Coincidentally, I think someone else has just approached me with what I now believe to be the same issue. I'm on it.

[colin@loomer]

What you are seeing is due to the fact that pattern changes are quantized. When you send a pattern index to the "play pattern index" on any playing sequencer, it doesn't immediately change the pattern: it queues the change to occur at some later time (such as the end of a bar) in synchronization with the main clock.

So even though you've requested the pattern change, it hasn't actually occured when you then try to write to the row data. But there is a solution: you can write to patterns other than the currently playing one by sending an event to the "write pattern index" inlet. By doing this, the sequencer will redirect writes to the "correct" pattern, even though the playing pattern hasn't yet changed.

To summarise: connect the `0` and `1` to both "play pattern index" and "write pattern index".