New subject: OSC sequencer idea (was: Qtractor 0.5.4 - Echo Victor shouts out!)

4 Mar 2012

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 &lt;Dr.Graef(a)t-online.de&gt; 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:  Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
 WWW:    http://www.musikinformatik.uni-mainz.de/ag
 _______________________________________________
 Linux-audio-dev mailing list
 Linux-audio-dev(a)lists.linuxaudio.org
 http://lists.linuxaudio.org/listinfo/linux-audio-dev 