If these are supposed to work the way I’m interpreting the manual, I think they’re broken … but I’m not sure I understand them right and want to verify before I submit a bug report.
One of the things I’m trying to use the math module for is to create sequences were one or two notes in a pattern are transposed every so often.
In cases where I can use the 1:2 / 2:2 type trig conditions, it works great. Set the first note in the step to be 1:2, the second to be 2:2, and I’m good to go.
However, in cases where I want one note in a step to play for the first 3 loops and then a different note to play for the 4th, I’m at a bit of a loss how to make that happen, and I thought ON=0 was the answer; set one note with a 4:4 trig condition, and set the other with ON=0, so it would play whenever the 4:4 note did not. However, when I do that, the note set to ON=0 always plays.
Doing a little further testing suggests to me that all the ON trig conditions are broken. I can’t seem to get any of them to activate.
That is, assuming they work like I expect: If a given step has 0 notes that would play besides the note with the ON=0 condition, that note would play. Otherwise, any other notes would play and it would not.
If I’m not understanding them right, can someone please explain how they work?
i’d say you’re right… ON=0 never plays wich is not what the manual tells us
they do work
the thing you are getting tripped up on is that trigs is evaluation (and ordering)
so you cannot place the ON=0 note at exactly the same time as the other note, as they are evaluated together… so when its evaluated, indeed there is no other note playing.
so it has to be on another step OR micro timed , to very slightly after.
I think whilst, perhaps, a bit unexpected its not a bug…
the issue is that some trig conditions will have to have an ordering
e.g. if you put 1:2 and PRE on a single step
does that PRE, refer to the conditions prior to this step or ALL other conditions on this step?
and it gets complicated fast… what about 1:2 , ON=0, PRE … which trig condition is PRE for?
so whilst, we could come up with some complicated rules about trig evaluation order… that programmers will understand, I suspect most musicians will end up using uTIme
in this respect it pretty similar to Elektron, where by definition you can only have 1 trig condition per step
the best way to test these things if they don’t appear to work at first is to try a simple use-case… then you can expand to a more complex test case, to see if something else happens.
in this case,
first try two notes e.g with 4 length, second with ON=0
don’t overlap - expected behaviour
now overlap them slightly (e.g. 2) - expected behaviour
then put them on the same step… oh… now we see what your getting confused by
yes it does work as expected when notes overlap but that must not be at the exact same time
elektron machines doesn’t offer to set two steps at the same time … so you’ll never have the chance to do that.
I totally understand the requirement of the notes need to have an offset… but the manual doesn’t tell it.
So, if I’m following this right, it means ‘if there’s a note already playing when you get to this trig condition, don’t play the note with the trig condition attached. Otherwise, play the note.’ ?
yes, are there any notes ON at this point in time?
again, we need to think of this more as continuous time, rather than as a simple step sequencer.
imagine you zoom in, and have a tiny little note… at 4/64 past the 1/16 note.
is that ON, when you zoom out to 1/16?
well, the answer is , is it ON at the time the trig is evaluated.
in particular this means… the trig is evaluate when that note is EXACTLY started… this is why uTime, helps us out here.
I think the unexpected thing we see here is trig conditions are evaluated BEFORE notes are played.
in reality, this makes sense, because trig condition are determining if notes are going to be turned on or not… so at that point, all notes in that ‘time slice’ MIGHT be turned on, but are not on.
(not sure, if that clears it up)
perhaps easier to just say, I believe , the flow of operations is:
trig evaluation → notes turned on/off
there is one other ‘complication’ here… and that is when chance is evaluated (compared to trig conditions) , I did test this at some point, but can’t remember my conclusions
perhaps @Thibault_Squarp , might want to expand on this trig evaluation and chance, order of operations. … particularly if there more than one note on a step (at the same uTime)
that discussion might lead to a succinct description for the manual.
(as whilst, its clear in my head… clearly above, Im finding it tricky to put into words!)
Yep, this makes sense, thanks! I was making an incorrect assumption about how it processed steps, but now I get it.
Chance, from what I’m seeing, pre-empts other step conditions, so even if there’s a note that would be set to ‘on’ typically, when the chance condition isn’t met, that note doesn’t exist for purposes of evaluating ‘ON=0’.
We did notice some inconsistencies & minor bugs wrt MATH.
We are working on it.