is_playing wavering at playback start

[amounra93]

The short of it:

When using live_set property is_playing to monitor the transport state (which is apparently the only way we have now, since transport doesn't work in that capacity anymore, and hostsync~ is out), the value sent by it bounces back and forth between off and on, even though the transport is on, at the very beginning of the play action.

Aside from this being incorrect, it makes it impossible to sync to the top of a loop position when playing synced to a beat, but not to a timeline. I'll include a patch, perhaps someone else can reproduce what I'm getting. Just load the patch, open it, press play in live, press stop, look at the max window. Bouncy is the result of the transport state reported from the API. The metronome is a pulse that has an autostart time of zero. Some of you may see some potential problems in there.

Thanks for looking.

<pre><code>
----------begin_max5_patcher----------
987.3oc0X1saaBCEG+5jmBqbcZjs46ooospdSk1dBlppHfSpm.bD3z0rp9tO
iMrljZ.WJ0ZsRo.1Dx47i+mywG+37YKVydfTs.7IvOAyl837YyjCUOvrlqms
HO9gjr3J4ssnf7a15esXoZJN4Atb3LVb553hssSPSkCKt0KPAsCtgUvKhyIx
o9VIMNCbIKKsc5h84zhLBW9CgN56TQ+i76ffqfMCuKlmbGsX6skjDtx9cPNh
oAnP4AOO0Eqffad94y1yO+GPMD+vNh5wrP5Ffapm8o4yq+2RCYSBKOmTveIb
D9LnhksmSYE.vEs+8EczxyNzBAk.xIDJ4jGb.bAGAO5PqrqjVvA4DdISG.bs
C.bgXI.vt0G7crm+K8bwObA3qw64rJdbIGfN5BNUnWf5XCdLrAOV1fijZDLz
29wR8pcVy1WjbPCfBsTpFbfR6HUMAH6ocDBEc5BT29swtbTedL1Or1IcQxCX
kGG75EDh2dSqdfti.7fZCVfuRnfGITbhhjrwarPYRIBG.0l6v4cWh3EbTEEG
7JudoAtOIxxoWorMlSzfEu2cQhmJxwQQG2AvhcDIU.YgFcQMVPmn.RibYnnl
IM44ZPlFe1cxVxQjAUMvt90Z.+fAbbbuEUWNVEQNopJdKQSkU1NRI+.fVc6t
r3CTsKlG6OUq.wHTE.qQkZYHHOaEzzIhh42Axn2StshnK1wCaG3nZzAKVAes
NxxvoqF.EXYUMfzwEGC4RBKiUprN3pnPWGj6RwYgnHeXX8YPOXj3DzoN6aIl
rgkXIKcGJlzoSVtr4yjyT15JR48jRcb00VbczAvQn2VttwyztZF+yfK2SyRA
GX6KA+35qtFP1rQX2f6Hk+KjOiVPRDMYvO13Nthgc5yHR13kurC0PUuXQSZg
xtfzUj6oIDfP1woIBeJilS0kwKZBVrP+HPsuDApCptO5qSqlQuillRJjO8Ij
JR0BmA9tHtTCLFZet.WyiynIlCFTuQXplxcjshEn19hnAAylxsqaAqScjuiL
Sf6ow90d7I4LzbqSMW2Txx6hr91krMhMYTW3GAv10FMQSoBSU2x3rzdronGR
taRMEWsyVrI7bZgt1aroi6n7a3X28rWzBr7AHKNc1d1KMg5wOEUUhZbIsOs1
MPD7rcjRp3zh35sk93ax8ja54bosNrft6XBiqwH5PxZrMEXfM4gspM44ZfME
ZWSxjWc0qz1h1Tc2fCaS1UNIQ.Z.ax0t1jqIxoyfoUrIjIu6P1KU.zjzSH6l
dBYhF2pljyGRK5rWt1vjPF.Iz+WEUraBbOSduYWSxjvs2xhADW7z7+BRygoE
-----------end_max5_patcher-----------
</code></pre>

[pukunui]

I get one bounce. You could filter it by using the transport's stop to set the onebang object.

or

<pre><code>
----------begin_max5_patcher----------
410.3ocwUE0SCBCD9Y3WQSeFWnEvsYxdP+aXVLEnB0.sDZINcY9a21xvMWl.
FmrWZC2c85222cWYqqCLVrgJgf6.OBbb1553XMYL3r+aGXIYSRAQZCCF2nTB
Nzq0UEQkjy3YOUSSTsoIBgm46APAglMre2JX89yvRsIRD+xMX+tDIZTETk5s
JZaVfwDdF7qyvaJYbc.VLfNXr8XsVMF245ZV7tTjIDe63IC55RFN8UML5vfh
twxAHMMi9wHnneX6VTubD2OG8NkqOK3JNozFD79ZFo.djGI6cqGDZVzxHzh4
iWgvWNEZ0pO.9yFVhlaK+gg8JPA+n.IYYbM8ujRC9+t4IIWWMGS6SvRyZDx1
Cs37ZCZ4ePa.OHJROq.YpJWiAqphlrpbhTTOlwK6ihy6WeVLj9nGuJXR0DnS
GOdYuM8EyO8OEV5Zr+cwSJZpS5PdWgGbfxoTohwIJl9o2CAYlbNJnbVZJ05u
C0krzJAiq1CBv5yVJGKlLujAPCgI+oGSCpSnoESAiAS3IESlAkAwzIMc+NLo
+Xm6mT3Xa3B
-----------end_max5_patcher-----------
</code></pre>

[amounra93]

Thanks, it looks like plugphasor~ will work better than my method anyway.

I also only get one bounce, but its AFTER the first beat of a metronome set to autostart@0 so it causes double triggering of start points, leaving everything out of time. I was hoping there was another way, thanks for showing it to me.

[pukunui]

Yes. Something with onebang would have filtered all but the first bang from restart.

Anyway.

TMTOWTDI

-A

[amounra93]

Ahhhh....now I get it. Very sneaky. I love Max

[amounra93]

OK, this is still broken, and the other methods don't work either.

This is way unnacceptable. The only workaround that I can come up with still doesn't deal with hitting play when the transport is already running. Here's a patch with a bunch of methods that I've tried, none of which actually work.

The problem with the original method (api: live_set property is_playing) is stated above. Using a onebang to filter out unwanted feedback doesn't work, since the the transport has to be constantly running or the metronome linked to it will not trigger a transport "not_playing" event. Otherwise, the metronome has to be set at an interval too low to be acceptable (I'm using the transport to calculate swing, and there is no reason to make that many calculations). I could use another transport, but then there is no way to guarantee the order at which the two will fire. Besides (and most importantly), this still doesn't deal with the problem of retriggering play when the transport is already running.

