Controller blocks

[SpencerPark]

In some instances such as piano specifically, there are multiple performances happening simultaneously. This may be both hands playing the same instrument. In these scenarios both blocks are tightly coupled and could be controlled by a higher order block, the controller block.

This block would not have any output of its own but would have a namespace and scope. It also has access to the output streams of the performers it controls.

Proposed syntax

Definition

Defined similar to regular blocks but have the additional control clause which specifies the blocks the controller needs access to. In this clause there is an option to provide a local alias for the block name.

def block PianoLH
def block PianoRH
def block Piano controls PianoLH as Left, PianoRH as Right {
   // ... config
}

Note that the original PianoLH and PianoRH are still able to perform on their own but it is unlikely they will need to in this scenario.

Performance

Performance looks very similar to the standard performance with the exception that the performances are nested inside the controller's scope allowing access to it's local memory space.

Piano {
    playChord -> C
    Left {
        [playChord]*<w>
    }
    Right {
        4 * {
            [playChord:it]*<q>
        }
    }
}

Multi-performance

Similar to the multi-block performance statement where the same definitions are evaluated for all blocks, the same may occur at the top level of a controller block. To improve support for this feature an implicit boolean should be defined for each of the blocks the controller controls. This may allow for similar but slightly diverging executions based on a test for which block is executing it.

Difference from branches (#19)

Branches are anonymous and share the memory space of the controller (a plain block). They therefor must synchronize at the end of the branching since the performer cannot diverge in time after the branch is complete.