Re: Mutitimbral - A clarification, sort of
Re: Mutitimbral - A clarification, sort of
- Subject: Re: Mutitimbral - A clarification, sort of
- From: "Angus F. Hewlett" <email@hidden>
- Date: Thu, 17 Jul 2003 11:57:37 +0100
At 02:12 PM 7/16/2003 -0700, you wrote:
>
What about the labor overhead of a user who must instantiate 16 plugins
>
before he can listen to a partner's emailed MIDI file?
That can and should be automated by the host. It's not at all difficult.
In fact, having monotimbral-only devices and having the host automate
multitimbral loading and mapping makes things, in some ways, easier for
both the host developer and the plugin developer, and this in turn makes
things better for the user.
The host developer wins because s/he can rely on plugin behaviour being a
specific way, rather than having to accomodate potentially different
behaviours across different MT plugins.
The plugin developer wins because s/he only has to support ONE api and
mechanism for loading and saving internal state, and changing parameters,
rather than having SaveState/RestoreState, MIDI program changes, multiple
internal presets a la VST, parameter changes, MIDI CC changes and NRPNs.
Most importantly, the user wins because the plugins behave more
predictably, and s/he doesn't have to worry about whether that patch they
were just tweaking gets lost or not when the synth receives a Program
Change, where it gets written to, what restoring a previously saved state
will affect, etc. etc.
This last point is particularly important to softsynths because there are
subtle but important differences in the way people work with software as
opposed to hardware. The main point is that because the synth is integrated
in to the sequencing environment, more advanced users are going to be
tweaking the synth's settings as they sequence, and the synth's interface
is "on the same page", conceptually at least, as the sequencer's transport
bar.
The problem there is that if the synth has a hardware-like MIDI
implementation, and there are MIDI commands embedded in the tracks or
automatically sent by the sequencer, they can screw with the state of the
synth before the user got a chance to change it. With hardware, it's
different:- it's easy to think "I must write the synth's changes to memory
before I go back to the computer". But with software, you really do not
want MIDI CCs or Program Changes making persistent changes to the
software's state:- it's MUCH better to let the parameter and state
save/restore API do that stuff; MIDI CCs should be used only for
non-persistent "performance" changes.
>
For sake of example, say a sequencer has a bunch of MIDI tracks in the
>
Mixer window, and a single instance of Virtual Sound Canvas, SampleTank
>
or whatever. Easy to set up. Easier to navigate on-screen, than a
>
duplicate synth instance for each MIDI track.
IMHO, not really. If you are using a synth in this kind of multitimbral
mode, you by and large aren't needing to open up the synth's UI at all...
the arrange view and the pulldown menu look almost exactly as they would
with a single multitimbral synth (the difference being, the different parts
are listed as devices instead of channels. no big deal). You can probably
edit all you really need to in this scenario without ever opening up the
synth's panel; if you do need to edit deeper, opening up individual windows
is again not a big deal.
>
Say we have a five-band dynamics plugin. This dynamics plugin has 10
>
parameters per band, and some global parameters. Maybe the host has to
>
load/save a total of 70 parameters.
>
But the dynamics plugin control panel doesn't have to show all 70
>
parameters simultaneously-- Perhaps the plugin control panel would put
>
each band on a separate view of a tabbed pane, with an additional tab
>
for global settings.
>
This view-hiding in the plugin control panel doesn't affect the host at
>
all-- When appropriate, the host just gets/sets 70 parameters?
>
How is this substantially different from a 16 part programmable synth,
>
even if part 10 uses a drum structure rather than pitched-voice
>
structure? Perhaps each part has 50 parameters, oscillator, ADSR,
>
Filter, etc. In this case, perhaps the total synth "Patch" would
>
contain 800 parameters.
Because in the case of the dynamics plugin, it clearly makes sense for the
host to always load and save the entire state in one go. And, because the
dynamics plugin cannot receive MIDI, there are no issues regarding program
change messages.
In the case of a multitimbral synth, each part may have a life of its own
in terms of preset state (or program number, etc.); it is reasonable to
expect that the host-level save/restore mechanism would work for each part.
But, IMHO, with this approach you end up with too many overlapping
mechanisms for doing the same or related things.
Just MHO, of course...
Regards,
Angus.
=======================================================
Angus F. Hewlett, Technical Director
FXpansion Audio UK Ltd -
http://www.fxpansion.com
=======================================================
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.