Prolog

Whenever we try to air some new ideas and critiques, people tend to get very angry and upset about their brain children. And our professional lives become difficult because of that. However, since we were explicitly asked to look at the ZIPPI docs, we decided to give it a try once more and risk loosing friends. So to make it very clear: we think it is a great idea to define something that can handle the transfer of musical data better than MIDI. And it is kind of brave too, to just do it. And the potential and the quality of the work that went into ZIPPI is greatly appreciated. We will only not repeat this every other sentence, but get down to business and let you know where and how we think that it can be made better. Feel free to use or ignore any of these ideas. If they turn out to be useful for you: just give us credit as contributors to the design. We hope ZIPPI will materialize (and we may even become advocates).

Peter Desain and Henkjan Honing

  Review of

ZIPPI: Proposal of a New Networking Interface for

Electronic Musical Devices (version 1.0.)

 

Let the depth of the hierarchy increase dynamically

The hierarchy is a great improvement &emdash;but why just one step better than MIDI? There are many logical groups needed for the easy modeling sound. Think of the resonant strings within an instrument, the groups of singers within a choir, within a orchestra, etc. It is simple to extend the notion of hierarchy to an arbitrary number of levels (even when it would make the note address field a bit more complex). It must be possible to address a subtree on any level of the hierarchy. Cutting in on a high level a first time will instruct the synth to instantiate that level. A toy simulation program can help synth builders understand dynamic instantiation of hierarchy levels, how they are addressed and what group of notes is affected by a message.

Define more sophisticated triggers and gates

"Articulation" (a wrong term for a generic On/Off message) is handled as an exception within the set of control parameters (e.g., it is the only one that needs the special "and" combinator).

One needs to control the way in which an instrument is excited and dampted better. E.g., a string can be plucked, slammed, damped, free to resonate with the instrument, and so on. Next to the continuous control signal of which some are predefined, some open, and that can be send to any level, we need the same full flexibility for triggers an gates. Think of sustain pedal of a piano, damping an individual string on a guitar, hammering on sounding guitar strings and playing the piano "stumm" to allow strings to resonate. We are not sure if these messages should have a continuous value too, or just specify points in time.

Define responses to inquire messages at MPDL level (not at lower levels only)

E.g., it must be possible to inquire for the names of the presets (programs) of a synth to be able to make controlling it from the computer easier (making a menu of program names) To evade the emergence of many company and synth-model specific dumps, we propose a more or less generic way to inquire capabilities by linking it to the ZIPPI control messages. A special header will turn a normal note descriptor into a question about this message. So "inquire program-change 1" would give you some info on this patch, E.g., a name. In the same way a synth can be asked if it handles a certain control parameter. It could even be asked if a certain note is still on, or what its amplitude at this moment is (It will save a lot of adminstration at the controlling side).

Define treatment of higher level updates for notes that are still sounding

E.g., define what a program change does to sounding notes. Not always it is possible here to come up with good answers (for program change, leaving sounding notes untouched is often reasonable, for other messages one wishes immediate changes). The best solution would be to have an extra flag in the messages to the higher level to specify this.

Preprocess the note descriptors within a message and effectuate them all at once

Define when the separate contents of one large ZIPPI message will be effectuated. It makes sense to let the synth wait for reception of a whole message, preprocess all of them and that effectuate them all as closely in time as possible. In this scenario a sensible re-ordering of constructs has to be performed to prevent signal processing artifacts, such that the user does not have to worry anymore about, E.g., sending a volume update in the same packet before a trigger. A ZIPPI message should be an atomic command

Treat data-reduction over the address space a bit more sophisticated

• Send the same data to a range of notes at once: next to the new-address message (p13 of MPDL ) a way to send the same data to a range of notes (just allow two note addresses in a MPDL data message).

• Send range of data to a range of notes: supplying two full messages and have the device interpolate between the note descriptors, e.g., set up equal temperament by sending lowest key, lowest pitch and highest key, highest pitch within such a note-scale. This neatly moves, e.g., keyboard parameter scaling from the synth-specific to the protocol.

Turn modulation into a general mechanism for data-reduction over time

• Change of parameters over time: make the modulation function (p 11 of MPDL) more general (less ad-hoc) such that it can handle updating control signals in segments, e.g., a linear segment.

Splitting it into two (oscillators and segments) would make the definition of this part easier (e.g., depth and offset are not natural parameters for expressing control segments). Segment messages are something like: change this parameter to reach this value in this amount of time and stay there, using this type of curve (linear, S-shape, exponential) with these parameters. Or "start changing this parameter at this rate and keep doing so until a new parameter update or segment is received." These definitions have to be very precise (publish programs!) such that they can be used in encoding continuous data (e.g., the bandwidth analysis in the ZIPPI guitar description will come out much more sensible). And ZIPPI continuous control devices (because they know how fast they can be controlled) can send appropriate (linear) line-segments. So the ZIPPI guitar can send much less data. This data-reduction can be added to MIDI-to-ZIPPI converters too, to have old controllers benefit from new techniques

Define the treatment of allocation and overflow

Because of the large address space, it will be essential for a device sending ZIPPI notes to know about the capabilities of the synths and do some complex allocation. It is better to let the synths handle this themselves: define ZIPPI overflow that will be emitted from a synth &emdash;containing all notes and corresponding messages that cannot be handled by it. Setting this up would only entail instructing a synth to send this overflow as plain ZIPPI messages to a certain other device. Then, finally, synths can be easily extended. Furthermore, allocation can be done better because the synths themselves know better which notes are still sounding. Having the last overflow in the chain returning to sender will also give an easy check for note density problems.

Define a file-format and add structural descriptions

• Define a ZIPPI file format, and do it earlier and better than the standard MIDI file format specs. Less is better in this case (and this has consequences for the ZIPPI protocol itself). We want a file to be able to be played and to capture it at the other end without loss of information. This means that data needed in a file, like text annotation, and rests, have to have corresponding ZIPPI messages. This makes a file format just an agenda of time stamped ZIPPI and simplifies playing and recording it. It has, however, to be defined in the report. It is important to consider, e.g., ZIPPI addressing for text messages so that they can be used for annotation of ZIPPI data. E.g., a specific note on a certain instrument in a certain family may be indicated (textually) as an ornament. We do not propose to define standards for these annotations &emdash;just the availability of them will make it possible to have an annotated ZIPPI file as input/output for programs for score editing, multi -track sequencers, etc., that would otherwise need their own file format.

• A simple grouping mechanism based on a PART-OF relation would (generically) allow bars, beats, voices, phrases and other structural descriptions to be defined. A group needs a start message with a specification of its parts a name and type, and a end message. Its parts specify a section of the hierarchy (all notes of instrument one, these specific keys, etc). One could even envision an extension of ZIPPI in which control messages can be send to these structural units, like "play any chord a bit softer," with abstract group-start (name=chord, type=parallel, parts = instrument 1 and 2) and group-end messages setting up control that cuts through the hierarchy and is more dynamic in time. The hierarchy could be seen as a special case of this more general mechanism (with pre-defined group-starts for instruments containing notes and families containing instruments). This would widen the scope of programs that can use ZIPPI as file format, just supply the hook with which application specific data can be attached to a ZIPPI group structure.

Address MIDI-ZIPPI compatibility more extensive and in a practical way

This is important for gaining acceptance in existing studio environments.

• Define simple encapsulation: ZIPPI inside a MIDI SYSEX and MIDI inside a ZIPPI message.

• Define as good-as-possible software translations (publish programs!): From restricted ZIPPI to MIDI (e.g., interpret instrument as channel, or translate to mono-midi, allocate notes on channels, translate fractional pitch to pitch bend) and from MIDI to ZIPPI (e.g., translate pitch bend to fractional pitch).

• Build hardware translators and encapsulaters based on these conversions. In this way. e.g., existing MIDI controllers and synths can be used in an all-ZIPPI studio. (Even without any other ZIPPI capabilities, the routing capabilities plus MIDI inside ZIPPI encapsulation would make a wonderful upgrade for a MIDI studio in which the wires don’t have to be changed anymore. This would make a good Trojan Horse. The real ZIPPI devices could be added later easily.) N.B. the encapsulater devices should be able to receive the device address to send their data to. In this way, a central controlling "patch bay" computer has only to emit data when the patch changes and routing overhead is essentially zero.

Don’t propose old technology for future standards

We may have not had access to the detailed lower level specs, but we think that using old network technology, i.e. trying to have ZIPPI come out of the MIDI din-plug, is smart but will turn out to be a bottleneck. Why not use fast links (optical, coax?) directly to the devices? When ZIPPI will have become widely accepted, this technology will be very cheap. And synths will have fast digital audio data output connectors anyhow.

Prepare for ZIPPII now

At some point in the distant future ZIPPI will have to be extended. Define hooks for that at all levels of the messages and explicitly reserve them. Some foresight will prevent a lot of trouble here. Define ways in which ZIPPI parsers can be defined such that they will be able to parse any future extension of the protocol (but loosing info of course).

Do conceptual exercises

We find the most productive way to think about ZIPPI and its capabilities and limitations is to imagine it controlling a whole orchestra of physical modeling synths. In that way all concepts of instrument construction, playing style and performance control&emdash;and possible problems with their treatment in ZIPPI will come out.

Give the defining document the proper style.

Start at the higher levels, and work down. It is quite off-putting to have bits and bytes hanging around at page 1 of the MPDL while the good new abstract ideas are one treated much later. This is a formal language specification plus semantics thereof, its translation to bit strings has to be considered detail at this level. Cut the commercial nonsense in the ZIPPI Guitar part (the "unprecedented" control, etc.) this doc ought to evolve into a formal defining report, not some marketing brochure. Likewise, remove the Virtual Reality (yet undefined) point at page 7 of the network summary. Or add Spaceship Control (yet undefined) too.

Supply a Program Suite

Supply a suite of well written and documented programs for ZIPPI, e.g., a simple parser. This will give implementers a head-start, define semantics more thoroughly, and pin-point possible problems. Write the programs as clean and clear as possible &emdash;avoid optimization.