Stephen Powell

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.

Transport: transport @name test1 @clocksource live

Metro: metro 4n @transport test1 @active 1

Transport: transport @name test1 @clocksource live
Metro: metro 4n @transport test1 @active 1

odd-transport-behaviour-in-m4l

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:

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

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

If you use @clocksource live you will be synced to LIve's transport

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.

Odd transport behaviour in M4L