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'

yeah, your workaround probably works :-)

Here are related threads on this forum

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

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

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.

Cheers

-A

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.

-A

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