Timo Rozendal

when observing the 'is_playing' property of 'path live_set' the output value is incorrect when starting to play:

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

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.

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: 

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.


bug-observing-property-is_playing

It's a known issue and has been discussed on several threads.

Personally I'm using a "filter" as shown in this patch.

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


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

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

yeah, your workaround probably works :-)


https://cycling74.com/forums/behavior-of-live-observer-is_playing

https://cycling74.com/forums/safe-usage-of-live-observer-is_playing

https://cycling74.com/forums/behavior-of-live-observer-is_playing
https://cycling74.com/forums/safe-usage-of-live-observer-is_playing


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...

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...


"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..?

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


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

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.

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.

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.

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.

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.

@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 

 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!

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.

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


[bug] observing property is_playing