metro and rewire problem
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.
----------begin_max5_patcher---------- 689.3ocyW00jZBCE8Y7WQFl9ncGRPDsO096nyNch3UMagDZRn51c1+6MjfeV QAkk5KA4RDNmy8buI4sAd9yDa.kO5Knui77dafmmMTY.up687ynaRRoJ6z7S DYY.W6Oz8LMrQaimAZo.oKjbERrXAZ8JfiRREI+TIJjI.hoPp0LcxJX91+bJ iCIhBt8MPpBtPv0bZFXeqeSxnoamNatMlX1KelDsMHuHiwSAsEc38AEE5sQC phlSMecFe4OjPh1wYRzjmBFhFaGIAjxKgidJ.87AnQw9iEMXyiKi99fAkCCu SE6kBkFQQFAHOELZFRWBNERajQ4q9sRNvcibfISKU.rUNvQwNUoakCsX4xT3 Lj.O8hjHWBJiLR0LA+PHiGYyfkCAUC6f6wDGeAhGfsTdGiOg2t2h90bvMeeV oo84af9YfRQWB+iaflnY+FPeB2pDOdxY0LxMx+Q1BfnclfZy60IK2llTukXb K70WhdNF4n2+kz6QcB4ZPx2mOaVldzEyz0TcLJNvkKw2W8AwIZ3PacF1Umzi NDCPmAxVIXwsv5PtTkgkxjvPaoQvUaIdIK0Pj+LJeYuoAXb2HBQjGDMn9NEj toSQzIsH9vZTLqPqE7ywjftgIgQkne5jlxj6vXBqM.ulcDhGyQe8WETt13Ob 2UsTW6VoqiVnykeGO0oGiuYm7sqVMYEBIrlIgVoOgc0FApZzG4ZzGz2M5OuW RKobUtPpaW6uVnISulmAG61ULI9da+UcYQpfVyON2rNVOsea6AnN4zaV7WF+ XQ1Yrpvw1cai1Sg4fRy31sOb3jlbzjVwlOG3GdFhL17bgAoUfnlTdiwzjFfo VBoRKbjoh2cJA71eemHsI.E2uZGo60t9PjB5WUZ7iWhaziGjLeM7UPTbuinq pQ8qHE9Am1L279f+BH5lQtB -----------end_max5_patcher-----------
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?
ok, well maybe I wasn’t clear on this.
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.
one last thing-
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.
Forums > MaxMSP