[Top][All Lists]
[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