[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:
----------begin_max5_patcher---------- 317.3ocsS0zSDBCD8b4WQSOijVfMt5M8rFu3MyFSgV2slRaSaQQ2r+2EJv9g AS1DVuzlNu2Ly6MLrMBfJzMbGBdK7EH.rMB.Bg5B.FdCPUzlRI0EngT7O0Eu ih6g77FeHrTSYET05Q.csWx89uL79hiBfvUCvBVHq1JcEIcLm2zJuhVEx.cm UPkv60R1Hrg5K2HTqe0xK88UcY9MI3X3hEGNIKSv6aiptRnZ0QP5jiZiS7cn MDbaN641K5dxcA2EE0cDOuQiwJTdzDFmLaimhy6txxtfNGe4b9i4OjPMhjmJ bb6G7msTkyns9+bIY5ED7rmSDBIbkc8+zJRnbHoP86elBZpK9oSOmt1VN55Q SBOnJF24EJpWnUGShbBoMBFiGvGEXkfYzsaaCh.tZxukmslROGMgmglZerK5 Gn8QMTO -----------end_max5_patcher-----------
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.
It’s a known issue and has been discussed on several threads.
Personally I’m using a "filter" as shown in this patch.
----------begin_max5_patcher---------- 574.3oc2VtsiaBCDF9Z3ovhqoHay4dW6qQ0pHB3l3JhMB6rMaWsu60G.sjsa HrDBps2.3Ae3e9Xlg4YWGus7SDgG3yfuAbbd10wwXRavoari2ghSk0EByz7X jex29COe6qjjSRiYAPHKZk81aJjk6orcaZIkR61igYAw9fvbX.zGDgzWQYAP vCcq46blTP+EQOcjdRVyzJyAnNzOg62d1wCTVMQZjDZv5YEGLq26KszhZvW4 0U8qojWyasRAFjgPoIJ0.CBSwwQ4CeBMPSpCheT1eRPswWbc0W7ucdwaFCWw oCwEbF3J9+GbIAnQXEJLxvJbllRX7LXUxsvpyc69EYMIepgXUoGkoz6CKITf iAkLjEJIyFJn+AgREot3Ik+.ud7BN2DuDmLmRQuexEdQYy1B1tEEN6JjD.Zz botxz3Pacmr4vF7JvlEkKBRsB.Jx.m.YRBmeTCb4xnBGMpw+06KJopoORB3a Ej1GIs.pXSiJcipOnKysPyexPo1XIbzbpDkubgT3KFRcWfkhH6A5m1HHi0eT HLwfonXMexmS+QnrUH7xPo+fTFUpbX1a6lz3oZ6miOA+XaY+V1mZnR.6c1Jh PRYERJmMXRphtfWAxdZUEw75dVbfV0vU+QoSCW3a4TkjFmWUR5HyAS5tqo7y Pv6qIcA30TSSURefOcHaBPXbWQCauLmMBiRMc1frc8oGciNRx8vQhhVeGwjL cMOAspISugaW.tv0USSAS30URwSPRI+ERoaozrZvKt+FxEWw8. -----------end_max5_patcher-----------
sorry, couldn’t find it on this forum by searching for ‘property is_playing’
yeah, your workaround probably works :-)
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…
----------begin_max5_patcher---------- 701.3ocwVtsiaBCDF95rR66fEWmFAjjBo209ZTsBYBS13ViMx1jlzU8cu1lC KrqgbfsMRIwjYFL+ymGF6Wd7gYdo7ifzC8Ez2Qyl8h1xLqMikYMFl4kiOtkh k1.8Xvu3o+vadsOEbTYsWHHLEhHSJn3SD1ysQPxr902zmB1zZcGmoX3bv56q BBlh9Fml05u.q1tWOMIBXqpRgKWsveNJLbsYH19mf3E9nmZtGVYNgQAkUnAc rxKUMl86J.I42VAD3uv2Z9OO9fYTOLex.gRN.K3oRPb.DNoQ7zoQvlHyPT3Y nQnaZDNDMZrWEq5TAT8T87lq+hd5loUNHk3mAW0O7BPnN4pDhRXvVdIS0Syc QYzTPYvmszaUGTFFcsnL35Q4Dv3PEcJTJh5rXa8THTzRKg7sfZY3h02xqdWe wVJ1TDLMRYeMLsTo3r1L7.VzB.W96xskmmKap5K0764nRAVne3JPj.LbJEFA YAiU7z3ShO.YIXkRPz4A75UxZtz.FShSKA9tF6sN5JJ8Ka+zPmdsK6EQNOS+ AFzOgsiaAnmKukLRUx41MWjoaWNzTmA6Fwqr.fLJI2htECnsCDIol5tmDETL btiYLtBqHbVRaIjy7.zqj0qU7c6LUw5Br1Es9gdrfyfptaCHaKzTmpKVbupn K6GYFx0kh1rxs6lRqP2PinzsI5Tu5lb64B0XuX8tpnZEa515JDJm87UMesoX s+5FFudwG9F75lB6c02X0za2FY61tN31Nnyxaaq84+a1WhxwYls9QFdgLjKQ BJmMbmN3p1HOHz+1H2GwN4UOQ6AWd64qsx133MbTxKEaalwZRf5H8LPpHLaq mNAspeP6IYY.q2AcyIYEb8Yyq0wXKtWtzVdIZK39ns0Wj1htehK3rhKteT+u DWzEQt36B4VcQZa88YUM9hD2lIKNiA8veQVPhNI -----------end_max5_patcher-----------
"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.
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 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!