This page explains all the possible ways to control the transport in score.
There are three ways to control transport:
Manually, with the “play from here” feature which allows to seek at a given point explicitly.
In a pre-determined or processed way with a specific process which allows to control the speed of its parent interval.
Through an external transport system. For now only JACK transport is supported.
Before explaining how to use the actual feature, it is important to explain the semantics of transport in score, as due to the interactive nature of scores, behaviour of transport can be somewhat surprising.
Consider the following score:
This of course begs the question of: what should happen when asking score to transport at any given point when the score has not started playing ?
The policy taken by score is to follow the visual duration set for intervals. That is, that visual duration even for a fully interactive interval is not entirely devoid of semantic meaning: it can be taken as to mean:
The duration that I expect this part of the score to last.
In particular, this means that any interactive point before the point to which the transport is performed will be triggered. All intervals that are visually at that point will be positioned accordingly.
That is, here are successive transports done in the above score.
Consider a score where a sound is being played through an external sound player, controlled through OSC. This sound player’s API is:
player:/play <bool> player:/volume <float>
The score is:
Now, if we want to play our score from the middle of the automation, if nothing else was done other than positioning the playhead and starting playback, the
player:/play true OSC message would never be sent and the remote software would not start playing, thus making the feature somewhat useless.
Thankfully, score takes this into account: by default, when running a transport action if the score is not playing, every state leading to the transported point is computed from the beginning of the score. If multiple states send different values, then the last one is taken into account: that is, if making a transport after the end of the example score shown above, the player will receive the messages:
player:/play false player:/volume 0
The software settings contain two options to control this behaviour, one for the first time a transport is done, and one for subsequent transports when execution is already running:
A more complex case is related to conditions.
In this case, a choice must be made when processing the conditions. However, sometime we may need to explore the different outcomes of a score when doing transport: for instance, if a condition requires a performer to be at a specific place on the stage, we may want to be able to perform a transport without having to ask the performer to go to the designed place for the transport to take place as expected.
Thus, the condition inspector provides the “offset behaviour” setting which allows to toggle whether the condition will be true, false, or evaluated with the live value in the device tree, when it is evaluated during a transport operation:
This feature allows to move the global time bar. To use it, right-click on a scenario and hit “Play from here”:
You can also use the “Play” tool:
Either the play tool or a right-click menu allow to launch the content of a single state at any point.
See the documentation of the Tempo process.
Right now, only JACK is supported. The plan is to include synchronization with SMTPE, Midi Clock, Ableton Link, etc. over time.
The setting is currently in the global software settings: score can act both as a JACK client or master:
It is possible to set a start marker by right-clicking into the musical metrics area, at the top of the score.
When a start marker is set, play / pause will always start from this point: this is mainly useful to play a specific part of a score quickly in succession.