Re: [linux-audio-dev] ecasound status update

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] ecasound status update
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Wed Nov 29 2000 - 12:45:44 EET


On Tue, 28 Nov 2000, Paul Barton-Davis wrote:

> if you look at the docs on OSC, you'll see they used it to implement
> control over direct-to-disk recording in one example. i don't think
> they are really that different. OSC is more generic, and doesn't
> provide a CLI of any kind - you would still have to do that. Its
> really a way of naming and communicating with an address space that
> happens to be well suited (as far as i can tell) to all audio
> applications. i think it would good for us all to pay attention to it,
> but i understand that we all have time constraints.

Yes, OSC definitely looks useful. It's just that for ECI,
parts that do overlap in some sense, are the ones that are
already implemented in ecasound. The address space issue
is one very close to ECI. OSC uses a hierarchy based approach,
where regexps are used for addressing multiple targets.
Ecasound has an OO-style approach, where you first select
the current object(s) and then issue a command. OSC's
approach is clearly more scalable, but results in longer
command syntax. Longer commands are not a problem to
today's computers (as stated in OSC docs), but unfortunately
are still a problem to most today's people. :) More about
the human-vs-machine issue later...

Another problem is announcing the address space. Currently
the address space is not made public in ECI. The API functions
know very little about the values that are passed between
the engine and the client. The goal of course is to allow
ia-mode commands to be added, removed and modified without
breaking source nor binary level compatibility. This seems
rather tempting after having spent lots of time trying to
maintain compatibility of various C++ libs (although much
of the problems tend to be caused by GCC2.xx and the old
libstdc++). It seems that OSC does provide a mechanism
for dynamically registering the address space, but whether
this is enough, I'll have to investigate further.

But I see no reason why I shouldn't support OSC in the future.
In a way, yes, ECI just defines one protocol to communicate with
ecasound, so from ecasound's point of view, OSC support would
just be an alternative control channel. And OSC does
have many interesting features. For instance timestamping
is something that has been on my todo-list for a while,
and OSC seems to have a ready solution to it.

> => /ecasound/chains/0/1/thingamajig 32.45
> => /ecasound/chains/0 add a_component
> => /ardour/track/1/loop/set 235363 3636363

This does look nice. Basicly you could automate your
whole virtual studio using timestamped OSC scripts.

Hmm, but the above syntax-sample also clearly shows
that OSC is aimed at app/module-to-app/module communication.
I try to make switching between user-to-app to app-to-app
as seamless as possible... This wouldn't necessarily
make sense for OSC, but it does for ECI.

-- 
 . http://www.eca.cx ... [ audio software for linux ] /\ . 
 . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Nov 29 2000 - 13:17:02 EET