[Octal-dev] 0,1,infinity redux (yet again :-)

[Dave O'Toole]

> (which means L&R channels are higly correlated) but as n independent mono 
> signals
> played separately on each output of the audio device(s). Thus, when the 
> processor
> (usually) gets an interrupt from the audio device(s) for the output buffers 
> to be
> filled, the mixing routine has to calculate every audioFX, automation (...) 
> applied
> on each independent track and transmit the resultant sample blocks to the 
> device(s).

Oh, I see. This sounds like support for devices with more channels than
just stereo, i.e. surround sound etc. To address such devices in OCTAL
(well, eventually) what I'm planning is an extension of the "Master"
output idea in Buzz. If we have output machines each managing one of the
output channels (the channel number can be a machine parameter) you can
route the desired audio to the channel you pick by connecting them to
different machines. 

If you're talking about having n-channel reverbs, i.e. extending all
signals beyond stereo, that's different. This probably won't be possible
with OCTAL--one of the first big debate issues during OCTAL's inception
was whether or not it would do this. The engine, the signal router, and
its interface (this was the clincher, actually) are much simpler when
signals are indivisible and easily interchangeable. 

The multiple-out-machines approach I outlined above doesn't break the UI
or engine design, and probably won't be too hard to implement in the
future. (I hope multi-out hardware becomes cheaper/more widespread.
Otherwise I won't be able to test it.)  

Given that the world's music distribution formats are all stereo I don't
think this is a bad tradeoff. There isn't much danger of quadraphonic
stereo becoming popular (this was supposed to happen in the 70's but it
didn't). This might mean that OCTAL won't be optimal for specialized
tasks like installation music. 

> could you explain a bit more what is the Auxiliary Input ? Is it a stereo one 
> ? How

It's essentially a compromise. Something like this was added to Buzz
after it became popular, to make things like Vocoding work.
(unfortunately, the implementation was unstable.) It lets a normal audio
signal plus a specially "marked off" second signal (for modulation, etc)
come in. 

> Is it possible to divide/merge multiple aux to control an
> input signal ? 

The basic model shown in Buzz lets you duplicate output signals (i.e.
send them to more than one sink) as well as automatically merge signals
into a single input, so if I understand you correctly, "yes." 

> Vocoding is one (great) thing but let's imagine you have a stereo
> track processed by audio plug-ins : what about using external signals to 
> control
> these FX, a bit like multiple not-so-Low Frequency Oscillators ?

The current model has several possibilities. One is that the Aux signal
can be used as a high-data-rate control input, which can be fed by any
other signal. This can be used to have an "lfo machine", although I
don't know if this is a great idea (the signals wouldn't be
audio---connect it to the right place and it works, but to the wrong one
and you blow your speakers.) 

For control routing I've been looking at alternative architectures--all
the "classical" unit-generator systems I've used that do this tend to
have about 63 control i/o nubs sticking out of every box onscreen, and
63^2 lines connecting the different nubs. This isn't acceptable. Going
from "just stereo audio" to "n-channel audio and control" using the
current UI is not much of a solution, since it breaks the UI. What Buzz
showed is that it's still possible to get the work done in an
environment like this. By offloading parameter control routing to the
pattern/sequencer subsystem, it cleaned up the "digraph" to a usable
state. I suspect this is why it's so popular--the compromise worked.

I'm looking at ways to similarly "offload" some of these tasks.

Keep in mind that not much of this is set in stone. 

-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal