Gen ratcheting acting unexpected

Luca Schwarz's icon

Luca Schwarz

8月 22 2024 | 12:32 午後

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 :)

Max Patch
Copy patch and select New From Clipboard in Max.

Source Audio's icon

Source Audio

8月 22 2024 | 2:28 午後

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

Luca Schwarz's icon

Luca Schwarz

8月 23 2024 | 10:54 午前

thx mate, you are right it really works that way, i am just wondering why? should also work without edge detecting?

Luca Schwarz's icon

Luca Schwarz

8月 28 2024 | 9:50 午前

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.

Source Audio's icon

Source Audio

8月 28 2024 | 10:00 午前

If it were exactly so, it would work.

But it does not.

Luca Schwarz's icon

Luca Schwarz

8月 28 2024 | 4:56 午後

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.

Max Patch
Copy patch and select New From Clipboard in Max.


Source Audio's icon

Source Audio

8月 28 2024 | 9:21 午後

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.

👽'tW∆s ∆lienz👽's icon

👽'tW∆s ∆lienz👽

8月 28 2024 | 10:20 午後

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:

weirdness :/

switch 'th notes' to '3' and it's steady:

ratcheting shows up 3 each time as expected :)

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 🍻

Roman Thilenius's icon

Roman Thilenius

8月 30 2024 | 11:12 午前

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.)

Luca Schwarz's icon

Luca Schwarz

8月 30 2024 | 1:14 午後

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!

Roman Thilenius's icon

Roman Thilenius

8月 30 2024 | 2:33 午後

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.

Graham Wakefield's icon

Graham Wakefield

8月 30 2024 | 4:26 午後

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?

Max Patch
Copy patch and select New From Clipboard in Max.

======

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.

Luca Schwarz's icon

Luca Schwarz

8月 30 2024 | 6:11 午後

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!