[LAD] OSC sequencer idea (was: Qtractor 0.5.4 - Echo Victor shouts out!)

[Stephen Sinclair]

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