It seems this debate is how to represent OSC messages in a sequencer. I've thought about this before, and the idea I always had in my head was something tracker-like, where you would assign columns (or rows..) to a message path, and specify whether the arguments are ints, floats, etc. For each argument the column would contain subcolumns with fields allowing editing of these values. Any row that is all "nil" would mean "do not send a message." The editor might allow a special column type called "note" which is represented on-screen as a note name (A#3 or whatever) but sends out the value as an integer or float. Alternatively the editor could be told the min/max values of the subcolumn and represent it as horizontal bars or a line plot, etc.
I even started working on such a thing once, with the intention of controlling sequences for custom synths written in e.g. Chuck or PureData. However, I never got far with it as I had other things to do. In any case, in this paradigm, the user would define a patch in Pd (or....) which accepts certain control or trigger messages, and therefore the sequencer would need to be told what messages to send it. No need to "standardize" the messages for any particular representation, since it would be different for each patch anyways. (The "sequence + patch" would be considered together as the music file.) What I like about this is that it would allow a user to use whatever program he/she wants for sound synthesis, but have keep a consistent sequencer interface. You could even use multiple back-ends for sound synthesis in the same track. p.s. thanks Jonathan for bringing up libmapper. For those who don't know, libmapper is an attempt to create a "glue" layer for OSC-supporting programs. Instead of standardizing on a set of messages, the idea is to instruct sending programs to translate their messages into the format required by the receiver, including any data transformation (scaling, etc). This allows programs to use any message names they want, keeping the usefulness of readable, program-specific semantic naming schemes, while still being able to connect to each other. Still under heavy development, but it's quite functional, web site is at http://libmapper.org Steve On Sun, Mar 4, 2012 at 4:27 PM, Albert Graef <[email protected]> wrote: > On 03/04/2012 06:32 PM, David Robillard wrote: >> >> What do you mean by "pick the OSC addresses that I want"? > > > I mean those symbols with the slashes that are the first part of any atomic > OSC message like /foo/bar 4711.0. Usually such a symbol would denote the > particular control that the value applies to. When using OSC as input to or > output from automation, obviously I'd have to specify which OSC addresses I > want to be mapped to which automation parameter. > > However, I'd actually prefer a kind of separate OSC track which would be > connected to OSC inputs and outputs and listens for all OSC messages on its > OSC inputs, no matter what the addresses are. So (an ASCII representation > of) the contents of such a track might look like > > # delta OSC addr value > 0 /foo/bar 0.78 > 10 /reverb1/wet 0.3 > 5 /foo/bar 0.66 > etc. etc. > > By these means the OSC track would just record any messages that it receives > on its inputs, and I might then map them to the appropriate automation > parameters on other (audio and MIDI) tracks in the DAW, or just have them > played back via the OSC outputs assigned to the track, in order to drive > some other application like Pd. > > Dave, will you be at LAC in April? I'd really like to discuss this in more > detail with you, but it's much easier to do this in a room together and with > a whiteboard and a data projector within reach. ;-) If there's enough > interest, maybe we could do a "control beyond midi" brainstorming session at > LAC? Maybe Rui wants to join us there, and I know that some guys at CCRMA > are also interested in this. I guess that the organizers can allocate us a > time slot and a room with the necessary equipment if we just ask for it. > > Albert > > P.S.: Rui, apologies for hitchhiking your thread. I hope that you will > forgive me over a glass of good Californian wine. ;-) > > > -- > Dr. Albert Gr"af > Dept. of Music-Informatics, University of Mainz, Germany > Email: [email protected], [email protected] > WWW: http://www.musikinformatik.uni-mainz.de/ag > _______________________________________________ > Linux-audio-dev mailing list > [email protected] > http://lists.linuxaudio.org/listinfo/linux-audio-dev _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
