Friday rants on cue scripts etc. on the Jamoma-devel list today. Tim suggests thinking about things like cuelist display editors
etc. in terms of structures. Below is my reply:
When thinking about this one has to have an idea of what one wants to use it for as it is likely to influence design decisions. A solution might be perfect for a certain kind of use but inappropriate for other approaches. As such I don’t think we should aim for just one approach towards how to control Jamoma.
Still I would always try to see how two criteria could be maintained as far as possible:
- modularity
- usability
I think that we should be cautious about adopting the cue and event terminology and in the process attempt at creating rigorous definitions of the terminology we settle for. We should definitively review common conceptions used for compositions controlling light for stage etc. but that should be used to inform our discussions and decisions but not to limit them. I believe that most common solutions have been made to work for a conventional and linear way of composing in time. That’s were the main commercial marked is regardless of whether on create technology for video editing narration (text) score composing DAW or stage light. We have to come up with solutions that might work for this but that will work equally well when challenging the conventions of the linear narrative.
So if I should start of defining an event this would be one way of doing so:
Event: A single control message to be executed
Events could then be bundled. Bundles will contain a mix of vertical and horizontal structure:
Vertical: several events fired collectively and instantaneously
Horizontal: a time-based stream of time-tagged events
A timeline will be mainly horizontal a cue mainly vertical but the RAMP and WAIT syntaxes introduce a horizontal component in the cue as any MIDI chord represents a degree of vertical structure in a stream.
If a bundle can be triggered using a single control message it is per definition just a special case of an event. Thus a bundle can itself become part of a bundle.
To me this aspect is important. A traditional division into cue and event might suggest the existence of two levels only.
The reason why struct doesn’t ring with me is that it seems to suggest containers of fixed size. I don’t think of events as something to be contained but rather something to be executed. Neither do I see the size of bundles as fixed. This is the main reason why I have problems with pattrstorage as a system for controlling patches.
I would instead think in terms of an event being comparable to a single line of code while cues are functions:
- Once the function is set up calling it looks and feel the same as executing a single command. So a function becomes a way of extending the programming language introducing new commands that can be executed. There is one important and interesting exception though: The added possibility for passing arguments back and forth which itself is an intriguing idea for extending how we conceptualize cues.
- A function can itself call other functions.
This to me is critical for the system to be modular.
From a user perspective it has to be human readable and easy to modify on the fly in any way: adding or taking away change values reorder substitute etc. So if it is important to know e.g. NUM_CUES this should be figured out by the module itself by scanning the file when loading it kind of “compiling” the script.
