Re: Mutitimbral - A clarification, sort of
Re: Mutitimbral - A clarification, sort of
- Subject: Re: Mutitimbral - A clarification, sort of
- From: Urs Heckmann <email@hidden>
- Date: Thu, 17 Jul 2003 12:27:59 +0200
Frank,
this is not necessarily true.
Hosts could still just keep unaware of multiple group designs.
For example, AUBase could dispatch GlobalScope level parameters to
address Group 0.
Hosts that are not aware of the new scheme would just do as usual, but
Multi-Group MusicDevices would only act as SingleGrouped, i.e.
monotimbral instead of multitimbral.
The host furtherly should not be aware of number and length of
implementation-specific data keys within the presets. It would
therefore treat preset formats (Multi with more than one patch or
single with just part data, but no global ) as only one format.
State information (that saves with song) would be a Multi (with some
redundant information...)
However, by the still valid idea of sending MidiNotes and stuff, users
could take advantage of multitimbrality even on multi-unaware host. If
she loads a multi, then this multi would affect all groups at once.
What the user would not be able to do, however, is multitimbral
automation.
I am sure that the CoreAudio Team will design these features in a way
that makes it painless for host developers. Chris?
Methinks we should listen to Jeremy's objections / experience, as he
currently provides the only available host (AU and other) which
supports Instruments of multiple PlugIn formats.
Cheers,
;) Urs
Am Donnerstag, 17.07.03, um 11:44 Uhr (Europe/Berlin) schrieb Frank
Hoffmann:
Chris,
Seems you are not aware that it indeed limits host development on a
conceptional level. Because if the standard provides it, you have to
support it.
Frank
On Mittwoch, Juli 16, 2003, at 09:52 Uhr, Chris Rogers wrote:
Frank, I think the idea is that with the multi-timbral synths, you can
still use them as mono-timbral synths and instantiate 16 plugins
if that's the way you like to work. We're just talking about not
forcing
people to work in this way. What happens to the UI when you have 16
plugins
open? 16 windows? There are a number of reasons people have brought
up
for wanting to be able to write and host multi-timbral synths.
Personally,
you can still write only mono-timbral MusicDevices and always host all
MusicDevices (mono and multi-timbral) in the way you want.
We just want to make sure we don't impose unnecessary limitations,
especially if we can find a reasonable and clear solution
for those wanting to write and host multi-timbral MusicDevices...
Chris Rogers
Core Audio
Apple Computer
On Mittwoch, Juli 16, 2003, at 05:35 Uhr, Michael Olsen wrote:
They had two reasons:- they want to be able to use multi-channel
modules
like DLSSynth, SampleTank and the Roland Virtual SoundCanvas
modules
without having to instantiate 16 plugins; and, for plugins like
Native's
B-4 which supports different MIDI channels for its lower and upper
manuals
and pedalboard.
As the developer of SampleTank, a multitimbral, multipart
instrument, maybe I should say a few words here...
To me the clear advantage of multiparts for an instrument like
SampleTank, which is essentially a sound module, is:
A: (As Angus says) you don't have to instantiate 16 plugins
Where is the problem with instantiate 16 plugins? We are talking
about shared code and data here. The overhead is minimal.
B: The multiple parts can share the same voice manager. (This is
very important in my opinion).
In which terms? To manage in a way a part of the overall cpu load?
This is only of use if you use only one instance of one plugin in
the whole system, isn't it?
C: The multiple parts can share the same (build-into-instrument)
effects (Admittedly, we don't do that in SampleTank, but some
developers might want to).
It would be more flexible when the send effect you described and the
synthesis parts are separate Audio Units. Then you can use it as
send effect for all monotimbral instances and even for other
instruments. This is much more flexible.
As for (B) I have been complaining to just about any plug-in API
developer that would care to listen, that there should be some way
for multiple instances of the same plug-in to share an instrument
manager. This is a quite advanced topic, and is not supported by
any platform that I know of.
This just makes it even more important to do multi-parts
instruments when doing something like a sound module.
If there is such a mechanism your point (B) is not valid anymore. If
not, as you pointed out, the usage of a voice manager is mood,
because several instances and other instruments
Regards
Frank
---------------------------------------------------------------------
-----------------------------
frank hoffmann mailto: email@hidden
ableton ag http://www.ableton.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.
_______________________________________________
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.
-----------------------------------------------------------------------
---------------------------
frank hoffmann mailto: email@hidden
ableton ag http://www.ableton.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.
_______________________________________________
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.