Gen ratcheting acting unexpected
hey there. so i am building this little retrigger ratchet thingy which creates a specifiy amount of re-triggers based on the value in that int box. it works just fine when i trigger the bang manually. weirdly, when i plug in the trigger genarator in the patch (callled propabilistic trigger generator) my ratchet engine will only put out the correct amount of triggers after at the very first trig. every trig after it will miss out the last re-trigger. it is quite reliable with that missing out, though i dont get what is the reason for it. any ideas? also open for any aspects of more elegant soloutions for this patch. thx in advance for your help, it is really apreciated as usual :)
I guess there are many ways to create few clicks~ .
I don't want to comment what you do in that patch,
it is your soup, but to fix that "propablistic" construct, add this to output
to make it produce same signal as manual click~.
you should limit gui elements to usable range.
what when set parameters make no sense ?
for example this
thx mate, you are right it really works that way, i am just wondering why? should also work without edge detecting?
hey there! hmm i dont rly understand, i am not using the gate signal, i am using the click trigger signal for triggering, it is basically the same as edge detecting and banging that click object.
If it were exactly so, it would work.
But it does not.
alright i kind of know now that the problem is in the calculation of the bpm. it still makes no sense to me, but look at this: when sending the bpm calculated in a gen pacher the trigger amount is again not accurate. though, when i use a simple number object with the same value as the calculation it works just fine. is this a bug? or what is going on? it is literally the same (static) value.
sorry , i can't tell you anything about that.
I find this gen constructs far too complicated for that few timed clicks,
which can be easily done using max objects.
i am not using the gate signal, i am using the click trigger signal for triggering
oops! sorry, my bad, i got confused looking at different versions of the patch, you are correct.
it is literally the same (static) value.
that is one area of confusion, it's not the same value(open up number~ larger to see how much floating-point there actually is), try the exact value and you'll see the BPM calculation is still causing both to output the same pattern:
i can keep this unreliable amount of ratcheting from happening, simply by switching '4th' notes to '3th' notes for that specific BPM of 160 you're testing with:
switch 'th notes' to '3' and it's steady:
this usually means it's just the math being used(not a bug), apologies i don't have time to go through and figure out where exactly that is, but hopefully tracing it between the specific settings for BPM and 'th notes' to see where it might be going contrary-to-expectation can help 🍻
don´t miss that while signal triggers are more accurate than transforming data rate triggers to signal triggers, signals have a lesser time resolution than data rate messages - clicks can always only happen inside the sampling rate pattern.
as a result, it can become very confusing when you attempt to work in milliseconds instead of samples (and make sure to properly round down to int where needed.)
ok that is a very good insight thx roman! this makes so much sense. i guess the more comma digits the more problemtic it gets. will keep this in mind!
if it is possible for you in your project, you could limit the speed settings for the master phasor~ to only those time values which match exact samples values - or maybe even use counter~.
if done right, this would solve the amplitude value comparation problem.
First I should note, in case it wasn't obvious, 2.667 is not exactly the same as 4*(160/60). The number~ box is displaying 2.667 as an approximation of the true value to fit within the display, but the true value is probably something like 2.6666666666666666666666666667. Over time the two clocks will very slightly drift.
Now in the ratchet patch, why are you not using the master phasors to drive the ratchets? You have the master phasor patches, but you don't route their ramp signals into the ratchet patchers (instead you have another master phasor embedded in the ratchet patcher, and you are resetting that phasor by triggers from the other master phasor. Triggers are inherently less accurate than phasors (that's a big part of the narrative of the GO chapter that a lot of these patches are drawn from). Use the phasors.
The rest of the patch I can't quite understand what you are trying to do. But here's an example of getting 3 ratchets then a rest per master phasor loop -- maybe that gives some ideas?
======
Note in future, you should name your gen~ patches using @title, e.g. [gen~ @title masterphasor] or [gen~ @title "calculating bpm"] to embed the gen~ content in the Max patch. Otherwise the argument is telling gen~ to search for an external file. That's why when opening the patch you see warnings:
gen.patcher: could not find gen patcher phasor
gen.patcher: could not find gen patcher phasor
gen.patcher: could not find gen patcher masterphasor
gen.patcher: could not find gen patcher calculating
gen.patcher: could not find gen patcher masterphasor
It's lucky that the gen~ patch content is still there.
Hi graham! thx for you response! i will keep all in this in mind, and yes you are so right i am a curious reader of your book hehe! Yes my bad, i just displayed the value of the calculation in a number object without checking if there are some more numbers hidden behind the comma.
Yeah maybe "ratchet" isnt the exact name of what i was wanting to achieve.
So my inital idea was to have like a dedicate sequencer, independeant and outside from that gen patch i posted here, sending triggers in the patch (i posted here). That phasor outside of the patch was only a placeholder for that sequencer-to-be-built.
The whole plan was to use this gen patcher (more or less) like a delay/retrigger unit for signal triggers. I mean by that: Sending a trigger in it and ouputting a quantized amount of triggers, where i can set the amount of triggers and the speed of those triggers from outside of the patch. I guess i was on the wrong road for this ^^ but it would be so so intersting to know, how you would approach such thing.
Would be great to hear from you :) thx in advance!