This sets up an environment in which you can build a player, build a gui for that player, and respond to midi and keyboard control.
The gui is quite optional, and in fact non-screen-staring is one of its primary goals.
You can set a custom gui function. This can use any combination of .gui style and normal Views The Interface can be placed on any other windows of any style. You may decline to customize your gui.
If you set any of these handler functions: onNoteOn onNoteOff onPitchBend onCC then appropriate midi responders will be enabled when the player starts to play and disabled when it stops. This includes if the player is being started/stopped by external mixers, PlayerPool etc.
KeyDown/KeyUp keyDownAction keyUpAction (only when guied, only when focus is within the MetaPatch's views)
Interface is great for having no gui at all. Personally I use the gui stuff to set up parameters for performing, and then when performing I use no gui, only MIDI controllers and key commands.
The function that builds the player is actually an InterfaceDef. These can be created and stored in the same fashion as Instr and kept in the same folder. You can then address them by name, supply paramaters as you do for Patch and you will get an Interface which will use the gui and midi functions from the InterfaceDef.
interfaceDef | |
args |
the control change handler is installed (via CCResponder) when play starts and unistalled when play stops.
It can be a simple function:
a CCResponder that responds on a specific number. (note: tell it NOT to install itself, because the Interface will install and uninstall it when play starts or stops)
or a custom class:
whatever it is will be asked to respond to 'value' :
i | |
a |
argargs |
agroup | |
bundle | |
private | |
bus | |
defWasLoaded |
b |
f |
... args |
function |
function |
stream |