[bug] observing property is_playing

    Nov 01 2010 | 10:48 am
    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:
    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.

    • Nov 01 2010 | 1:36 pm
      It's a known issue and has been discussed on several threads. Personally I'm using a "filter" as shown in this patch.
    • Nov 01 2010 | 2:31 pm
      sorry, couldn't find it on this forum by searching for 'property is_playing'
      yeah, your workaround probably works :-)
    • Nov 06 2010 | 9:37 pm
      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...
    • Nov 07 2010 | 10:37 am
      "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..?
    • Nov 07 2010 | 2:59 pm
      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
    • Nov 09 2010 | 4:28 pm
      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.
    • Nov 09 2010 | 4:36 pm
      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.
    • Nov 09 2010 | 4:53 pm
      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.
    • Nov 09 2010 | 6:42 pm
      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.
    • Nov 09 2010 | 8:01 pm
      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.
    • Nov 09 2010 | 10:25 pm
      @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!