DominikK

while working on a project I had to deal with a problem concerning a play~ object an stop/start messages sent in short intervals. 

When a start message is sent shortly after a stop message without sufficient time in between the start message seems to fail to do it's job. The threshold seems to be around 20ms in order to make it work reliably.

The issue was very hard to track because i occured in a complex patch and using the debugger and breakpoints made it disappear. It forced me to use a pipe object to fix it, which is something I really like to avoid. 

Is this caused by the play~ object itself or is it a side effect of max control rate?

I attached a little patch to clarify what I'm talking about.

playscheduler.maxpat

while working on a project I had to deal with a problem concerning a play~ object an stop/start messages sent in short intervals. 
When a start message is sent shortly after a stop message without sufficient time in between the start message seems to fail to do it's job. The threshold seems to be around 20ms in order to make it work reliably.
The issue was very hard to track because i occured in a complex patch and using the debugger and breakpoints made it disappear. It forced me to use a pipe object to fix it, which is something I really like to avoid. 
Is this caused by the play~ object itself or is it a side effect of max control rate?
I attached a little patch to clarify what I'm talking about.
What are your workarounds?

best
Dominik



hey dearest patchers,
while working on a project I had to deal with a problem concerning a play~ object an stop/start messages sent in short

play~-startstop-timing-issues

Message "stop, start" will make play object do it as fast as it can.

I don't see a reason why should one need to do so,

but if there were, like very short pauses during playback,

there would be better objects to do so than play.

I am thinking on count index combo, or something else ... ?

Message "stop, start" will make play  object do it as fast as it can.
I don't see a reason why should one need to do so,
but if there were, like very short pauses during playback,
there would be better objects to do so than play.
I am thinking on count index combo, or something else ... ?


Well "as fast as it can" is actually not what it's doing. It looses the following "start" message at some point. That's what I'm wondering about. I know there might be better solutions that doesn't change the fact that I want to understand why this is happening. That's why we're here after all, to understand things.

I came across this issue because I needed the stop message to wait for a line~ to finish, before it restarted playback. It's setup where different positions in a long file are played back smoothed by a crossfade. So the perceived time between stop and start is much longer that how it actually happens in the patch. I know the stop message is not really necessary but as mentioned I'm always interested to know about max anomalies.

Well "as fast as it can" is actually not what it's doing. It looses the following "start" message at some point. That's what I'm wondering about. I know there might be better solutions that doesn't change the fact that I want to understand why this is happening. That's why we're here after all, to understand things.
I came across this issue because I needed the stop message to wait for a line~ to finish, before it restarted playback. It's setup where different positions in a long file are played back smoothed by a crossfade. So the perceived time between stop and start is much longer that how it actually happens in the patch. I know the stop message is not really necessary but as mentioned I'm always interested to know about max anomalies.


I can't answer the question why does play~ behave so.

If You replace stop message with pause, than it will

I can't answer the question why does play~ behave so.
If You replace stop message with pause, than it will
not loose the following start message :

0, 1  or stop, start   does not work
pause, 1 or pause, start does


play~ start/stop timing issues