I used the method with plugphasor~ for a long time, but I'm just finding out that this doesn't work either. There is a bug with this method in m4l that causes plugphasor~ to briefly drop out at random times, thus triggering a loop restart. I spent a day last weekend using plugphasor~ as the sync engine for my plugs in order to incorporate swing, as it required fewer objects to incorporate, and I assumed it would be higher resolution since the MSP calculations were at audio rate. I was sadly dissappointed when this method was completely unreliable: apparently calculations at vector rate are a lot slower than I thought, because the swing calculations were slower than using max objects, tied to a metronome driven transport @ 128n.

Is there any other workaround for triggering a sequence restart when the transport play is pressed?!

I've been using faulty workarounds ever since the introduction of M4L (and even before) to achieve this. I can't believe no one else has noticed this, so perhaps I'm overlooking something obvious?

Here is a patch with a bunch of methods I have tried. None of them work for me. Note that only two of them would adequately deal with pressing play when the transport is already running.

Code: Select all

<pre><code>
----------begin_max5_patcher----------
1335.3oc0atsahiCFG+Z3oHhqaQ9rcVo4h8t8cX0np.3oMifDTRna6NZlm8M
9.sLUNDiZ3Cu2zz3FJ+yu7c1vOlOawp5WzsKx9ir+Na1reLe1L6RlEl4Oe1h
cEurdaQq8xVTo+m5Ueewct+Tm9kN6x0U5UEUOdb8xMtUW886wbzwUqNrqrZq
ty9eh3W7a0UcUE6z1Wve1TVr8jKu9P2Gud2RcutW6j8B26q+X1W8W19ht0OU
V83CM50ctqDKnKQ20ePXOfY1Cxkn2dQFszV9u1+y4KQlE+474leb2mCOqepW
b5fzAGjN3KjNzgnigLkUcGObV9vxsDgYACS.Gd1VWrYPyG5j.H7YMeh.Kbkk
Jpq.U1oaaKd273Mrruoduto60rx1G1us30xAHDaRbvFjPQYzf3lCJmQCGDil
xm0KqW0padV2DjKpqafGiOUTrg3hzfP.5QYfSujdJy7aOzp6BRn7qevmXojz
5YIkvwn1r6u+91thlfrQIlD1fFOejyogCX5H8lG0+JzMMkD+M8eo29rtqbcw
0JeMwEx8X9HhK48.7AilR.8ku7qLzxfD5BB1NBgFLfaa4iU81SwvFWnEZNfr
wUKSHyG9jY7LEnA4LafDM62d3w8OUzV2D16Rd88t7.5NSJf1tX.kxxIeQwvv
otrUA3iJ+VWoWtEHbgMIDACW.4M59x6xduSoSoh55Vc23ggwVPvQ1CLNbTY.
yD1M1L4HPHBnMSZ0a6UQVPyDLLcYedxHbjwELwmwFFSklhp180AKkSMMCfHe
HzbR608G9VeyrC7Kgtpnrzb8hq.z0a344H4ox3b7QqU1n0JRBLMGIMcFliKs
NSxSog4bqSv6fBUkmnyxgbKmji2hgJRsI4Pu0ywwSFNOMmiCKElhimQn7jZL
NSzziQilFRfjPOEmASCIXISZHt0Wgv.OKjoU71WqVGpQbAeR3SjED9wJ9r8k
Gr9vKioDWzHBztZM5gb1DW8Ql5u0c8WvuFcds5PWWcUnHIm2nYpJQQRcQSr2
aDzwel80I8dQAx8h6o0zbubgSx9R1Yiq9frcbfKwoybrEnjXL1dxPkIzTrw4
IwXr8nAIRroXKvI0PrcXhIyAeH1s605MaK2YZHHTQ442vd4boFo4tjIrjn4e
1sdtsdn38nRul+Y3auECmlZM+St0c+6IijjlM+SHIP2+dF41QDPa9e3cDAiR
fcDw6IoXPugHl.wlvQY3PUGKutghOusB8DGINf1J6zcM0g4g3FuGqdlPrFHL
bBLCoD5ykp2GRv.e+mOylJxD+ecSE81ZLWsgzK.m1KoOqT0G+HiaeWLq+6Lt
s9Py5i2PGgVl3s2oM51txphtx5pStHikW16x4oxMazUmNWncka1W2eK6Ew.i
SHVM8g2tvZxjKAPMYxoOplXvxIVLbxTrFjZhEilHo2yNKmvwqIAZIuu9JlKa
YeBhim8YEKMFCsbXcHEwnIArZRFgl3vpIQLF+Bf0DOFMw.USp7HzjjCplj+t
+eXMof0uy7AMbTNoXvyIxXZRAKmhwuSAaACJbr13X3zDJhh8TvVDiLl3SbXK
hIlTvRfqqJlRXfsppHTDrLJFONVx8T6Bq6DmSMkZxntMuUxd6rOK8hIor.1f
nl8LdzjxbN7ZZz.Vvl.7COVFPSvV7hHpt3gUS1uMciKJy25C.SKa+FmOpYtS
U.xJdLFU1uTlfpJUTOAw.qp7nTECXUwhRUJfUEMJUkmjOAUWX1ZtxjeN29Yg
fPyOdxmNNVTS+.3XqQYsQgsJUdTZ5y3W1exOm+evobhws
-----------end_max5_patcher-----------
</code></pre>

