(maxmsp) global synch’ing metro explanation

To follow up on my last post on my global synch’ing metro patcher, here’s an explanation.

Transport

Since I’m using musical time, I have to use the transport. I want to be able to start and stop the transport, and to change tempo. Rewinding isn’t completely necessary, and I don’t care about transport location, so I’m not reporting measure | beat | tick values.

Global Metro

The global metro sets the “quantization” interval, or the time interval that synchronizes time changes in the other metros. The initial value is the quarter note (4n) because the loadmess object sends a 2 to umenu, choosing the menu item at the index location 2 (the third item in the menu). Loadmess sends the argument as a message when the patcher is finished loading. It is a great object for setting initial values in number boxes, umenus, and other changeable user-interface objects.

The global metro sends a bang at the specified musical time interval via a send (s) object to any receive (r) objects with the same argument (syncBang).

Playback Metros

Each playback metro looks familiar, except for the way time values are sent to the metro. Time values are sent from the umenu object to the right inlet of message box. The time value is stored, but not outputted from the message (because it comes in the right inlet). When the message receives a bang via the receive syncBang object, it is transmitted to the metro object to change the playback speed.

The patcher is not perfect. Since metro objects update their tempo on their next bang, you can still get the metros out of sync. But it is easier to make changes to the metros all together.


Comments

Leave a Reply