ring

I simply want to have a signal accumulator that goes from 0 to e.g. 48000. If the result is beneath 48000 (

Do you have any workaround without leaving the signal domain (like having an edge or snapshot object)?

signal-accumulator-loop-doesnt-work-bug

+=~ needs a signal input to work; also you cant have a signal feedback loop the way you structured it

if I understand your question correctly, solution (I think) posted, but you might also just use [phasor~] (also posted)

The aim was to use this together with index~ in order to play a buffer~ one time from a starting index to an end index.

I still don't see the point why it shouldn't be possible to use a loop like I showed above. I find this a little buggy.

Looks like you've sorted it already, but here's another way of doing it. The problem with loops like that is that Max processes audio in chunks (aka signal vector). If you have two objects in a loop without any delay, it's impossible to determine who goes first especially since the output of one object will change the other. (and this is not a problem that is unique to Max; Google "delay-free loops" and you'll see that it's a nasty problem! (albeit with some solutions, but lots of math involved))

The minimum delay in Max is the length of the signal vector. Note that you can set the signal vector to 1, though this will eat up lots of CPU. You can also, however, set the vector size of poly~ patches independent of the current vector size, so you could wrap it in a poly~ and do it that way. Usually if you find yourself in these type of conditions it suggests one of two paths:

1. Fake it: You don't really have to update certain values at signal rate. For example, in your code, the cutoff comes from >~ instead of at +=~; it's not as notationally neat as if the loop worked, but it works the same.

2. Make it/Find it: you absolutely do have to have these two values dependent upon each other and (near) instantaneous in response, so you should probably write an object in C++ or Java. For example, an oscillator that changes its frequency only at phase 0: this is nasty (impossible?) in MSP, but trivial in C++ or Java. Chances are, however, if your task is important enough, someone else has written the object and you simply need to find it. Maxobjects.com is your friend...

Looks like you've sorted it already, but here's another way of doing it.  The problem with loops like that is that Max processes audio in chunks (aka signal vector).  If you have two objects in a loop without any delay, it's impossible to determine who goes first especially since the output of one object will change the other.  (and this is not a problem that is unique to Max; Google "delay-free loops" and you'll see that it's a nasty problem! (albeit with some solutions, but lots of math involved))

The minimum delay in Max is the length of the signal vector.  Note that you can set the signal vector to 1, though this will eat up lots of CPU.  You can also, however, set the vector size of poly~ patches independent of the current vector size, so you could wrap it in a poly~ and do it that way.  Usually if you find yourself in these type of conditions it suggests one of two paths: 

1. Fake it: You don't really have to update certain values at signal rate.  For example, in your code, the cutoff comes from >~ instead of at +=~; it's not as notationally neat as if the loop worked, but it works the same.
2. Make it/Find it: you absolutely do have to have these two values dependent upon each other and (near) instantaneous in response, so you should probably write an object in C++ or Java.  For example, an oscillator that changes its frequency only at phase 0: this is nasty (impossible?) in MSP, but trivial in C++ or Java.  Chances are, however, if your task is important enough, someone else has written the object and you simply need to find it.  Maxobjects.com is your friend...


signal accumulator loop doesn't work (bug?)