Subject: Re: [linux-audio-dev] ecasound status update
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Nov 29 2000 - 01:41:13 EET
>On Tue, 28 Nov 2000, Paul Barton-Davis wrote:
>
>>> is to take a subset of functionality provided by libecasound, write a
>>> simple (my favorite word! :)) API for it, and port it to various
>> any particular reason why you didn't want to use OSC ?
>
>To be honest, this was the first time I heard about OSC. But there doesn't
>seem to be much overlap with OSC and ECI. Ok, here's some marketing speak:
Well, we must have different interpretations. I took your comparison
with gdb+CLI, thought of the use of OSC, and they seemed fairly
compatible.
however, given this:
>designed these same principle in mind. So it's a minimal set of commands
>for adding, setting up and removing ecasound objects (exactly five types:
>chainsetups, chains, audio objects, chain operators and
>controllers).
its easier to see why they wouldn't overlap.
>So coming back to OSC, which is described as "A protocol for communication
>among computers, sound synthesizers, and other multimedia
>devices". ECI is more close to "Language-level access to ecasound
>interactive mode" - so they are two totally different things.
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.
=> /ecasound/chains/0/1/thingamajig 32.45
=> /ecasound/chains/0 add a_component
=> /ardour/track/1/loop/set 235363 3636363
etc.
--p
This archive was generated by hypermail 2b28 : Wed Nov 29 2000 - 03:09:40 EET