Re: Multitimbral Music Devices - Question and Proposal
Re: Multitimbral Music Devices - Question and Proposal
- Subject: Re: Multitimbral Music Devices - Question and Proposal
- From: Philippe Wicker <email@hidden>
- Date: Wed, 16 Jul 2003 09:57:18 +0200
Hi all,
This posting make reference to several contributions.
On Wednesday, July 16, 2003, at 05:28 AM, Christopher Corbell wrote:
Not being a seasoned VST or audio plugin developer, I'm not sure
I understand all of the ramifications of this thread, so please pardon
me if I miss a point.
Though I've began developing some AUs I feel myself like you about this
thread :-)
On Tuesday, July 15, 2003, at 07:26 AM, Frank Hoffmann wrote:
Regarding Audio Units hosting Audio Units: There should be no need
for that. Or how many layers of Audio Units inside Audio Units you
want to support?
Isn't this basically what AUGraph is for? I'm completely naive about
the
implications for plug-in development, but I think wrapping an AUGraph
of
arbitrary complexity in a single AudioUnit would be a really powerful
feature.
(If that's a stupid comment please just ignore it :-) )
No, it's not stupid at all. I'm still asking why no experienced plugins
developer (I'm not counting myself in this category :-) has not yet
announced a "super" AU which would be some kind of AU host itself. This
would be a software equivalent of multi-effects racks available in the
hardware world. Jim Wintermyre mentioned FXMachine and VBox, but they
are (still?) VST only I think. Of course, the question of what
parameters have to be published is not a trivial problem (that's why I
let this problem to experienced developers :-)) The "super" AU would
have to provide the user a mean to build the UI for a given
multi-effect preset.
On Wednesday, July 16, 2003, at 02:16 AM, Bill Stewart wrote:
I guess I have to say something :)
On Tuesday, July 15, 2003, at 09:51 AM, Urs Heckmann wrote:
People come up with unusual solutions. In this case, I bet it's hard
to prevent some people from doing so. Offering consistency would be
better. Otherwise one should say "No. Preset/Parameter based Music
Devices must not be multitimbral". Bill?
Yes - that is our strong inclination...
As I said above I began developing some AUs, one of them being a
"multi-instrument" MusicDevice. I say "multi-instrument" because I'm
not sure of what people exactly mean when mentioning mono-timbral and
multi-timbral plugins. In my understanding, both mono-timbral and
multi-timbral plugins are able to play parts (a part = an instrument +
a midi channel + some parameters), a multi-timbral plugin being able
to play several parts at the same time.
I agree with folks saying that it would be much simpler (for the host
and probably also for the plugin designers) to consider that an
instance of a multi-timbral plugin behaves like a mono-timbral
MusicDevice and that if a user wants to play at the same time another
part, then he does this by instantiating the MusicDevice one more
time. However, it remains that each instance is still a
multi-instrument plugin and a user may want to change the instrument of
the part played by that instance on the fly. When I was doing a lot of
music (a few years ago) I was using Cubase version 5 and 2 external
sound generators (SC88 and Akai S2800). Each midi track provided a
popup menu allowing to select the destination device, and another popup
allowing to change the instrument on the fly (while the sequence is
playing). It was very handy, particularly when you're prototyping your
song (as James Chandler Jr says in one of his postings).
To sum up. Yes for a new plugin instance for each part intended to be
played concurrently with the others. No new instance if you "simply"
want to replace a part by another (I should say to be more accurate if
you want to change the instrument and the parameters within a given
part).
Philippe Wicker
email@hidden
_______________________________________________
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.