delay > 480 ticks

I’ve got delays of up to 10 seconds in my current project and they work fine. Max 8.2.2 Windows 10.

thanks, this is strange I cannot get a delay longer than 500 ms
Am I being stupid and tired or is this a bug? Running Max 64 mac Rosetta

I've tried to reinstall Max, turn off Rosetta, still no delay longer than 480 ticks.
This computer has 64 GB of RAM so can't imagine it's a problem with the memory.

I've also used long delays without issue, but never used `ticks` before.

In testing with your patch, I wonder if it may have to do with the speed of the metro above it where you can't delay something longer than the rate that new bangs are coming in, with each subsequent bang "resetting" the delay. I changed the tempo to 2n as a quantize rate and it happily took longer tick times.

Thanks Rodrigo! you're right, it seems like delay resets itself as soon as a new bang comes in. I've never realized this. A double bang in delay's helpfile only outputs one bang.
on the contrary, pipe keeps a memory of its input, so in this case pipe works great

What I often do if I want to "hard update" a delay is to use [t i clear] so you clear the delayed signal before setting the new value. It won't help if you want to set it to a time larger than what you've set it to, but it will help for updating things and it working the "first time".

thanks! that sounds like good practice!
I have a sequence of irregular bangs (rhythms) that I want to delay by 1900 ticks (almost 4 beats) so my instinct told me to use delay, but in this case it seems like converting bangs into integer numbers and using pipe is the way to go

If that's the case you may want to look at using [rate~] and a global [phasor~] rather than metro as it would be tighter and you don't have to worry about scheduler-based things. It's also worth noting that [pipe] messes with the scheduler priority of the messages too, which in a larger/complex patch may cause other problems down the line.

Hi Florent. I've loaded your patch into my Max and done the following:
1) If I send single bangs into the delay, they come out with the expected delay time - I tested this up to 10 seconds (10000ms).
2) If I send multiple bangs that are spaced further apart than the delay time, they all pass through.
3) If I send multiple bangs that are at intervals shorter than the delay time then only the last one comes through.
4) Using the metro, the bangs stop coming through once the delay time exceeds the tempo of the metro. Once the metro is stopped the last bang comes through with the set delay time.

So this confirms that every bang going into the delay essentially resets its timer back to zero and if bangs arrive faster than the delay time the previous ones get lost. In fairness, it does say this in the reference documentation:

Delay - Output
bang received in the left inlet is delayed by the number of milliseconds specified by the right inlet, then is sent out the outlet. Only one bang at a time can be delayed by delay. If a bang is already in delay when a new bang is received in the left inlet, the first bang is forgotten.

Have you tried using pipe instead? If I replace the delay with pipe then it works as I think you are wanting, with every bang coming through with the required delay, irrespective of how long the delay is:

Pipe - Output
When a value is received in the pipe object's left inlet, it is delayed by the time specified, then sent out the left outlet. If there are middle inlets, the values in those inlets are also delayed and sent out their corresponding outlet, in response to a value is received in the left inlet. Unlike delay, more than one value at a time can be delayed in a pipe. When a new delay time is received in the right inlet, it does not affect when the values already being delayed by pipe will come out.