[broc]

I've also experimented with different methods you describe and can confirm the issues/bugs.

So I gave up, and for synchronization with Live I'm always using the standard method as shown for example in the live.step help (p Transportation), i.e. triggering a transport object with metro at appropriate intervals. It ensures perfect start/stop and timing behavior. In particular I find the 'raw ticks' output of transport useful for creating different counters and loops by division and modulo operations.

Wouldn't it be possible to adapt your patches to this standard scheme?

[amounra93]

My frustration was definitely showing yesterday.

I was frustrated enough to overlook the most obvious solution to my problem: using the raw ticks output of the transport to detect zero at restart. I was looking for a solution to a problem that I didn't need a solution to (i.e. knowing when the play button was pressed).

I'm kinda partial to my own timing model, but I can probably adapt my system to this standard eventually. There are things I like better about the step sequencer model, though. I don't need sync info, just a bang at each beat and a trigger to restart a sequence at its beginning when there is a transport restart or a timing change.

Pukunui pointed out the raw ticks thing. This wasn't working for me when I tried it before, but now I've got a functioning model. I think perhaps before I wasn't using a quantized metronome to parse the transport.

I'm still trying to figure out a reliable way to retrigger sequences on timing changes. When I get it worked out I'll publish the results.

[Surreal]

I think i have encountered this bug in jsliveapi as well... but i will still suggest considering a small js to deal.