[Octal-dev] The 95% solution

[Dave O'Toole]

Ola Sverre Bauge wrote:

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

Right; this is why I didn't go out of the way to implement multi-out
support, even though it looks very possible to add this easily down the
road (the multiple-master-machines thing)

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

In this case, adding the capability *might* not be a problem for the
interface. Since a 5-channel signal probably won't happen too often, it
won't bother the user unless he/she uses such a machine. Then again, now
the engine contains a (possibly buggy) piece of code that virtually
no-one will use (or have the hardware to test effectively.) 

The same would now be true of the interface if the extended channels
were to be accessible to the user (however rarely this might happen.)
After all, if the UI doesn't let you do it, the feature effectively
doesn't exist. 

This would be fixed if you could only connect 5-channel outs to
5-channel (or more) input machines, but given that there aren't likely
to be many of these, one might never get the chance to connect them to
anything. 

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

Maybe I made a mistake in the docs; there should be at least a
commented-out line reading 

samp* xlin, xrin;

Denoting a left and right aux channel. If I've left this out somewhere,
can you point it out to me so I can fix 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.

Yeah, networked streaming audio. I dunno, I think if you have the money
to set this up at home, you might be using a 64-channel hardware mixer
anyway :-)

> industry made the middle class rebuild their record
> collections.  They might want to pull something silly with
> DVD.  :-)

I have my doubts that the CD format is going to be displaced by another
physical storage format. Even if it is, I don't think true multichannel
is going to replace stereo+surround-sound, which is almost as good. The
change would be expensive (everyone needs a new player and stereo, and
the entire recording industry needs new equipment: everything from mics
to reverbs to mixers.)

If, against all odds, this migration really did happen (let's say in ten
years, barring revolt or antitrust against the RIAA) I think there will
be ample time to extend OCTAL, if it hasn't already been rewritten by
2010. Remember that Donald Knuth rewrote TeX in the early 80's. 

(It will also probably happen much, much faster than people rewriting
all their octal machines to support multichannel, which would also need
to be done if anyone was to take advantage of the capability.) 

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

At larger shops here, they have some of these for sale, but they're kind
of expensive. Given how jacked-up CD prices already are (in the USA at
least) I don't see these having that much more success than any of the
other weird videos-on-music-cd formats (CDi, etc) that the industry has
come up with--at least with respect to displacing the CD itself. There's
always been a market for concert videos etc, and this may transition to
DVD, but I don't think this will impact the CD market unless they stop
making them. 

[installation music snip]
> demonstrates, you don't really need anything special for
> this.  Heck, I've seen XM modules with surround sound.

Wow, which tracker? :-)

I've checked out a decent amount of installation-music (so far, I think
minimalist Mika Vainio's "Onko" is my favorite.) From what I've read,
these installations are looped or non-repeating montages of material
that last for days. I think there's a lot of custom software or
programmed cd players going on. 

I don't know that OCTAL is a good fit for this kind of thing anyway.
Maybe OCTAL 1.0 won't ever be used for 64-channel OMNIMAX movie
soundtracks, but they're probably already using their own really
super-duper system for this. 

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

Haha :-). What was your solution? 

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

The current codebase calculates an A440-based equal-temperament scale
and stores it in a table. But I imagine it would be very easy to allow
the user to select different tunings. (This could be done at
compile-time now, if you rewrite the bit of code that makes the scale.) 

I suspect it'll eventually move over to storing the frequencies in a
file, which you can replace to get different tunings. No, this means it
probably won't be easy to switch tunings in the middle of a song. 

As long as machines get the frequencies through the standard OCTAL
utility functions, this should work. 

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

Well, MIDI does kind of suck :-). Anyway, if you need not just an
alternate tuning but something totally off-the-wall, not based on the
12-note naming system, we could add a format type to the OX_API (cf.
struct param_spec) for whatever this happens to be. Then the machine
that uses this could translate this number into frequencies itself.
Machines are free to ignore the default frequency table, and make a
shared library with another weird one. 

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

I don't think there's any good way to put FP cols in a tracker UI,
especially if it's the "change one digit at a time" bit like in Buzz.
(I.E. what happens if you put two dots in?) Hex integers take up much
less space, too... I suspect we'd be limited to only one or two float
parameters. 

The thing I was trying to get across with the Aux input was that if you
have such a control parameter that's really better suited for float (and
hence not too good for direct human input IMO) use the Aux input and
drive the control with the floating-point output of other machines.
Which can be algorithmically generated, or waves, or whatever. Should be
pretty cool, actually. 

Essentially the Aux input is multipurpose. This is a nice way of saying
"use it for whatever special-case stuff it isn't worth
extending/breaking the system for." If the Aux In gets used for
something weird all the time, then it's time to consider adding a
feature to OX_API. This is the conservative approach to controlling
interface bloat. I doubt that designers of "elegant" programming
languages will like this. Niklaus Wirth would probably not be happy with
the design of any tracker, least of all OCTAL. Then again, I am not
happy with his Pascal, so sue me :-).  

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

Thank you---I'm glad this seems to be working out. Of course, it isn't
perfect (yet :-). I'm going to add one more callback function to the
spec, called "ox_track". This is how a machine will know when its number
of tracks has changed. The way it's currently handled isn't very good
(requiring the machine writer to poll the value of "tracks_changed"...
yuck.) 

I'm also coding the C++ wrapper so that people can write C++ machines,
which I suspect will be the norm given the way the straight C version
handles "state objects". This is, as far as I'm concerned, the only
rough spot in the C version. C++ includes direct language support for
exactly this technique so it'll be easier to do them in that way. (Ooh,
Bjarne Stroustrup isn't going to like that I just used C++ as a "better
C" given his current ideas on how people are supposed to use C++.) 

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