Odd transport behaviour in M4L
Experienced Max programmer, new to M4L.
For some reason, when naming a transport in a M4L patch, and naming a metro the same to output bangs at that transport’s bpm, the metro still responds to the bpm changes of Live, rather than the transport it’s been named as.
Well, a test case would have been helpful ;-)
Alas, I haven’t worked with transport objects that often but to my knowledge they’re tied to Live’s master transport all the time. See the testcase here:
----------begin_max5_patcher---------- 1553.3oc6ZszbihCD9rmpl+Cp3b1THYvO1ZOjYp8xV0bZulJUJYPPzDPhBj8 jrSs6u8UO3oMfwIwApL9BXK0H070c+oVs3me9Syr1vehjYA9cvsfYy9orkY5 1TsLqngYVw3m7hvYZAshn6HWK3ggQDqqxEXGNkgiI62+sv6JEgsMlxhHB8f. q0Jeq3flMsIdNgXzMKKvcE8Q80SCey2+MzxxgOAK7dfxBuOk3ILOzb2kWaeE .BUWQyKtVMRI3ToRKHo2SX3MQjFpPFdGw+drPjR2rUPp9UVN3TfNp29nsDdP Q6kcTeFh3rvi.QMjOl6KwKkz1REusAjxdTMfZ0wtqgf6S5reJKfqUmVUfsLp wnzd27TeRZmCsOInmdyRHD+HZrFua+sKSPRx5Qy2Qyn4VrVkfHcrxcc3AAVW Iuwp7gZJ5SIbFgI5QavLFWfETN69RaX2fl34bWo1sJxfodlp39s5EgDn1gEp fhip4M2N19.OUbp9h4JMRFRkKw+94OY9UwOxuKuc0oQlHipDRySmjIl9O6jI tCfLYkslFAVbcpPlb.DcgL4BYxHQlbbewyDYBi7CYfbYTrf7j1NXIm3TNvgA tQjhYYIRMF3SCz+AbC1SH0Z.rcxEzQHWB3rpW+ujJQLvW4Q9VcR9rAyB6f.x Y.DPtZpG35U5aqpy.oTkL5+j6tjCsuXR4gkg24kQdde.xZWMD3LMIjaBOWXi uvFOpo18dSEKcdyvgjC4hyHh2Ih1N3TP8wofPJdjkZlk4nqck7KKNKTrchOB prKZHXNvYbwI69vInsd8GmEpqKzf1YBnNgMHbVWKBtpO7XgFHlaVExt35zZy AWVK5xZQShcFL1qEQCYbYnaD06w8IHd2oYg8VASngKAB0Euz09LxyNoAI2iy 89KOFsn+0qufQRLp2MXilu1.Rq+0Fj5cS2vU1uWfTWUyIAf25S4smsmc6fj8 PAo5.Ab.QTKWTkGb+UiowXYxZoQpcAzHxNRZFkypaVmYgSRp09do8Ei+NWOV tUKpJgCSavp1RIpTYLCw5pEWKmjpWL86k9xBG8MmU0SkUZ1Bi3dOR7arvukL UrSXL3IDVahWbYOQorjTRlL4IcxQGLw3sQh6af2nqaWf.rGo6GuoiQYZJVgo TeNSoHMeVU6ESozivTOJ2FZuVDFNosGWv4Qavo0xwrxnKiMvLZLVPTaHTG9a W8jz3jTpIUxpFMoi8PlWJOJp4nY5ZWac4KcL7H+f5KdXu7Aad1vMb6pG61ri 8hg83wwpbdupl.kAx+A3qaoQ9fm4aSMwz.RPfzq.HiOHMdF4tPHd7slWYT8d Zcud8v.LDVf8YBbZzQajA4D.t50WWa1.355NBcxL1HK2RFxy.Z+2VudXKMbS QD6bUb5bG0U4E39uqpo0iGY3gFf7cXQ.+k.KWUrKCS0Q10okwEY1Mtor4KOf mdBXY91GQKyhiYYxOI0org4CYHiy.CYfnKgLuuVFzvBYJJJvjzv7m5zI.xDV ETO46cDMlJFnw5ApuOg85VGuKvc8wvVyVYPt46AbRBteQmijfC9FcG4CXDvx iF.nSyBYB.VkeR38ZifiiMJHkG+Q0JMvU1g15aqWLRVolkOXuRHDsMTh2+W2 VGT2VGzotShCJ7RFMjonpJ+USno9ZBGCqMeGH4YQY19wHvZcLrlxl9PMbXPc dZQuRntVEBTassqcYq0Bk.cXDxj6b1q3UM+k..apQ9jLAkUV3jaKcr1Wvpke av+DS8S3TlHWGA2MbumWj5aOT029MU8K5npnX4mKqb5jt.8cnr8Wfo9JrzPJ 9zQquU2SaqhGFw2fixqBY0wLd9956p9l6tQMc09x6Dj3DN.tvFbimplhF+AP Ts0MGTIvW+hKAtpHZWUdKHhi63GsIU60Oe9wOqJy2WBZk6I+M7YDrImQt0Y+ fsBazAAYnlAOcDgoNOo5RcX3UGgVs557VqbtSYka4TV4lOkUNmSU4P4m.kIH 5MPQUelOGWQGIPzd5papYEMnHC3nnavAQoLN51v3hGGcawfhYGGcyYPjcu+5 FZ9DlCwYH5FZjVec4fTNmWsxoZPd6+UrsybB -----------end_max5_patcher-----------
I use this in a normal Liveset (so 120bpm, 4/4 signature). When trying to change the signature you’ll trigger an error. And even though I set the transport to 160bpm you’ll notice that it still follows Live no matter what (bang it, check the output).
As such my conclusion.
You’ll also notice that by using a live.toggle (or Max toggle) you can’t start/stop the transport as would normally be the case.
also; don’t be fooled by the helppatch. The moment you open the helppatch for transport while in M4L edit mode (or if you simply have a Max license as well) then at that moment the transport won’t utilize the Live environment but that of Max. So; opening the help patch would suggest that transport can control metro, while within Live metro will only listen to Live’s global transport.
Just my general theory combined with a little experience. As said; I haven’t messed with transport all that often.
i’m not sure what is going wrong for you here, sorry. it should work.
what you are doing should be perfectly possible (if i understand you correctly). simply make sure that the different wished for named transports are named first, then you should be able to clock to any of them. in m4l, if you use @name live it will reset to live’s clock. take a look at the pluggo "cyclotron" device that comes with your distribution for a simple example. of course, none of this will work in ‘edit mode’. device needs to be instantiated in a set.
controlling the other way round (live’s transport) is also possible but a little more involved. for this you have to go via the API. but be careful about multiple same devices that do this in the one set. you can make various ‘set’ patching to make it appear everything comes from the same interface (as your transport stuff).
post a patch if trouble.
If you use @clocksource live you will be synced to LIve’s transport
Try @clocksource internal
This kind of intrigues me (as said; haven’t used transport that often) but there seems to be an issue even if you set the clock source to internal.
If I change the patch I shared earlier and change the clock source to internal as well as the tempo (adding a . in order to use a float) it still doesn’t work every time.
The main oddity is that the transport seems to be stuck to 120bpm even if you use the @tempo attribute and/or have set Live’s tempo set to something else.
Another oddity seems to be that if you pull the device in and try to start the transport using the toggle then it doesn’t start all the time. If I start the Metro first and then the transport it does seem to start every time.
But even so; always stuck at 120bpm, I can’t seem to get the transport to run differently (I’m on 5.9 btw).
I’m not sure if I am doing exactly what you are doing but with various tests using Max 6 as the MFL runtime it appears to be working fine.
If there are problems they will be fixed in Max 6 only.Please feel free to post bug reports to support.