Re: Those API revisions, plus some thoughts

[Neil Nelson]

David O'Toole wrote:

> Initially I was resistant to doing it this way... I wanted everything to
> be thunked into one big file. However, then the host needs special-case
> code to deal with any kind of data resource. It might be better to allow
> a general resource facility where the host loads the data from disk, and
> gives the machines access to it.  What really got me thinking on these
> lines is something Neil was saying a while back, about a machine that
> used a frequency-spectrum file to define a sound, rather than a straight
> waveform.  If these are simply files, we can make UNIX-ish filters for
> them and have other programs operate on them or generate them, just as
> with wavefiles. 
>
> This sounds pretty simple to do. Instead of specific wave maps, we'd
> have "resource maps" that identify a file resource based on some input
> parameters. Or something to that effect. Let me know what you think. 
I have not checked out any sound synthesizing packages that may provide
this ability for Octal, but my current work is based on the assumption that
almost any useful sound can be described as a set of frequency threads,
where each thread is described with an amplitude and frequency change
envelope/curve.  Frequency changing for the same sound/note is used less
frequently in synthetic sounds which simplifies the assembly of synthesizers
but is almost universal for natural sounds.

If someone is interested in building a comprehensive synthesizer based on
frequency threads I could give them some very good pointers.  However
such a synthesizer is a bit of a CPU hog and would cause interrupts in Octal
depending on the complexity of the real-time generated sound and the
speed of one's computer.  E.g., my 750 MHz CPU chokes at around 60-70
threads when that is all that is running.  Octal is going to take a good
portion of that CPU space such that current single computer capacities
make this kind of real-time synthesizer a marginal option.  However that
will change as computer speeds increase.

The following is the heart of a thread-spectrum synthesizer.

#define RUN_ANGLE 1.42475857305659548476e-4 // M_2PI / 44100

 for(i=start_sample;i<=end_sample;i++) {
    for(fc_dx=start_fc;fc_dx<=end_fc;fc_dx++) {
       smpl_fc_sum += get_samp_amp(fc, fc_dx, i) * sin(lnk_angle[fc_dx]);
       lnk_angle[fc_dx] += RUN_ANGLE * get_samp_freq(fc, fc_dx, i);
    }
    // output smpl_fc_sum as the current value of the sound wave
 }

fc is the table containing the thread descriptions.  fc_dx points to a
particular thread descripion.  lnk_angle contains the angle of the 
current sample for that thread.  It initially contains the phase angle. 
get_samp_amp computes the amplitude for this thread at the current sample
using an amplitude envelope description.  get_samp_freq computes the
frequency similarly.  That frequency times the RUN_ANGLE gives the angle
increment that when summed to the preceeding angle increments, obtains the
proper angle point for the next sin computation for that thread.

Now we need a graphic method of showing and manipulating the amplitude
and frequency curves, and, likely, generating different families of
harmonics.

Regards,

Neil Nelson