Re: [Bluemusic-users] Prototype: new idea [long]

[Michael B. <got...@ya...>]

Ok, last night I was brainstorming about this since I
couldn't get to sleep. I've tried something similar to
what you've put together in your prototype, Steven,
and there are several problems that make it somewhat
cumbersome to use:

- matching input and output zak numbers of various
instruments
- making sure zak instruments are numbered so that
they get processed by csound in the correct order
- making sure the zak channels you use aren't already
being used by another instrument

So you wind up with a scenario where you want to
simply remove an effect in an effects chain, and you
have to go into the i-statements of the source sound,
change its zak channel output, find out which effect
was next in the chain, go to its i-statement and
change its source zak channel. If you're not changing
i-statements you're changing widgets dealing with
numbers, which is still a hassle.

So here's what I came up with.

NEW INSTRUMENT: Effect

An effect instrument would not have an instrument ID
show up in blue like the other instruments. It would
be like a BlueSynthBuilder instrument in that there
would be a widget UI to edit, but you wouldn't change
the actual widget values from this instrument (i.e.
you wouldn't be able to set the knob to 2.11)(more on
this later). You would reference the widgets in the
code portion of the instrument just like in BSB.
Lastly, there would be boiler-plate code prepended and
appended to the final csound code, handling zak input
and output. That boilerplate code wouldn't be editable
by the user; the only thing the user would need to
know is that at the beginning of the instrument, the
user has two a-rate variables already defined carrying
the input to the instrument, and that the output from
this instrument should be assigned to two a-rate
variables with predefined names. There would be an
optional setting per Effect indicating that it be the
terminus in an effect chain.

NEW INSTRUMENT: EffectChainInstrument

The EffectChain is more of a meta instrument than
anything, because no csound code is associated with it
directly. Its UI would have a space to insert effects.
One would choose from a list of Effect instruments
already in the project. The area in the UI holding the
effects would be a 1-column table. Each row would hold
a now-tweakable version of the widget UI created by
the user when they made the Effect instrument. Beside
each effect UI row would be buttons to move the effect
up and down in the chain and remove the effect from
the chain. Each effect would automatically pass its
output down the chain to the next effect (this whole
idea is basically borrowed from JackRack).

NEW SOUNDOBJECT: EffectChainObject

The EffectChainObject would contain the (tweakable) UI
from the EffectChainInstrument, along with additional
widgets letting the user enter the zak number OR the
global variable containing the source sound signal to
feed into the chain, and a widget letting the user
select which EffectChainInstrument to use. Any changes
made to the EffectChainInstrument's widget UI in the
SoundObject would be reflected in the instrument UI
and vise-versa (this is optional, I suppose, but I
thought it would be nice to make the effects widgets
tweakable from the score view).

BEHIND THE SCENES:

No Effect instrument would even show up in the
orchestra portion of the rendered CSD if there isn't
an associated EffectChain instrument as well as an
EffectChainObject. Each EffectChain instrument would
render the actual instrument code for the effects,
automatically assigning increasing instrument IDs per
the effect's position in the chain, starting at the
greatest instrument ID of user instruments+1. The
boiler-plate code of the effects handling zak input
and output would be generated again based upon the
effects' positions in the chain, as well as the zak
input/global var input specified on the
EffectChainObject (only applicable to the first
effect's boiler plate). The zak channels to use would
be either determined automatically (i.e. by examining
any zakinit opcodes), or by a project-global setting
indicating the lowest zak channel number the effects
should use.

An EffectChainObject's position in the score would be
replaced by the i-statements of each effect instrument
in the chain. The widget settings for each effect
would translate into p-fields passed in to the effect
instrument, with corresponding substitutions made in
the instrument code (i.e. <knobAmplitude> might be
replaced with p9).

When one wants to reuse an EffectChainInstrument, they
place an EffectChainObject, specify which
channel/variable to use as input and which chain to
use. If there are multiple EffectChainObjects
referencing the same EffectChainInstrument but
specifying different sound sources to feed into the
chain, the first effect's boiler-plate code simply
reads the input from both sources and sums them
together.

Reuse of individual Effect instruments across mutiple
EffectChainInstruments causes multiple instances of
the same effect instrument to be rendered, each with
their own instrument ID and boiler-plate code
according to their position in their associated
EffectChainInstruments.

WHAT YOU WIND UP WITH:

- Reusable effect instruments with user-friendly,
tweakble UIs (configurable on a per-use basis) and no
messing with zak code by the user.
- Reusable effects chains with easy effects
re-arrangement at the push of a button; again, no
messing with zak code at all.
- An effects setup that uses the instrument-score
paradigm natural to csound
- An effects setup that accomodates users that use
both zak and global variables.

I know this is alot of work, but the good news is that
changes to existing code would be little to none. And,
of course, I'd be glad to help implement it.

What do you guys think?

Michael Bechard


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs