Re: Those API revisions, plus some thoughts

[ben]

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

I think additive synthesis is generally more expensive than other
methods, but this could probably be optimized by using inline functions,
a fast sine approximation, etc.  I think the call to sin() is the
slowest part.

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

Creating an interface to easily manipulate those curves would be hard -
there are three dimensions to keep track of (freq vs. amp vs. time), so
it would have to be something like a 3-D envelope editor or a set of
freq vs. amp envelopes, interpolated over time, or something like that.

-ben