[bug] observing property is_playing

Nov 1, 2010 at 10:48am

[bug] observing property is_playing

when observing the ‘is_playing’ property of ‘path live_set’ the output value is incorrect when starting to play:
it is 1 0 1 instead of just 1
the output when stopping is correct

this can be easily checked with the [M4L.api.ObserveTransport] abstraction like this:

– Pasted Max Patch, click to expand. –

I’m using Max 5.1.5 and Live 8.2 on Mac OS X 10.5.8 (Macbook Pro, 2.5 GHz Intel Core 2 Duo)

it is especially annoying that if you have notes exactly at the start point it will first receive the is_playing value 1, then the midi notes themselves and then the is_playing values 0 1
this makes it impossible to reset the effect on stopping the track by observing this property.

#53035
Nov 1, 2010 at 1:36pm

It’s a known issue and has been discussed on several threads.
Personally I’m using a “filter” as shown in this patch.

– Pasted Max Patch, click to expand. –
#190751
Nov 1, 2010 at 2:31pm

sorry, couldn’t find it on this forum by searching for ‘property is_playing’

yeah, your workaround probably works :-)

#190752
Nov 1, 2010 at 4:39pm
#190753
Nov 6, 2010 at 9:37pm

Actually this looks more like a bug in the abstraction than M4L itself. I hardly use the pre-made abstractions myself, and I guess this is yet another good reason to do so…

Get rid of the abstraction and use your own routines and you’ll be just fine..

Check out the testcase below. As long as you rely on loadmess the patch will behave as you’d expect. Using either the APC or the spacebutton or mouse button, etc. I just can’t get it to misbehave.

However.. As soon as I manually click the button after the patch was already initialized you’ll notice that it suddenly starts to print several values. I can’t conclude otherwise than an issue with the abstraction…

– Pasted Max Patch, click to expand. –
#190754
Nov 7, 2010 at 10:37am

“I can’t conclude otherwise than an issue with the abstraction…”

So how would the proper abstraction look like?
Or are you saying it can’t be handled with an abstraction at all..?

#190755
Nov 7, 2010 at 2:59pm

I found it out not using the abstraction but I posted the most simple example I could think of: with the abstraction.

how do you do it shelluser? then I will check how your solution behaves on my system

#190756
Nov 9, 2010 at 4:28pm

I did some further testing to make sure I didn’t overlook anything and well, sorry to have kept your hopes up but I did. When I started to deeper investigate with the mouse/keyboard and midi mapped options in Live itself I finally noticed the behavior.

Still, from a technical perspective I wonder where the bug really lies. I mean; when re-starting the transport by hitting play again Live does in fact start, stop (and reset the position) and restart again.

Anyway; I overlooked the option at first because this behavior doesn’t occur when using a supported control surface. Only when you’ve midi (or key) mapped the Live button does the event occur.

#190757
Nov 9, 2010 at 4:36pm

Why would you use the API for this? Is there something I am missing? The plugsync~ object seems to me to be a much better bet.

Cheers

-A

#190758
Nov 9, 2010 at 4:53pm

Well, there is a major difference in behavior here. Whereas the live.observer only signals upon changes the plugsync~ objects constantly sends the current status.

I’m not sure here, but it wouldn’t surprise me if plugsync~ would have a bigger impact on the live environment than the live.observer has.

#190759
Nov 9, 2010 at 6:42pm

Yeah that’s why you use a change object under it.

>I’m not sure here, but it wouldn’t surprise me if plugsync~ would have a bigger impact on the live environment than the live.observer has.

I really doubt this. But you could test it by creating a few hundred of them. Max’s internal transport is always synced to Live’s transport. This is a constant, negligible MFL overhead. All that plugsync~ is doing in this case is asking if Max’s (Live) transport is running.With the API, calls you make are inserted into Live’s GUI thread.

-A

#190760
Nov 9, 2010 at 8:01pm

Using plugsync~ makes sense to me since MFL devices are basically plugins.

I’ve just measured the timing accuracy and found that plugsync~ delivers “1″ in perfect sync with the first tick from transport. In comparison, when using live.observer there is a difference of 10-20ms.

#190761
Nov 9, 2010 at 10:25pm

@Andrew: Good point indeed! (that the transports are always linked anyway).

Well, broc beat me to it, but even looking at it from a theoretical point of view it makes better sense now than this method should be faster. After all; Max can process signals a lot faster than the Live API can. And since plugsync~ obviously will be using its internal routines to check up on the state of the transport it should indeed be faster.

The thing which puzzled me was the constant stream of signals, but I guess that’s neglectable.

Thanks for the tip, I wasn’t aware of this object yet!

#190762

You must be logged in to reply to this topic.