Re[2]: Re:machine types as instrument abstractions, or IA-Ma

[ccastiglione]

____________________Reply Separator____________________
Subject:    Re: Re:machine types as instrument abstractions, or IA-Machi

>> maybe env's should just be rolled up into the category of "control signal"
along with LFO's and be produced (if at all) by machines designed specifically
for that purpose.

> How would this work for envelopes? Every instance of it would be at a
different point in the envelope... some notes starting, some stopping,

I was thinking that the connection diagram, in the case of control signals,
wouldn't necessarily indicate the flow of an individual signal so much as a
dependency relationship.  So if a machine provided three externally controllable
attributes -- pitch, pan and volume, for example -- then it would accept three
control inputs.  The only difference is that if the control input were an env,
then it would be triggered by note events rather than just providing a steady
signal.  It's not uncommon for LFO's to respond to a trigger event (possibly a
note-on) by starting over at phase zero, so this is functionality you might want
in both anyway.

Uh -- but then there's the issue of mapping env's to notes / instruments, which
is pretty much incompatible with everything I just said.  I mean, if you have a
wave / instrument based machine, and the user loads fifteen waveforms and the
machine supports two env-able parameters for each instrument, does your machine
require thirty control inputs?!  Ackkttpthtt!  Forget about it...so, probably I
was confabulating two perfectly good ideas which should stay separate.

Maybe a global env table accessible with the same keys as the wave map table and
then an interface for plugging control signals into machines, also.  Maybe
full-blown use of control signals should wait 'til later.  A phased
implementation for writing the LFO code!  Heh...