Exit Only

Something I've noticed when I try to use transport with rewire is that a synced metro object will stop if the clock source of transport is changed from internal to rewire, or back. This is true even if the active argument is set to 1.

Sometimes this is not a big deal because I can just turn the metro back on, however if it is buried in a sub-patch somewhere this can be a hassle.

Something I've noticed when I try to use transport with rewire is that a synced metro object will stop if the clock source of transport is changed from internal to rewire, or back. This is true even if the active argument is set to 1. 

Sometimes this is not a big deal because I can just turn the metro back on, however if it is buried in a sub-patch somewhere this can be a hassle. 

metro-and-rewire-problem

Nick, I'm not saying you're expecting too much, but what would @active 1 have to do with the metro not stopping when the rug is pulled out from under everything? If we were to fix this, you don't seriously want me to stop only the metro objects whose active attribute is not set, do you?

Lets say I have a synced metro, with active 1. I stop the transport. Its clocksource is currently set to internal. Metro will stop, like it should.

So then I set transport's clocksource to rewire. If I start the host (Logic 8.02), the metro will not start up again. When I manually bang transport, it updates correctly so I know it is running.

If metro just missed a beat or stopped temporarily, then yes I would say I'm expecting to much. But if the active argument is set to 1, I would expect the metro to run when the transport is running. Currently, this is not the behavior I'm seeing. 

Lets say I have a synced metro, with active 1. I  stop the transport. Its clocksource is currently set to internal. Metro will stop, like it should.  

So then I set transport's clocksource to rewire. If I start the host (Logic 8.02), the metro will not start up again. When I manually bang transport, it updates correctly so I know it is running.  

If metro just missed a beat or stopped temporarily, then yes I would say I'm expecting to much. But if the active argument is set to 1, I would expect the metro to run when the transport is running. Currently, this is not the behavior I'm seeing. 


The active attribute starts the transport when the metro object is instantiated. It does nothing else.

I would say that the best behavior would be this: if the sync-ed metro is "on" when you change the clock source, it should stay on and keep running if the new clock source is running (and the transport, if switchable, is on -- note that with ReWire sync you can't control whether the transport is moving or not).

However, I don't think making this work is a matter of gigantic importance at the moment. I assume you just care about this for development workflow purposes. If you really want to switch among clock sources as performance technique, you can set up multiple transports set to different clock sources, run them simultaneously, and send the transport message to your metro objects to switch them.

I can understand if this isn't a priority. I was hoping it would be an easy fix.

In the mean time, I'm currently setting the global transport to rewire before I open any patches I'n working with. This way, the metros I expect to be on from the get-go will be. I hope this helps anyone who runs into the same problem. 

I can understand if this isn't a priority. I was hoping it would be an easy fix. 

In the mean time, I'm currently setting the global transport to rewire before I open any patches I'n working with. This way, the metros I expect to be on from the get-go will be. I hope this helps anyone who runs into the same problem. 


If you change the clocksource of transport to rewire while the global transport extra is open, the global transport extra will not function until it is re-opened. I guess this is the best illustration of the problem I can come up with.

metro and rewire problem