octal-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Octal-dev] suggested features


From: Dave O'Toole
Subject: Re: [Octal-dev] suggested features
Date: Thu, 27 Apr 2000 18:04:44 -0400

> > The current plan for OCTAL is to have all envelopes globally shared and
> > synch-able; GTK+ already has widgets designed for editing envelopes and
> > curves.
> 
> what's the rate at which these envelopes are reported to the machines?
> do you think users would want to influence this rate somehow?
> maybe set it high just for some machines that need it...
> or is this just tempo*16n?

I think you mean "oscillators" not "envelopes." Envelopes, like vol
envelopes for waves, are not "reported"; they're stored like waves,
since a given machine may have multiple sounds playing that want to
follow the envelope, each at a different point in the envelope. 

Oscillators (like LFO's) for global sync (not sure how useful it is, but
some Buzz ppl have suggested it) could be achieved by holding a data
buffer (equal in size to the block-size being generated at each block of
time) which is filled with the appropriate data for that block. 

Everything--all events and sound generation--everything in OCTAL is tied
to the block-size. These blocks are small chunks of samples, out of
which "ticks" are built.

> i guess a way to send these into the system in real-time (==with a constant,
> small latency) would need to exist if we wanted to drive octal with a midi
> controller someday. or from a friendly neighbor process. but the clock issues
> involved are probaly pretty involved...

If everything snaps to block boundaries, we'll get low latency without
all the timestamping/recalculation issues. 


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]