[linux-audio-dev] Modular Synth OSC API

From: Dave Robillard <drobilla@email-addr-hidden>
Date: Fri Jan 07 2005 - 23:31:03 EET

Hi all,

As many of you know (hi #lad) I'm working on an OSC controlled modular
synth called Om.

I'm just finishing up subpatching and polyphony now, so things have hit
the stage where the OSC "API" is important, and needs to be thought
about and stabilized. What exists right now is just randomly added
commands to get functionality working, so I won't even mention it here.
Best to start from basics. I think I'll tacke it one issue at a time,
and make a final RFC kinda proposal for people to comment on.

The reason it's important is that I intend for Om to be useful from
scripting languages for algorithmic composition / soundmangling /
experimentation / etc - not just one 'official' client. So the API
needs to be clean and clear as possible, since real people are going to
be dealing with it directly.

So. First issue, "command" versus "object" namespace. Right now the
API is like so (roughly):

/patch/connect patch1 osc1 out lpfilt in
/patch/set_control foopatch osc1 freq 440.0

etc. The reason for this is simple: liblo didn't have pattern matching
support when I wrote it. I think it would be clearer to have paths for
the node/patch names rather than as parameters, ie

/patches/patch1/nodes/osc/set_control freq 440.0

Another minor thing would be to possibly distinguish commands from
object by the use of a # symbol, as in
http://www.opensoundcontrol.org/papers/query_system/ making:

/patches/patch1/nodes/osc/#set_control freq 440.0
/patches/patch1/#add_node foo bar baz

I don't think anyone would really disagree this is cleaner than the
command-based version but I have one concern: performance. I don't know
if the pattern matching in liblo would have a significant enough
overhead to introduce any latency. These commands are used to control
everything in realtime, so latency absolutely must be as low as
possible. (Steve?)

Comments? (There will be more issues to come, assuming anyone cares)

-DR-
Received on Sat Jan 8 00:15:14 2005

This archive was generated by hypermail 2.1.8 : Sat Jan 08 2005 - 00:15:14 EET