Re: Mutitimbral - A clarification, sort of
Re: Mutitimbral - A clarification, sort of
- Subject: Re: Mutitimbral - A clarification, sort of
- From: Frank Hoffmann <email@hidden>
- Date: Thu, 17 Jul 2003 11:44:26 +0200
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.