Subject: Re: [ecasound] A new controler?
From: Kai Vehmanen (k@eca.cx)
Date: Fri Dec 08 2000 - 09:00:30 EET
On Thu, 7 Dec 2000, S. Massy wrote:
>> # store the audio buffer
>> -estore:id-number
>> # the controller itself
>> -kg:fx-param-low,low-value,high-value,id-number,low-ampl,high-ampl
> Now this surely is not as simple as I had thought it, but a system
> like this would add a lot of flexibility to ecasound; I mean there
> would be other doors opened for new things.
Ok, I'm starting to see the bigger picture. Whoa! :) We could add a
generic "audio stamp" chain operator type. These chainops would have a
unique id-number, for use in identification. Now so far nothing new
here, just a new effect type that doesn't modify the signal. Btw; what
would be a good name for these objects "capture", "slave", "audio stamp",
"shadow object", "audio bucket", :) ... ideas?
Now the next step is the critical one - we need a way to add new types
that take a reference to an "audio stamp" as one of their arguments. These
objects can be pretty much anything: controllers, effects, audio objects,
GUI widgets, etc, etc ... but the mechanism is always the same. They have
access to one "audio stamp". They don't know where it is located, or when
it was generated, but they can analyze the audio information. And one
thing to note, it would be possible to assign the same "audio stamp" to
multiple "stamp consumers"!
Now there really seems to be lots of potential here:
- control effect parameters based on signal amplitude/volume
- control params based on the amplitude of _another_ audio stream
than the one being processed
- calculate the left-right balance (stereo-image) and use that
for controlling effects
- control params based on audio pitch (using fft-analysis)
- use one audio signal to control multiple other streams and
their effects
- ... and list goes on ...
> What kind of overhead would there be in such implementation, would it
> be speedy enough for real time?
Actually this is another prime example of my "easy access to simple
functions, obscurity allowed for complex tasks" paradigm! :) The key
here is to keep the engine simple. As long as new features can be
added without making any changes to the engine, we're safe. Engine just
processes audio objects, chains and chain operators. It doesn't care
whether they are complex or not, just as long as they behave according to
the high-level interface. If you create heavy objects, the engine run
slower, but it'll still run just as fast as before when using lightweight
objects.
Most of ecasound's complexity is in fact located in object creation
(typical for OO-designs). That's where you have to do the difficult stuff.
In this case, we have to somehow make a connection between the audio
"stamps" and the "consumers". But once the objects are created, we can
forget about the dirty details. We just have to be able to make even the
most complex objects look (and act) like any other object of their type.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Fri Dec 08 2000 - 08:09:52 EET