stopping count~ from looping
Hi everyone, I want [count~] to count up to a certain number and then stop, at the moment its just looping round and round.
I tried using [< ~ 1] to try and catch the count on its way back round so I could shut a [gate~] but I can only get it to spit out a 1 when it’s argument is really high. I’m sure that [<~] is sample accurate isn’t it? I know I’m missing something here…
Any ideas?
----------begin_max5_patcher----------
651.3oc0WEriaBCD8L4qvxW5kzJFCDHUUppeGUUUjf2DukXGANax1Ua91KdL
jkMkDnIKjsW.4wlg277yyCdZjCclZGOmR9L46DGmmF43fgLAbJG6PWEuadZb
NtLpjuUM6d5X6TZ9NMFd9xX4BdU36TRct32byT.6StkgkaVIjobMlI3kfpM5
pndkQWmwy4RcrVnj+LiOWaw3zfhjQfotlaUWH+n7gDIHVJv2G88piEY7JDKz
ukIhSqlw9Z0OtlaSNkNlPERc0sC4ccrd9RgbQMfDFg.I.wS.hDFBEyS77nQl
KiuNJccVAHHaW9HIQwykePSzKE4jspre80qmncafy7amyNMUX2SffnqiK1rZ
FOa++R8wZr9XmWHMwh1haAsHjf1IkUpDd824eIrxEKjlkSn2kphqorJl.2LN
TYMvu9.BUFhxfI8gT6K6IrqmxgFXO2K3XXIactieVNYJRFdA+Wn3fno39HLo
MImWzsVxA19rV9EB8LH9hI3YazZkj18VSMni7fSpVlUX7bVsB3ZMMNHSd6O+
7V69UqxYg8qQF3yFHmLUFZf0OdWrKy6pr5Y.d1LL78Umj502M2Fp5XTe6C45
1KNQPX+3DURK1Vk9Q8R2E0FodOwkDEUvNDnQ9w6R3mSYUA3AgPVaekc+xo1V
R..1inGQpXBnoB4w++BlPS7Wyz4pMYyq.QUmUxKkUBOWKjHUTeQ9uZQKEIIb
Y8dPIh73YobjSbabOuq3w7KKshG+gCOPm3GXvvSWfyQX9VCGym+NTpGyFAzF
d7FN731E948k5w7g2CDb7fNfmgSLy5h5gco3w1pNd85G3Y4k4DgRg828pLyv
IiwgBocHlQZF+AQ05CGYx1yi9CfGjpjE
-----------end_max5_patcher-----------
This is a way to do it. It’s not sample accurate though.
there was a post about this once
Hi,
a short explanation on why your original patch is not working: the DSP chain (think about the objects connected with yellow cords) runs real-time. However, the right output of the [number~] object in your patch will monitor your signal and output its value each n-th millisecond (by default, one sample value per each 100 ms). Since you have a [< ~] with parameters 2 and 200, these periods are simply too short to make it sure that the 1 sent out by them (when the counter is between 0 and 1 or 199, respectively) holds long enough to be catched by the 100 ms long monitoring interval of [number~] (if you’re on 44.1 kHz, then 200 samples will last approx. 4.5 ms, so your chances of actually catching that 1 by the [number~] are quite small). To make it sure that you always catch the changes (at least, theoretically), you’ll have to put at least 4410 as the parameter of [< ~] (if you’re on 44.1 kHz AND [number~] has a monitoring rate of 100 ms).
On the other hand, you’ll need to consider that the messages in Max are processed on a lower priority thread, and generally speaking, it’s not a good idea to flood the messaging threads with too many messages at the same time…
Hope that helps,
Ádám
That’s a good solution, pid.
What does the bitxor~ do? I’ve never seen this object before.
Hi Barry
this seems quite solid, and doesn’t reset to 0.
Brendan
@dave m: the helpfile is very comprehensive and clear, take a look?! also, i think the example is the work of dsp guru christrippledot – take a look at the link in the file i posted.
the problem with the other solutions in this thread is that they are not sample accurate and thus very wonky. the solution i posted is particularly accurate since max6, because of the 64-bit signal chain accuracy ([+=~] now accurate).
this is even better written in gen~ or GenExpr, and much more versatile in that environment. almost all dsp counting tasks i have these days are pieced together in gen~.
hth.
A variation on pid’s patch, with fewer objects:
Thanks for all the help and explanations guys, its been a big help! :)