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: Wed, 16 Jul 2003 15:07:17 +0200
Urs,
reading your statement gives more questions than answers.
And the one and only ruling question still remains: Why? Just because
it can be possible? Which advantage do you have?
Answer: None.
See my inline comments:
On Mittwoch, Juli 16, 2003, at 12:48 Uhr, Urs Heckmann wrote:
[...]
Problem
Well. The current API has no concept to properly implement part-based
MDs. There is no way to specify a part when loading presets, restoring
state, setting parameters etc.
This is a critical situation, especially if you take into account what
hacks / inconsistencies have been used to circumvent this within VST
world, where exactly the same problem exists. However, since VST has
learned to let the plugin send midi, some use midi CCs with
midichannel <-> part mapping instead of parameters to damp the hassle
a bit. AUs currently can't send midi as a replacement for parameter
changes, an honestly, it's bad style.
Slow Urs, the situation is anything else than critical. On Vst ist is
though. The situation is, that multitimbral is disencouraged, which is
just the way it should be.
Proposal
My suggestion was to merge the AU concept of Elements with the real
world concept of parts. This would immediately provide us with a good
50% on the road to a properly working, part-based multitimbral world.
Objection!
Respond
To respond to the criticism (Frank, we'll carry this out at our next
beer night, maybe I simply pay for yours), I'll sum up some basic
conditions that I implicitly put in the pot:
Slow, slow Urs ;)...
- The property and notification scheme in AU world allows for thorough
reconfiguration of what an Audio Unit exposes to the host. Parameters
can be added, the parameter list can be altered at "runtime".
Which is something totally else.
- Parameters are already tied to the Elements scheme. There's about no
work to do to enable Element/part-based multitimbrality here. (On the
specs side, of course)
- Presets and state are not tied to Elements, hence not to parts. This
would require some modifications in the specs.
- Extensions to that scheme might be useful, i.e. to deal with overall
stuff vs. single part stuff. For example, Element -1 could be used to
communicate "He plug! - All parts are meant". Somewhat the like.
- The modifications of the specs can be done without breaking
compatibility to current conventions and existing software. Thus a
transition can be seemless. At least I hope so.
Nobody denies that it is possible to do. But that is not the question.
Your "Respond" points only explores the technical side. But i still
think the User Experience should be in the center of all considerations
first.
Conclusion
In my opinion, the hassle that people (host developers, hehe) are
concerned of, already exists. AUs already offer that complexity, i.e.
by the ability to change their properties any time after construction.
Proper host design has to take this into account already ( even if it
means a delay in AU support 8-).
I see no general problems with that. For sure many questions arrise,
like what happens to automations for these parameters... This is of
course another story.
It is often said and a valid argument, classical multitimbrality is
somewhat obsolete for virtual instruments as we know them. Exceptions
may occur, and YMMV
There is no exception. ;)
I see applications beyond classical multitimbrality. - Examples like
VBox, FXMachine, or even my superficially described visions, show that
plugin space wants its options. So does user scape. I assume.
The Development of VBox, FXMachine and a like is a pure compensation
for the lack of options at the host side. You can do cool stuff with
it. But it is also a pain to work with them in many ways. Read my
previous commends about UIs before.
In my opinion, minimal effort is required to get rid of the necessity
to do "workarounds".
Wrong. The missing of a policy created the problem for VST. I hope AUs
doesn't follow this path. A "workaround" is more a sign of a lack at
another part. Legalising the "hack" afterwards doesn't really help.
Some Questions arise, and to name only a few:
Which part is related to which Output? And which Input going into which
part? What if some parts share outputs, others go into several?
Sure, you can add more and more properties... But the UI... :(
The devil itself lurks behind a pretty face sometimes... ;)
Yeah, I like the look of Live very much 8-)) (sorry, couldn't resist.
Where's my NFR?)
And you can make a hell of a music with it? (couldn't either :D)
Ciao,
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.