Cycling 74 » Topic: Odd transport behaviour in M4L http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/feed Wed, 19 Jun 2013 16:21:59 +0000 http://bbpress.org/?v=2.2.4 http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-64170 <![CDATA[Odd transport behaviour in M4L]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-64170 Fri, 31 Aug 2012 22:04:19 +0000 tsuki Hello All.

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.

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

Thank you.

]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-231441 <![CDATA[Re: Odd transport behaviour in M4L]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-231441 Sat, 01 Sep 2012 13:05:52 +0000 ShelLuser 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:

– Pasted Max Patch, click to expand. –

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.

]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-231442 <![CDATA[Re: Odd transport behaviour in M4L]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-231442 Sat, 01 Sep 2012 16:06:01 +0000 pid hi tsuki

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.

]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-231443 <![CDATA[Re: Odd transport behaviour in M4L]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-231443 Sun, 02 Sep 2012 18:34:11 +0000 Andrew Pask @tsuki

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

Try @clocksource internal

Cheers

-A

]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-231444 <![CDATA[Re: Odd transport behaviour in M4L]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-231444 Mon, 03 Sep 2012 00:29:00 +0000 ShelLuser @Andrew

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

]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-231445 <![CDATA[Re: Odd transport behaviour in M4L]]> http://cycling74.com/forums/topic/odd-transport-behaviour-in-m4l/#post-231445 Tue, 04 Sep 2012 01:08:34 +0000 Andrew Pask 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.

-A

]]>