Re: Parts, Groups and Multi-timbrality
Re: Parts, Groups and Multi-timbrality
- Subject: Re: Parts, Groups and Multi-timbrality
- From: Urs Heckmann <email@hidden>
- Date: Sat, 26 Jul 2003 23:41:45 +0200
Hi list,
due to my overwhelming excitement over Bill's novel, I forgot to reply
to you as well...
so here's my interleaved reply, interleaved with Bill's respond and
some interleaved add-ins...
Cheers,
;) Urs
Am Samstag, 26.07.03, um 22:17 Uhr (Europe/Berlin) schrieb Bill Stewart:
Urs
On Friday, July 25, 2003, at 01:36 PM, Urs Heckmann wrote:
Am Donnerstag, 24.07.03, um 03:42 Uhr (Europe/Berlin) schrieb Bill
Stewart:
This is long, and we have suffered greatly in its production, so its
only fair you should suffer to read it :)
Yeah, looks like you had a good time 8-)
Many "discussions" :)
Usage of the Group and Part scopes
Yes. I find the answers I was looking for. At first read of course.
There's more questions to be expected during implementation 8-)
Indeed - there are some tweaks we will need in the AUBase support (and
I think we're going to make the default behaviour for saving the
global preset skip over group scope to reinforce the differentiation
we're trying to make here)..
Hehe, thanks for building total persistence into .aupreset. Good move.
Sure - it would be a mess without that...
I have some general questions:
What led to the decision to keep MidiNotes away from MusicEffects? -
I think that Midi Notes are actually a grewat way to manipulate
Effects that extend synthesis. Like Filters with Note-controlled
Cutoff frequency. And there's a common way to circumvent lousy
problems by calling a distinct method of synthesis "Comb Filter"
instead of "Physical Modelling". Hence building a Gate/Delay/Filter
MusicEffect would be great to have in an effect chain...
We want to distinguish between a Music Effect - that essentially
provides for this "run time" mapping of "controllers" to the rendering
process, and the concept of creating notes that are then controlled
(which is the domain of the Music Device unit).
I take your point though - using the MIDI note messages as a way to
manipulate some parameters seems like a legitimate usage - but what we
don't want to see is the use of Music Effects to actually generate
notes per se... Maybe we're being more restrictive than we need to be
here...
maybe, yeah...
What about a property to query the host if it likes to bother with
Part Scope? - For simpler hosts it might be cool for a Part based
MusicDevice to be able to provide a limitted set of Parameters in
Global Scope instead, much like it is now. This would ensure that
some host developers won't drop me from their NFR list 8-)
I would expect this to be done with the PartGroup property.
I think this gets too confusing.. If your republish a parameter in
global scope, the implication to me is that the synth will apply those
parameters across ALL of its parts, which I don't think is your
intention?
The DLS Synth publishes a couple of global parameters... Tuning,
Volume - and when they are applied, they are applied to the entire
synth as you would expect.
And ultimately general:
From the Midi specs as I know them, when subsequent data of a single
type is streamed, the actual identifier (CC, Program Change, Pressure
etc. with Channel) is sent only once, followed by that stream of >> data.
Yes - Running Status.
The concept of MSB/LSB controllers certainly breaks this neat goodie
and slows stuff down by factor 2 - 4. What led to that decision? - Is
the anticipated precision at all met by common hardware controllers?
Hardware controllers tend to deal with this problem by assigning other
MIDI controllers (like pitch bend) to high fidelity controls... I'm
sure Doug, and others with more MIDI experience than I can give you a
list of workarounds/techniques that have been applied for many years
to workaround this restirction...
Bill
Cheers,
;) Urs
ps - Urs, if you don't mind, I wouldn't mind re-sending this response
to the API list - as the issues you raise are probably of interest to
others as well...
done...
_______________________________________________
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.