Subject: Re: [ecasound] A new controler?
From: Kai Vehmanen (k@eca.cx)
Date: Thu Dec 07 2000 - 23:11:59 EET
On Sun, 3 Dec 2000, S. Massy wrote:
> Alright, here's an idea for a new controller, but maybe it's already
[...]
> So I guess the controller would have a format akin to this:
> -kg:fx-param,lower_amplitude,upper_amplitude,closed_value,opened_value
Now this is a very interesting topic. :) Unfortunately implementing the
above is not easy. Shortly put, the problem is that it's currently
impossible to route audio data to a controller. Similarly, it's impossible
to route control data to a audio stream.
You can get around the latter restriction by using a combination of a null
input and a chainop that produces audio:
ecasound -i:null -o:/dev/dsp -el:sine_fcac,440,1
...would produce a 440Hz sine wave as an audio signal. But doing the
reverse is more difficult. So taking another look at your example:
> -kg:fx-param,lower_amplitude,upper_amplitude,closed_value,opened_value
... this would be registered as a normal controller (=a black box that
produces values in the range of [0,1]) -> wouldn't have any audio
available for analyzing. Hmm, what if we introduced a "shadow" chainop.
Something similar to the audio loop devices (you register the same object
multiple times). Hmm, you'd have something like:
-i:file.wav -o:/dev/dsp -estore:88 -efl:1000 -kg:1,20,2000,88,0.2,0.8
# store the audio buffer
-estore:id-number
# the controller itself
-kg:fx-param-low,low-value,high-value,id-number,low-ampl,high-ampl
The controller analyzes audio captured by -estore, and uses it to control
the filter cutoff. Now this is one way to do it ... better ideas anyone?
> Does the above make sense? Would this be of any use?
> I, at least, see many situations, apart from the example given above,
> where it could be useful.
Hmm, the syntax might prove to be difficult to use, but apart from that, I
agree that routing audio to controllers has much potential. We could for
instance turn all gates into -kg style controllers. They are now
implemented as effects, which mute the buffer if the gate is closed, and
otherwise let the signal go through. Controller could do the same,
outputting 1.0 when open, and otherwise 0.0. If controlling an amplify
effect, you'd be emulating an ecasound gate (as they now function).
Hmm, this reminds of one feature that might prove useful for gates.
Instead of muting the audio, we could have gates that would truncate all
buffers if the gate is closed. Let's take an example:
ecasound -i some.wav -o target.wav -ge:20,20,0
At the moment, ecasound mutes all input until the 20% start threshold is
reached. Then it lets the signal go through until we go below the 20%
end-threshold. Then back to muting again. Now I'd change this so that we
would actually drop the samples instead of muting. This way, ecasound
would start writing to target.wav only after the 20% threshold is reached.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ .-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Thu Dec 07 2000 - 22:21:56 EET