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

[Ola Sverre Bauge]

Dave O'Toole:
 > Yannick Chapuis:
 > > (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
 > 
 > Oh, I see. This sounds like support for devices with more channels than
 > just stereo, i.e. surround sound etc.

IIRC, surround sound is just encoded in a stereo signal,
using some funky tricks with inverting and co.

 > 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. 

I was going to say I couldn't see how this would be hard. 
Then I thought about what to do when connecting eg. a
5-channel output to a 2-channel input and got an instant
headache.   So okay, I'll give you that, since converting
between mono and stereo is the only really unambiguous
conversion.

I do, however, think that binding the API to the mono/stereo
model is a mistake on the principle that interfaces should
be as general as feasible.  Why not an array of buffers,
with 0 defined as left/mono, 1 as right, and higher numbers
as undefined/custom?

Case in point:  Looking at the draft spec/alpha sources, I'm
only seeing one aux buffer.  What if I want a stereo aux,
for stuff like really strange vocoding?

 > 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.)  

One possibility for multi-out without hardware support could
be broadcasting surplus channels over a LAN to relay
machines hooked up to the relevant speakers.  Mmm...
overkill.

 > 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. 
 
Never say never.  It's been what, ten years? since the music
industry made the middle class rebuild their record
collections.  They might want to pull something silly with
DVD.  :-)

OK, so what'll probably happen is that they start selling
albums and music videos on one disc, but you get my drift.

Anyway.  For installation music etc, channels will probably
be either so similar as to be easily split from a
stereo/mono signal to their final destination or so
completely disparate that it won't be worth it to implement
n channels, and as mentioned above, surround is really just
a wacky stereo signal; as the Buzz surround machine
demonstrates, you don't really need anything special for
this.  Heck, I've seen XM modules with surround sound.

There might be some unnoticed field where n-channel machines
would be useful, however, which is why I think it's wrong to
bind the API to *only* support mono/stereo.

<snip>
 > 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.) 

Please, you're making me drool.

<snip>
 > 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.

It can, however, be a complete pain in the expansion ports
if you want to get around it.  I say this is as a man who
created possibly the worst circus tent machine layout in
history to get around Buzz's mono input limitation.

 > 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.

One thing that struck me is how all tracker interfaces,
including the prototypes lurking around in the alpha Octal
sources, currently are bound to the 12-note A440 system.  I
suppose it's only a matter of building alternate
interfaces/frequency translation tables to add alternate
systems and tuning temperaments, but hmm.

I guess the people who care about tuning temperaments are
the sort of people who scoff at MIDI and would never touch
trackers, and for different note systems you'd be better off
writing another tracker interface?

Going off on a tangent re interface, why is there no
floating-point number entry?  Seems such a waste to have
samples as floats only to be limited by integer granularity
in the interface.

Oh, and the API spec made a lot of sense once I sat down and
studied it.  Good stuff.

        -Ola <address@hidden>