The transmission and management of data, parameters and more generally of information within a system or between multiple interactive systems, represent the first problems that electroacoustic musicians and composers have to face. The problem was so relevant that it affected the nature and genesis of the work itself; as always happens, important technical questions radically intervene in the compositional processes.
In this series of articles, we will try to trace a path that describes the most important steps in the history of data transmission means and protocols. It will start from Voltage Control then move on to the birth of MIDI protocol, we will mention other protocols that have tried to counter its hegemony (endorsed by the musical instrument industry) such as SKIN, the ZIPIA, FUDI (specific for Pure Data). Finally, we will deepen and dwell at length on the latest born among the data transmission protocols: theCSO Open Sound Control. A lot of attention will be paid to the OSC since it is not a simple antagonist of MIDI, but a real revolution in the field of interaction between systems comparable in importance to that which occurred when we passed from Voltage Control (analog domain) to MIDI (digital domain).
Part Three
In the previous article we analyzed the birth and development of the MIDI. Furthermore, we have also emphasized some of its limitations, such as the lack of flexibility in the face of specific technical needs. And with technological developments, further limitations come to be highlighted. In the 90s there is a growing diffusion of computers that allow the execution of increasingly demanding tasks. New interfaces like the IEEE commonly called Firewire, capable of transmitting a considerable amount of data with higher speed than traditional connections. Radio frequency-based wireless technology also begins to develop. The development of these hardware technologies goes hand in hand with that concerning network connections: networks are born LAN, WAN, the internet is stated etc. In this new scenario, the MIDI shows major limitations and begins to design new protocols and communication systems capable of fully exploiting these new technologies: ZIPIA, the SKIN and FUDI.
ZIPI - Zeta Instrument Processor Interface
This research project was born as the MIDI in the commercial field thanks to the interest of Zeta Instruments, today a well-known manufacturer of electrified bowed instruments.
This industry finances the research project held at the CNMAT extension (Center for New Music and Audio Technologies) Of the Berkeley University. In the 1994 ZIPIA is announced to the international scientific community through a series of publications on Computer Music Journal. It is a protocol designed to take advantage of new network technologies and is based on observance of the model OSI - Open Systems Interconnection (standard protocol for communication, later superseded by TCP / IP). Physically, the connection takes place through a star network with a hub in the center which allows greater connection flexibility, overcoming the concept of daisy-chain, i.e. the serial interconnection of devices. The protocol does not depend on any type of specific physical interface, even if cables have been used for the research studies Ethernet with connectors 10Base-T.
ZIPIA uses a message system based on a protocol called MDPL - Music Parameter Description Language. In the intentions of the developers there was the intention to completely overcome the logic of events and channels MIDI introducing three hierarchical levels of addresses, Namely 63 families, each made up of 127 instruments, each with 127 note thus managing to reach the number of 1,016,127 note addresses distinct:
- instruments in a family they can be brought together by different physical devices. This type of hierarchical organization has been designed to obtain a meticulous control of the individual synthesis parameters and to favor certain types of physical controllers non-standard like wind controller e guitar controller that make use of greater and more accurate control parameters. This is an important aspect of the study, being the Zeta Instruments an unconventional tool builder interested in implementing research results on its products. Some messages MDPL derive directly from the MIDI, although they have different names to avoid ambiguity, but most of them are new and are based on very different but innovative logic controls: they refer to advanced programming parameters such as modulations, envelopes e 3D spatialization of voices, as well as specific messages for guitar controller, wind controller e drum controllers. The resolution in bit of the message parameters is a multiple of 8, extending the resolution of the midi from the typical 7 bit a 32 it's more.
Types of ZIPI Messages:
The control messages for the basic synthesis are:
• Articulation - 'note on / off' in MIDI
• Pitch (note number and offset in 0.2 cents)
• Frequency (inHz)
• Loudness - 'velocity' in MIDI
• Amplitude - 'volume' in MIDI
• Even / Odd Harmonic balance
• Pitched / Unpitched balance
• Roughness
• Attack character
• Inharmonicity
• Pan Left / Right, Up / Down, Front / Back
• Spatialization distance and azimuth / elevation angles
• Program Change - immediately and future notes
• Timbre space X / Y / Z
• Multiple output levels
• Time tags
• Modulation rate / depth / wavetype
Messages for controller specific (performance oriented):
• Key Velocity / Number / Pressure
• Pitch Bend Wheel
• Mod Wheels 1/2/3
• Switch pedal 1 (Sustain) / 2 (Soft pedal) / 3/4
• Continuous pedal 1 (Volume) / 2/3/4
• Pick / bow Velocity / Position / Pressure
• Fret / fingerboard Position / Pressure
• Wind flow or pressure (breath controller)
• Embouchure (bite)
• Wind controller keypads
• Lip pressure / frequency
• Drum head striking point X / Y position and distance / angle from center
• X / Y / X position in space
• Velocity in X / Y / Z dimension
• Acceleration in X / Y / Z dimension
With ZIPIA we also see the introduction of Tag-Time for the synchronization of the messages, which became necessary when faced with a star connection and no longer serial which forced scheduling. We also witness the attempt to enter the ability to perform Query within the system and to obtain reusable information about the parameters in use. The introduction of the Tag-Time and queries interprets the renewed need for a technology capable of making systems interact and not just connecting them together. We do not dwell too much in the technical description of the protocol since the project ZIPIA it was soon abandoned. The system has never found use either in commercial or scientific and research fields. The reasons are:
• Complex hardware; ZIPIA although it is not tied to specific physical interfaces, it required more complex and expensive wiring than the MIDI (star network, hub).
• The use of the communication protocol OSI. ZIPIA is based on this very reliable but extremely complex protocol, which is why it has not had a great diffusion and has been supplanted by the TCP / IP.
• MDPL has an unusual addressing scheme which, compared to the MIDI, requires a substantial increase in complexity. The handling of 1,016,127 single synthesis states was far beyond the hardware capabilities of the time. The same developers as ZIPIA they suggested that there were practical limits on the simultaneous number of notes and programs.
• While having the conceptual overcoming of the MIDI, in developing ZIPIA you failed that purpose.
• Market of musical instruments still linked to MIDI. This was still considered sufficient and cheaper to carry out most of the required tasks. Furthermore the complexity of the MDPL it did not favor its diffusion.
• Introduction of the "FireWire"(IEEE) as a physical communication device in equipment, capable of guaranteeing superior performance in data transmission. It has simpler interface requirements, requires no hubs, supports hot plugging, and also includes an isolated scheme capable of distributing power.
However, it is worth noting the merits of this attempt which laid the foundations for the development of CSO. A couple of developers who had worked on the ZIPIA, Matt Wright e David Wessel, form a new research team with Adrian Freed, Amar Chaudhary e Sami Khoury to develop CSO, which despite having nothing in common with the ZIPIA, addresses many of the issues raised with the development of the latter:
• Explore the possibilities offered by new network communication technologies.
• Exceeding the serial link.
• An attempt not to be tied to any particular physical interface.
• Increase in data transmission speed.
• Introduction of tag-time and the ability to perform Query.
• To increase the number of types of parameters and to increase the detail of the controls according to the use of non-standard controllers.
• Messages for unconventional controls, envelopes, loudness, spatialization, etc.
For complete technical details regarding theMDPL refer to the official document published in 1994 on the Computer Musical Journal (Winter 94) "The ZIPI Music Parameter Description Language" by K. McMillen, D. Wessel and M. Wright.
SKIN
SKIN is part of a set of classes in C++ named PCS - Synthesis ToolKit created by Perry Cook.
In particular PCS is composed of synthesis algorithms and signal processors written by P Cook and the G. Scavone with attention to multi-platform functionality, al real-time and ease of use. PCS is extremely portable (its main platform is the C and C++) and it's open source. Perry Cook began to develop PCS at CCRMA Stanford University in the early 1990s.
Here are some notes written by Cook and taken from the original distribution of PCS:
"STK was created without having any hardware system as a reference. These examples are intended to be a tutorial. They are the basis for the continuation of my research and the starting point for a software synthesis system. The basic motivations are to create the necessary generative units to synthesize, process and control what I want to do and teach….
A question at this point could be raised: “but with CMix, CMusic, CSound, CShells, CMonkeys etc., why make a new set of functions for music synthesis and processing?”. The answers are:
1. I needed to rewrite many things I had done into something generic so that it could be ported to different platforms in the future.
2. I needed to organize and document these things in a way that would ensure that they were understood over time.
3. The classic difficulties of many people in trying to implement physical models, namely:
- • Problems understanding the documentation and / or moving from theory to practice;
- • The tools for physical models are a matter of "great pain", so giving a stable and understandable starting point is beneficial.
4. I would like to try some new tools with Modal Synthesis and implement some classic patches for FM.
5. I'd like to re-implement some of the physical models I've covered in some of my articles. But I'd like to do it in a portable way, with modules that can be quickly connected. I'd like these tools to be connectable to other objects...".
In this set of classes C++ a call is included SKIN whose task is to transmit and receive data and parameters. SKIN was designed to be compatible with the MIDI and expand it if possible, so don't override it and replace it. The differences with the midi are:
• Promote readability and portability. Text-based messages are used, with understandable names where possible. This enables any language or system capable of formatting text to generate SKIN. Likewise, any system capable of reading strings and transforming fields into strings, float and int can use SKIN for the control. SKIN it can be manually written to files through normal text editors.
• Float numbers they are used where possible. Note numbers, velocities, control values, etc.. they are all represented in code ASCII. The byte in midi format they are preserved so that, coming from an interface, they can be inserted directly into messages SKIN.
SKIN was written to be extensible and adaptable to numerous applications:
• Integrated sound synthesis for video games and virtual reality.
• Applications dedicated to notation and al mixing.
• Applications real-time.
• Applications that do not require control for sound synthesis.
• Synthesis controlled by JAVA.
A basic message SKIN is a line of text. Only three fields are required: the type of message (an ASCII name), il tempo (a delta or an absolute) e the channel number. By channels we do not mean those midi which are however supported. The channel number is a longint and can refer to a number of socket, an Machine ID, an serial number or tag that identifies an event in a summary. Other fields can be used.
The fields in a row SKIN they are limited by spaces, commas or tabs. The parsers SKIN it only operates on one line at a time, so a new line means a new message. Messages
multiples are not allowed on a single line. Message types include standard midi message types such as: NoteOn, NoteOff, ControlChange, etc. Many types of messages are implemented that do not follow the standards of the midi, where possible, it is desirable to use them as external midi so you can use them in real-time.
To conclude the description of SKIN we highlight its nature open source; the MIDI and the failed attempt to ZIPIA they both arose from commercial needs. With SKIN instead, thanks to the individual needs of a scholar, we return to the free sphere of research and experimentation. Portability is an element to which great attention has been paid, as well as for the readability and accessibility of the code: typical needs of a researcher who takes into account the possible implications of future studies. skin by its nature it is extensible and integrates with a variety of other applications. However, it too remains conceptually linked to MIDI, in fact it was not meant to replace it. Use part of its messaging and try to integrate with it, indeed we could speak of an attempt to expand it; remember that the intentions of Cook there was to pass specific messages not standard including external midi, precisely to facilitate integration with the systems in use. However, we cannot yet talk about a standard protocol and its large-scale use since we are talking about a single class that is part of a library (PCS) written in C++.
We are there however, through the basic concepts of ZIPIA e SKIN, getting closer and closer to the technical peculiarities of CSO.
FUDI
FUDI is a network protocol used internally by pure data to communicate between the process GUI and the process of DSP.
pure data is a programming language for audio in real-time developed by Miller Puckette.
The same protocol is also used to save patch in the pure data. FUDI is the acronym of 'Fast Unified Digital Interface' (or in agreement with M. Puckette, any other acronym).
It is based on the use of strings very simple in which messages are separated by a semicolon. The messages are made up of blocks separated by whitespace and numeric blocks represented as strings. FUDI it is a packet oriented protocol. Each message consists of one or more atom, separated by one or more space characters, and is terminated by a semicolon and a atom is a sequence of one or more characters.
FUDI is used with objects:
• netsend / netreceive - these classes they can be used to carry messages PD through a TCP or UDP socket. Both are part of the distribution Pd-vanilla.
• netserver / netclient - these are part of maxlib and allow bidirectional connections between multiples client and a server.
The reflections concerning FUDI are roughly what we made for SKIN; we are faced with a system in which the operative freedom of the researcher and the scholar is maximum and constitutes the main element. The syntax is reduced to the bone just to leave the developer maximum autonomy. In fact, these are a few objects capable of sending and receiving strings and all the time management, addresses and data typology is entrusted to the development of the programmer.
At the next episode that will deal with the communication protocol CSO
Maurizio Zoccola
