## Counter MSP

May 28 2013 | 10:10 am
Hello,
I made a counter in MSP with these functionalities : - reset the counter - sets the direction (up or down) - sets the mode (auto or manuel) : in auto mode it's like the combinaison metro / counter in Max domain and in manuel mode, the user send a bang. - sets the maximum count - sets the speed (auto mode) : like with metro speed - count one tick (manuel mode) : like sending bang to counter
The counter works, but I have only one issue with the direction. When the user change the direction, the counter doesn't update the direction at the right tempo but immediately. I want the same behavior as the Max counter, so if I set a 1000 ms speed and I change the direction after 800 ms, I want that my counter wait 200 ms before it updates the direction.
Any idea ?
Thanks for the help
Another question : which version is better ?

• May 28 2013 | 12:08 pm
Sah~ could help
• May 28 2013 | 2:11 pm
Thanks ! It's a good beginning ! But is it enough precise ? Because phasor doesn't really reach 1, so the value 0.9999 si an approximation, no ?
Now, when the direction change, it doesn't countdown from the previous value. Maybe the way I made the countdown isn't the best way to do this ?
• May 29 2013 | 8:55 pm
Here's some tweaks. I've swapped out some of the logic (e.g. the if else) for things that may be a little more Max-ish. Ultimately, however, this is the type of thing that would best be handled in gen~ because the logic is much simpler when you can base it on previous states of the counter (since you can have single sample feedback in gen~)
• May 31 2013 | 6:59 pm
Thank you for the help Peter ! Clever ideas in your version ! The first part is clear for me and way better than mine, but I don't understand all the second part (pong and modulo subpatch). Why there is %~ 8 / +~ 8 / %~ 8 in the modulo subpatch instead of only %~ 8 ? Because the result seems to be the same no ?
Edit : I understand now the subpatch modulo (to avoid negative value in down direction).
Why the abs~ object is useful here ? Because when I check the out value from delta~ with number~ and print, it's always positive (0.000023). But if I erase the abs~ to test, it does not work anymore.
I made a version based on yours. I can't see how to reset the signal accumulator at the tempo and in signal domain. In your version, it works great but the reset isn't synchronize with the main tempo.
• Jun 01 2013 | 6:29 am
You can use rate~ to run the reset at a multiple of the accumulator's clock signal. (e.g. rate~ 16 should reset once per 16 pulses)
The abs~ is there so if you had a negative frequency in your phasor~, it would still work, since you're just looking for a big jump, regardless of direction. You shouldn't be seeing negative frequencies if you're just specifying in milliseconds, but say you add an LFO, etc. later...one less bug to find.
• Jun 14 2013 | 5:41 pm
Thanks Peter ! It works perfectly, but I have a problem to reset the signal accumulator at the right tempo, because if I change the min or max value, it updates the rate immediately. I think the max value must be stored and send only when the count reach the min value. I try with gate and sah but it doesn't work... any idea to achieve this only in MSP ?
• Jun 14 2013 | 6:35 pm
I think you need to sample and hold the min/max values. What about using scale~ for that?
• Jun 15 2013 | 6:13 pm
Thanks for your help ! I have an error with the scale~, it's an external object ? The sah~ is a good beginning, but the timing isn't perfect yet.
I try a new version with your ideas and without the pong~ object, but I don't succeed to make it work... If I want to update the min and max values without breaking the tempo, I must update the rate~ only when the phasor~ ramp is over, but when the sah~ is connected to rate~, the counter doesn't work anymore...
• Jun 15 2013 | 7:20 pm
scale~ is a native object. I guess you have something wrong in your search path. Look for a file in your search path with the same name.
" but when the sah~ is connected to rate~, the counter doesn’t work anymore…"
If you want to process the same vector you will need to introduce a vectorsize delay. Send~ and receive~ will do the job.
Have you tried with gen?
• Jun 16 2013 | 9:40 am
I search for the scale~ object but I didn't find it. Is it a Max 6 object ? Since, I'm still on Max 5 (and so I couldn't use Gen).
I don't really understand your explanation with the vectorsize delay. If I use a vectorsize delay, the counter timing will be inaccurate no ?
• Jun 16 2013 | 7:43 pm
yes, you will get a delay of n samples. (n is your signal vector size) but you can avoid the delay using the first routine of your patch to trigger the max value. something like this should work:
• Jun 16 2013 | 10:27 pm
Thanks ! It's almost what I want.
The only issue I see is when I change the max or min value. The counter update with the good values only after one count. For example, if it counts from 1 to 4, and then I choose a max value of 5 during the count, the counter will count from 1 to 6 one time, and then with the good range : 1 - 5.
Those timing issues make me crazy :)
• Jun 16 2013 | 11:06 pm
I think you need to trigger the min max vals with the same impulse from the first sah object.
• Jun 17 2013 | 10:55 am
I've already try this but it doesn't work. And I have also the same issue with the send~ and receive~ object.
• Jun 17 2013 | 12:16 pm
• Aug 18 2013 | 3:46 pm
I work on those timing issues since many weeks and I still have the same problem ! So, I decided to make it again from zero and I saw that the first timing issue happens when I change the rate multiplier value from the rate~ object.
Example : - I set my rate at 4 - My counter count from 0 to 3 - If I change the rate value (for example 5), it count from 1 to 5 one time, and then from 0 to 4, but I want it to count from 0 to 4 immediately !
any idea ?
• Aug 24 2013 | 4:03 pm