Re: Greetings and a couple of other things

[David O'Toole]

> but let's go back to char* for a second. one thing i see char* being
> useful for are for holding filenames. there's currently a machine on
> sourceforge called pwgen that loads wavetables from files. the way it
> loads wavetables is it looks for files named '*.oot' in the current
> directory. but it would be cleaner (you don't have to have all the
> wavetalbes in memory) and nicer (the wavetables could live anywhere in
> the filesystem) if you could load one wavetable at a time by making
> one of the parameters a filename.

The approach taken by pwgen won't be neccessary once Octal's wavetable
is implemented. (I'm sorry the docs don't mention more about this topic
yet.) Basically each song will have its own wavetable, and its storage
in memory will be managed centrally by the host (with each wave getting
an ID number and associated attributes, as in Buzz.) This means: 

1. More than one machine could access a given wave, something that is
pretty important to allow. Each machine loading their own waves would
make this inconvenient and wasteful of memory, unless there is
centralized storage for the wavetable, in other words what Octal is
doing :-). 

2. Machines can easily access multiple waves without having to load them
manually.

3. Machines can avoid ever dealing with the file system, different audio
file formats, different system calls, different ways of storing audio
attributes (loop point etc) in a file. Instead the host system defines a
basic sampler architecture (not unlike the DLS standard that Ed
suggested) and a single way to get synchronized access to wave data and
attributes. 

(NOTE: this leaves alone the issue of whether the wavetable actually
includes copies of the wave data, or whether it's possible to link to
outside files so that they can live in different places, as you were
saying. However there's a neat solution for that.)

For technical reasons #3 is the most important. This isn't in the
guidelines yet, but basically you have to avoid I/O system calls
whenever possible. If a call blocks and the rest of the signal network
is waiting on the sound you're trying to produce, you are basically at
the mercy of the filesystem to get back your CPU time. Meaning the audio
starts skipping and the audience starts to look at you like you're Milli
Vanilli :-). Calls that can take a long time, or worse, block on file
descriptors, have got to be avoided. One exception is stuff like memory
allocation, where it is usually a big waste to pre-allocate all the
memory you might use (and it might still not be enough.) 

All this means, basically, that machines themselves are *out* of the
resource management business, and shouldn't touch the filesystem. One
exception is loading a fixed table from disk during ox_init() since that
is done when the library is loaded, but I'd suggest avoiding that too. 

But while I don't see filenames as a particularly strong argument for
having string parameters, there might be others. For instance, there are
more resources than just waves---like formant descriptions, or patches
for an FM synth, or some plugin that requires equations to generate
sound. Many of these can be described by plain text. While there may be
some formats that only one plugin would use, I think for the majority it
would be best for the group to come up with, say, a standard format for
describing FM instruments, so that multiple synth machines could make
use of them, and also so that filters and editing tools could be built
for the individual text files bundled with the song.  

I guess what I'm saying is that I want to make a distinction between two
categories: 

        RESOURCES:
                - potentially in many different formats (one example is 
                an ordinary wave sound)
                - nontrivial storage requirements
                - accessible by multiple machines
                - need helper programs to edit each type
                - actively requested from system 

        PARAMETERS:
                - all float
                - tiny storage
                - sequenceable, live control
                - sent to a particular machine
                - can all be edited by a single program, even if made 
                for different machines. 
                - passively recieved


Editing a patch (full set of parameter values for a particular machine)
does not require a special program for each type of machine, because
they are all floats. The widget builder gets all the information it
needs from the description provided by the plugin. 

But wave editing needs its own kind of program, formant descriptions
would probably need a program to generate them and edit them, etc. 

My suggestion is: instead of sending a big resource or its filename to a
plugin when the data is needed, load the resource in Octal and then send
the plugin its resource-ID number (just like wave numbers in any
tracker.)

I think we can still get done the kinds of configuration you want to do,
I just don't think the parameter system is the best way to store it. I
would rather use the parameter system to select among resources that are
loaded by the user. 

> sound loops, like old-fashioned tape-loop effects. the sound-loops are
> intended to be arbitrary and reside in files. now, i can hard-code the
> filename into the machine (which is how it works now) or i could have
> the filename for the loop be a parameter and editable (and
> sequenceable). of course, you'd need the entry widget functioning for

Right, so with the scheme I've suggested, the user would instead select
his loops and load them into Octal's wavetable, and then the ID number
would be sent instead of the filename. (And the data would have already
been loaded, meaning the plugin doesn't have to run out and try to load
a 20 MB audio file just in the nick of time.) 

There is nothing wrong with testing it this way (particularly since I
haven't implemented the wavetable :-) but I think for the future it is
much better to keep all the waves together. 

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