6 Jan
2003
6 Jan
'03
4:10 p.m.
The main difficulty I see with the VVID system is how to initialize
parameters on a new voice before the voice is activated with a VoiceOn
event.
The MIDI standard deals with this by allowing 2 particular parameters, pitch
and velocity, to be privileged as voice-on initializers. These parameters
are included inside the MIDI Voice On message so that the instrument always
receives them when they are needed: right when a voice is being activated.
It has been the general feeling in LAD discussions that XAP should not put 2
particular parameters into the Voice On event but, instead, should allow any
parameter-set events to be intializers. How to achieve this?
In XAP, it is not sufficient to consider all parameter setting events
received before a Voice On message to be initializers. Consider that, before
an actual voice is attached to a VVID, all events sent to that VVID are
discarded. For instance, if a voice is activated and then reappropriated
halfway through a note, before the sequencer has stopped using the VVID, the
remainder of the events which the sequencer sends on the voiceless VVID are
simply discarded.
Furthermore, any system which requires initializers to be timestamped before
the voice-on event forces at least a 1 timestamp delay into voice activation
which is undesireable.
We could instead put the voice-on event at the same timestamp as the
initializers and require that the plugin read ALL events for a particular
time position before discarding ANY events, but this makes it more complex
for plugins to read their events. If the plugin found a voice-on event at
the end of a queue section for a particular timestamp then it would need to
loop back to the first event in the queue matching that timestamp and read
again for any initializers.
Alternately, we could require that event ordering has 2 criterion:
-first- order on timestamps
-second- put voice-on ahead of all other event types.
A little ungainly, but effective as it frees the plugins to assume that
they'll get voice-on first but must consider all other events on that
timestamp as arguments to the initialization of the voice. Of course this
only applies to events having a particular VVID on a particular channel of a
particular plugin instance. I admit that introducing another criteria to
event ordering is inelegant, but it is the best approach to voice activation
that I can think of. I think that introducing any sort of mandatory 1 or 2
timestamp delay is far worse.
-jacob robbins.... current projects: soundtank.......<BR>..........
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
6 Jan
6 Jan
5:09 p.m.
On Mon, Jan 06, 2003 at 12:04:23 -0800, robbins jacob wrote:
Alternately, we could require that event ordering has
2 criterion:
-first- order on timestamps
-second- put voice-on ahead of all other event types.
This is what I was assuming was meant orignally.
However you dont have to think of them as initiasiation parameters, voices
can have instrument wide defaults (eg. a pitch of 0.0 and and amplitude
of 0.0), and the parameter changes that arrive at the same timestamp can
be thought of as immediate parameter changes, which they are.
- Steve
6:23 p.m.
On Monday 06 January 2003 22.03, Steve Harris wrote:
On Mon, Jan 06, 2003 at 12:04:23 -0800, robbins jacob
wrote:
Exactly.
These "instantiation parameters" are in fact just control events, and
they relate to "whatever voice is assigned to the provided VVID".
The issue here is this: Where does control data go when there is no
voice assigned to the VVID?
It's tempting to just say that whenever you get events, check the
VVID, and allocate a voice for it if it doesn't have one.
However, it's kind of hard to implement voice allocation in a useful
way if you don't know what control will trigger the allocation. (You
can't discard very silent notes and that sort of stuff.)
As to event ordering, the logical way is to send "parameters"
*first*, and then send the event that triggers the note - be it a
specific note_on event (bad idea IMHO) or just a change of a control,
such as Velocity.
Synth implementations will want it the other way around, though.
Problem with that is that it breaks a fundamental rule of the event
systems: "Events are processed in order."
What I'm saying is that if you send the "trigger" event first,
followed by the "parameters", you require synths to process a number
of control events *before* actually performing the trigger action.
That simply does not mix with the way events are supposed to be
handled.
What's even worse; the logical alternative (sending parameters first)
results in allocation problems. Do we have to have actual Virtual
Voices objects in synths? If so, how to allocate them? (Or rather;
how many?) If VVIDs are global and allocated from the host, that just
won't work. Synths would at least need to be informed about the
number of VVIDs allocated for a Channel, when a connection is made.
Wait. There's another alternative.
If you really want to your voice allocator to be able to turn down
requests based on "parameters", how about using a single temporary
"fake voice" whenever you get a "new" VVID? Grab it, fill in the
defaults and have it receive whatever controls you're getting. When
you get the "trigger" event, check the "fake voice", and if the voice
allocator doesn't like it, just hook the VVID up to your "null" voice.
Obviously, this requires that "parameters" are sent with the same
timestamp as the corresponding "trigger" event - but that makes sense
if the "parameters" are really to be regarded as such.
If they aren't, we're talking about a different problem: Keeping
Voice Control history for Voices that aren't allocated or playing.
Anyway, this obviously suggests that it should be strictly specified
whan you may and may not talk to a Voice and expect it to respond. I
mean, it obviously seems stupid to have a physical voice running just
to track Voice Controls while nothing is being played - but OTOH,
what do you do if you have 128 VVIDs in use on a 32 voice synth? What
do you track, and what do out send to the NULL voice? When do you
actually steal a physical voice?
Note that all this is very closely related to implementation
specifics of synth voice allocators. I think the issue is more one of
coming up with a sensible API for this, than to dictate a policy for
voice management. I doubt that a single policy can work well for all
kinds of synths.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
Alternately, we could require that event ordering
has 2
criterion: -first- order on timestamps
-second- put voice-on ahead of all other event types.
This is what I was assuming was meant orignally.
However you dont have to think of them as initiasiation parameters,
voices can have instrument wide defaults (eg. a pitch of 0.0 and
and amplitude of 0.0), and the parameter changes that arrive at the
same timestamp can be thought of as immediate parameter changes,
which they are.
7 Jan
7 Jan
5:29 a.m.
On Mon, Jan 06, 2003 at 11:17:07 +0100, David Olofson wrote:
These "instantiation parameters" are in fact
just control events, and
they relate to "whatever voice is assigned to the provided VVID".
The issue here is this: Where does control data go when there is no
voice assigned to the VVID?
They get thrown away.
What I'm saying is that if you send the
"trigger" event first,
followed by the "parameters", you require synths to process a number
of control events *before* actually performing the trigger action.
That simply does not mix with the way events are supposed to be
handled.
Well, I thinik its OK, because the note will not be used to render any
samples until after all the events have been processed.
If you really want to your voice allocator to be able
to turn down
requests based on "parameters"
I think this would be complex.
- Steve
8:55 a.m.
On Tuesday 07 January 2003 10.23, Steve Harris wrote:
But who guarantees that whatever the "trigger" event is, also comes
with events for the "parameter" controls? It's trivial (but still has
to be done!) with explicit NOTE_ON events when assuming that NOTE_ON
means "allocate and start voice NOW", but it's not at all possible if
the synth triggers on voice control changes.
Not more complex than any "note-on latched" controls - and I don't
think it's realistic to eliminate those.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
On Mon, Jan 06, 2003 at 11:17:07 +0100, David Olofson
wrote:
Right - so you can't play a polyphonic synth with a continous
velocity controller, unless you track and re-send the controls that
the synth happens to treat as note parameters.
These "instantiation parameters" are in
fact just control events,
and they relate to "whatever voice is assigned to the provided
VVID".
The issue here is this: Where does control data go when there is
no voice assigned to the VVID?
They get thrown away. What I'm
saying is that if you send the "trigger" event first,
followed by the "parameters", you require synths to process a
number of control events *before* actually performing the trigger
action. That simply does not mix with the way events are supposed
to be handled.
Well, I thinik its OK, because the note will not be used to render
any samples until after all the events have been processed. If you really
want to your voice allocator to be able to turn
down requests based on "parameters"
I think this would be complex.
10:14 a.m.
On Tue, Jan 07, 2003 at 01:49:23 +0100, David Olofson wrote:
Right - so you can't play a polyphonic synth with a continous
velocity controller, unless you track and re-send the controls that
the synth happens to treat as note parameters.
I dont understand why.
I dont think that matters, eg. my favourite exmaple, the gong synth. If
you issue a voice on it will initialise the gong graph in its stabel
state, and when you sned a velocity signal (or whatever) it will simulate
a beater striking it.
Not more complex than any "note-on latched" controls - and I don't
think it's realistic to eliminate those.
There is a difference between "turning down" (implies communicating) and
ignoring (silent).
- Steve
The issue here is this: Where does control data go
when there is
no voice assigned to the VVID?
They get thrown away. Well, I thinik
its OK, because the note will not be used to render
any samples until after all the events have been processed.
But who guarantees that whatever the "trigger" event is, also comes
with events for the "parameter" controls? It's trivial (but still has
to be done!) with explicit NOTE_ON events when assuming that NOTE_ON
means "allocate and start voice NOW", but it's not at all possible if
the synth triggers on voice control changes. If you really want to your voice allocator to be able
to turn
down requests based on "parameters"
I think this would be complex.
10:56 a.m.
On Tuesday 07 January 2003 15.08, Steve Harris wrote:
I dont think that matters, eg. my favourite exmaple, the gong
synth. If you issue a voice on it will initialise the gong graph in
its stabel state, and when you sned a velocity signal (or whatever)
it will simulate a beater striking it.
Yeah - that's a perfect example of "allocate voice on first use of
VVID". This breaks down when you run out of physical voices, unless
you do instant voice stealing upon "allocate new voice for VVID". (It
might make sense to just do it that way, but it definitely is a waste
of resources if allocating a voice is frequently done before the
synth actually decides to start playing.)
Not more complex than any "note-on latched" controls - and I
don't think it's realistic to eliminate those.
There is a difference between "turning down" (implies
communicating) and ignoring (silent).
"Turning down" was meant as seen from the synth implementation POV.
That is, if a synth "turns down" a voice allocation for a VVID, that
VVID just gets routed to "the NULL Voice". Future events with that
VVID are ignored.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
On Tue, Jan 07, 2003 at 01:49:23 +0100, David Olofson
wrote:
Right - so you can't play a polyphonic synth with a continous
velocity controller, unless you track and re-send the controls
that the synth happens to treat as note parameters.
I dont understand why.
It's obvious when you consider that "VVID has no voice" can happen
*before* the synth decides to start the voice; not just after a voice
has detached from the VVID as a result of voice stealing. At that
point, only the value of the control that triggered "voice on" will
be present; all other controls have been lost. Unless the host/sender
is somehow forced to resend the values, the synth will have to use
default values or something.
The issue here is this: Where does control data go
when there
is no voice assigned to the VVID?
They get thrown away. Well, I thinik its OK, because the note will not be
used to
render any samples until after all the events have been
processed.
But who guarantees that whatever the "trigger" event is, also
comes with events for the "parameter" controls? It's trivial (but
still has to be done!) with explicit NOTE_ON events when assuming
that NOTE_ON means "allocate and start voice NOW", but it's not
at all possible if the synth triggers on voice control changes. If you really
want to your voice allocator to be able to turn
down requests based on "parameters"
I think this would be complex.
12:17 p.m.
On Tue, Jan 07, 2003 at 03:50:26 +0100, David Olofson wrote:
It's obvious when you consider that "VVID has no voice" can happen
*before* the synth decides to start the voice; not just after a voice
has detached from the VVID as a result of voice stealing. At that
point, only the value of the control that triggered "voice on" will
be present; all other controls have been lost. Unless the host/sender
is somehow forced to resend the values, the synth will have to use
default values or something.
OK... I was thinking that the initial mention of the VVID would cause it
creation (be that implicit or explict, though I prefer explit I think),
thereafter control changes would be applied the the instantiated voice (or
the NULL voice if you've run out / declined it).
Fine then.
- Steve
Right - so you can't play a polyphonic synth with
a continous
velocity controller, unless you track and re-send the controls
that the synth happens to treat as note parameters.
I dont understand why. There is a
difference between "turning down" (implies
communicating) and ignoring (silent).
"Turning down" was meant as seen from the synth implementation POV.
That is, if a synth "turns down" a voice allocation for a VVID, that
VVID just gets routed to "the NULL Voice". Future events with that
VVID are ignored.
12:31 p.m.
On Tuesday 07 January 2003 17.10, Steve Harris wrote:
[...]
OK... I was thinking that the initial mention of the
VVID would
cause it creation (be that implicit or explict, though I prefer
explit I think), thereafter control changes would be applied the
the instantiated voice (or the NULL voice if you've run out /
declined it).
Well, it is sort of explicit in that the synth will have to do
*something* about it - or Voice Controls just won't work as intended.
Now, if it's a physical voice or a virtual voice (basically a dummy
control tracer) that's being instantiated is another matter. You can
still actually keep track of more VVIDs than there are physical
channels, as desicribed earlier. (Two levels of "out of voices".)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
8 Jan
8 Jan
4:29 a.m.
I dont think that matters, eg. my favourite exmaple,
the gong synth. If
you issue a voice on it will initialise the gong graph in its stabel
state, and when you sned a velocity signal (or whatever) it will simulate
a beater striking it.
I'd expect it to work quite differently. I'd expect it to initialize a
stable state, and whenever a VOICE_ON comes in, latch the velocity,
beater-hardness, and strike coordinates. Perhaps damping would be a
continuous control.
Each new strike would be a VOICE_ON and each new strike would affect the
global graph. Really it is monophonic. Each new voice inherits state from
the prior voice.
6:55 a.m.
On Wed, Jan 08, 2003 at 12:23:23 -0800, Tim Hockin wrote:
That doesn't properly represetn how it works though, I would expect
VOICE_ON to map to a new gong instance.
- Steve
I dont think
that matters, eg. my favourite exmaple, the gong synth. If
you issue a voice on it will initialise the gong graph in its stabel
state, and when you sned a velocity signal (or whatever) it will simulate
a beater striking it.
I'd expect it to work quite differently. I'd expect it to initialize a
stable state, and whenever a VOICE_ON comes in, latch the velocity,
beater-hardness, and strike coordinates. Perhaps damping would be a
continuous control.
Each new strike would be a VOICE_ON and each new strike would affect the
global graph. Really it is monophonic. Each new voice inherits state from
the prior voice.
5:44 p.m.
On Wednesday 08 January 2003 11.49, Steve Harris wrote:
On Wed, Jan 08, 2003 at 12:23:23 -0800, Tim Hockin
wrote:
That doesn't properly represetn how it works though, I would expect
VOICE_ON to map to a new gong instance.
That means you can't strike a vibrating gong again...? Not quite
following here.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
I dont
think that matters, eg. my favourite exmaple, the gong
synth. If you issue a voice on it will initialise the gong
graph in its stabel state, and when you sned a velocity signal
(or whatever) it will simulate a beater striking it.
I'd expect it to work quite differently. I'd expect it to
initialize a stable state, and whenever a VOICE_ON comes in,
latch the velocity, beater-hardness, and strike coordinates.
Perhaps damping would be a continuous control.
Each new strike would be a VOICE_ON and each new strike would
affect the global graph. Really it is monophonic. Each new
voice inherits state from the prior voice.
6:34 p.m.
On Wed, Jan 08, 2003 at 10:38:44 +0100, David Olofson wrote:
Well there would be some other control for hitting the thing.
- Steve
That
doesn't properly represetn how it works though, I would expect
VOICE_ON to map to a new gong instance.
That means you can't strike a vibrating gong again...? Not quite
following here.
6:53 p.m.
On Wednesday 08 January 2003 23.28, Steve Harris wrote:
On Wed, Jan 08, 2003 at 10:38:44 +0100, David Olofson
wrote:
Well there would be some other control for hitting the thing.
Which means VOICE_ON actually means... what? (Now it seems redundant
even for the synths I thought could use it! ;-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
That
doesn't properly represetn how it works though, I would
expect VOICE_ON to map to a new gong instance.
That means you can't strike a vibrating gong again...? Not quite
following here.
6 Jan
6 Jan
6:10 p.m.
The main difficulty I see with the VVID system is how
to initialize
parameters on a new voice before the voice is activated with a VoiceOn
event.
After, or rather - at the same time. The host just has to make sure the
VoiceOn arrives first. This is what is currently in the header in my
working dir.
Send a new VVID to the VOICE control with timestamp X for note-on
Send any initial voice-params with timestamp X
Send 0-VVID to the VOICE contol with timestamp Y for note-off
Alternatively, rather than a VOICE control, just have special
VOICE_ON/VOICE_OFF events.
-first- order on timestamps
-second- put voice-on ahead of all other event types.
A little ungainly, but effective as it frees the plugins to assume that
they'll get voice-on first but must consider all other events on that
timestamp as arguments to the initialization of the voice. Of course this
not all events with that timestamp - only per-voice controls with the VVID
that was just turned on. All per-voice events have a VVID. So it is easy
to know if that VVID is active - if not, the host screwed up.
What I am still fighting with is the idea that the host pre-allocates VVID
space. How much space for each VVID? Any imposed structure?
Tim
6:45 p.m.
On Monday 06 January 2003 23.04, Tim Hockin wrote:
Problem is that that requires special case event processing in
synths. You'll need an inner event decoding loop just to get the
parameters, before you can go on with voice intantiation.
The alternative indeed means that you have to find somewhere to store
the parameters until the "VOICE_ON" arrives - but that doesn't screw
up the API, and in fact, it's not an issue at all until you get into
voice stealing. (If you just grab a voice when you get a "new" VVID,
parameters will work like any controls - no extra work or special
cases.)
It's not really "space", but rather a minimalistic approach to
senders allocating "handles", and receivers marking them, to avoid
searching.
When you get a new VVID, you just look the corresponding entry up in
the global array and point it at the physical voice you allocated.
When you get further references to that VVID, you can just look at
the entry and there's your voice; no searching.
(This obviously assumes that senders set new VVIDs to NULL, so synths
can tell them from VVIDs with assigned voices.)
The main
difficulty I see with the VVID system is how to
initialize parameters on a new voice before the voice is
activated with a VoiceOn event.
After, or rather - at the same time. The host just has to make
sure the VoiceOn arrives first. This is what is currently in the
header in my working dir. Send a new VVID to the VOICE control with timestamp X
for note-on
Send any initial voice-params with timestamp X
Send 0-VVID to the VOICE contol with timestamp Y for note-off
I'm not quite following with the 0-VVID thing here... (The VVID *is*
the common reference; that was the idea.) You can't know when a synth
is *really* done with a Voice without a round-trip - but indeed, you
can tell the synth that you have nothing further to say to this Voice
by implying that NOTE_OFF means "I will no longer use this VVID to
address whatever voice it's connected to now." Is that the idea?
If so, I would suggest that a special "DETACH_VVID" control/event is
used for this. There's no distinct relation between a note being "on"
and whether or not Voice Controls can be used. At least with MIDI
synths, it's really rather common that you want Channel controls to
affect *all* voices, even after NoteOff, and I see no reason why our
Channel Controls should be different.
Alternatively, rather than a VOICE control, just have
special
VOICE_ON/VOICE_OFF events.
That doesn't really change anything. Whether you're using
VOICE_ON/VOICE_OFF or VOICE(1)/VOICE(0), the resulting actions and
timing are identical.
-first- order
on timestamps
-second- put voice-on ahead of all other event types.
A little ungainly, but effective as it frees the plugins to
assume that they'll get voice-on first but must consider all
other events on that timestamp as arguments to the initialization
of the voice. Of course this
not all events with that timestamp - only per-voice controls with
the VVID that was just turned on. All per-voice events have a
VVID. So it is easy to know if that VVID is active - if not, the
host screwed up.
What I am still fighting with is the idea that the host
pre-allocates VVID space. How much space for each VVID?
4 bytes. (On 32 bit archs, that is.)
Any
imposed structure?
Nope, just a void * that the synth may use in any way it likes. (Or
ignore, if it's using some "tag + search" approach; you need only the
VVID [index] for that.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
7:37 p.m.
Problem is that that requires special case event
processing in
synths. You'll need an inner event decoding loop just to get the
parameters, before you can go on with voice intantiation.
You always process all events for timestamp X before you generate X's audio
right?
1. Recv VOICE_ON, allocate a voice struct
2. Recv VELOCITY, set velocity in voice struct
3. No more events for timestamp X, next is timestamp Y
4. Process audio until stamp Y
4.a. Start playing the voice with given velocity
The alternative indeed means that you have to find
somewhere to store
the parameters until the "VOICE_ON" arrives - but that doesn't screw
up the API, and in fact, it's not an issue at all until you get into
voice stealing. (If you just grab a voice when you get a "new" VVID,
parameters will work like any controls - no extra work or special
cases.)
All this is much easier if synths pre-allocate their internal voice structs.
Host: I know SYNTH has voices 1, 2, 3 active. So I send params for voice 4.
How does VST handle this?
Send 0-VVID to
the VOICE contol with timestamp Y for note-off
I'm not quite following with the 0-VVID thing here... (The VVID *is* can tell the synth that you have nothing further to
say to this Voice
by implying that NOTE_OFF means "I will no longer use this VVID to
address whatever voice it's connected to now." Is that the idea?
The synth doesn't care if you have nothing further to say. Either it will
hold the note forever (synth, violin, woodwind, etc) or it will end
eventually on it's own (sample, drum, gong). You do, however want to be
able to shut off continuous notes and to terminate self-ending voices
(hi-hat being hit again, or a crash cymbal being grabbed).
If so, I would suggest that a special
"DETACH_VVID" control/event is
used for this. There's no distinct relation between a note being "on"
and whether or not Voice Controls can be used. At least with MIDI
synths, it's really rather common that you want Channel controls to
affect *all* voices, even after NoteOff, and I see no reason why our
Channel Controls should be different.
I don't get what this has to do with things - of course channel control
affect everything. That is their nature. You're right that a note can end,
and the host might still send events for it. In that case, the plugin
should just drop them. Imagine I piano-roll a 4 bar note with 50 different
velocity changes for a 1/2 second hihat sample. The sample ends
spontaneously (the host did not call NOTE_OFF). The sequencer still has
events, and so keeps sending them. No problem, plugin ignores them.
That doesn't really change anything. Whether
you're using
VOICE_ON/VOICE_OFF or VOICE(1)/VOICE(0), the resulting actions and
timing are identical.
Right - Aesthetics. I prefer VOICE_ON/VOICE_OFF but a VOICE control fits
our model more generically.
8:20 p.m.
On Tuesday 07 January 2003 00.31, Tim Hockin wrote:
Yes, that's true. (You loop until you see a different timestamp.)
I'm assuming that they do this at all times. There is no other
reliable way of doing it.
The problem is when the sender uses more VVIDs than there are voices,
or when voices linger in the release phase. That is, the problem is
voice stealing occurs - or rather, that there may not always be a
physical voice "object" for each in-use VVID.
0-VVID is just so you can have one control for voice on and off.
Positive means ON, negative means OFF. abs(event->vvid) is the
VVID.
Ok. Why not just use the "value" field instead, like normal Voice
Controls? :-)
Not really - but whoever *sends* to the synth will care, when running
out of VVIDs. (Unless it's a MIDI based sequencer, VVID management
isn't as easy as "one VVID per MIDI pitch value".)
My point is that if you don't have a way of doing this, there's no
way you can know when it's safe to reuse a VVID. (Release
envelopes...) Polling the synth for voice status, or having synths
return voice status events doesn't seem very nice to me. The very
idea with VVIDs was to keep communication one way, so why not keep it
that way as far as possible?
Sorry, I meant so say "*Voice* Controls", of course...
Yes.
Although the VOICE control might actually be the VELOCITY control,
where anything non-0 means "on"... A specific, non-optional VOICE
control doesn't make sense for all types of instruments, but there
may be implementational reasons to have it anyway; not sure yet.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
Problem is
that that requires special case event processing in
synths. You'll need an inner event decoding loop just to get the
parameters, before you can go on with voice intantiation.
You always process all events for timestamp X before you generate
X's audio right? 1. Recv VOICE_ON, allocate a voice struct
2. Recv VELOCITY, set velocity in voice struct
3. No more events for timestamp X, next is timestamp Y
4. Process audio until stamp Y
4.a. Start playing the voice with given velocity
Problem is step 1. If the voice allocator looks at velocity, it won't
work, since that information is not available when you do the
allocation. Likewise for setting up waveforms with velocity maps and
the like.
When are you supposed to do that sort of stuff? VOICE_ON is what
triggers it in a normal synth, but with this scheme, you have to wait
for some vaguely defined "all parameters available" point.
The
alternative indeed means that you have to find somewhere to
store the parameters until the "VOICE_ON" arrives - but that
doesn't screw up the API, and in fact, it's not an issue at all
until you get into voice stealing. (If you just grab a voice when
you get a "new" VVID, parameters will work like any controls - no
extra work or special cases.)
All this is much easier if synths pre-allocate their internal voice
structs. Host: I know SYNTH has voices 1, 2, 3 active. So I
send params for
voice 4.
Actually, it doesn't know anything about that. The physical
VVID->voice mapping is a synth implementation thing, and is entirely
dependent on how the synth manages voices. s/voice/VVID/, and you get
closer to what VVIDs are about.
How does VST handle this?
Same way as MIDI synths; MIDI pitch == note ID.
Send 0-VVID to the VOICE contol with timestamp Y for
note-off
I'm not quite following with the 0-VVID thing here... (The VVID
*is* can tell the
synth that you have nothing further to say to this
Voice by implying that NOTE_OFF means "I will no longer use this
VVID to address whatever voice it's connected to now." Is that
the idea?
The synth doesn't care if you have nothing further to say. Either
it will hold the note forever (synth, violin, woodwind, etc) or it
will end eventually on it's own (sample, drum, gong).
Yeah - and if you can't detach VVIDs, you have to find out when this
happens, which requires synth->sender feedback. (Or you basically
cannot safely reuse a VVID, ever, once you've used it to play a note.)
You do,
however want to be able to shut off continuous notes and to
terminate self-ending voices (hi-hat being hit again, or a crash
cymbal being grabbed).
Yes - but that falls in one of two categories:
1) Voice Control. (Keep the VVID for as long as you need it!)
2) Channel Control. ("Kill All Notes" type of controls.)
If so, I would
suggest that a special "DETACH_VVID" control/event
is used for this. There's no distinct relation between a note
being "on" and whether or not Voice Controls can be used. At
least with MIDI synths, it's really rather common that you want
Channel controls to affect *all* voices, even after NoteOff, and
I see no reason why our Channel Controls should be different.
I don't get what this has to do with things - of course channel
control affect everything. That is their nature. You're right
that a note can end, and the host might still send events for it.
Yep - and the note might *not* end, while the host (or rather,
"whatever sends the events" - doesn't have to be the host, IMO)
doesn't care, and just needs a "new" VVID for other things.
In that case, the plugin should just drop them.
Yes, that's the "NULL Voice"...
Imagine I
piano-roll a 4 bar note with 50 different velocity changes for a
1/2 second hihat sample. The sample ends spontaneously (the host
did not call NOTE_OFF). The sequencer still has events, and so
keeps sending them. No problem, plugin ignores them.
Yeah - but I'm talking about the other way around; when the sender
needs a VVID without a "random" relation to any lingering voice.
That
doesn't really change anything. Whether you're using
VOICE_ON/VOICE_OFF or VOICE(1)/VOICE(0), the resulting actions
and timing are identical.
Right - Aesthetics. I prefer VOICE_ON/VOICE_OFF but a VOICE
control fits our model more generically.
9:01 p.m.
1. Recv
VOICE_ON, allocate a voice struct
2. Recv VELOCITY, set velocity in voice struct
3. No more events for timestamp X, next is timestamp Y
4. Process audio until stamp Y
4.a. Start playing the voice with given velocity
Problem is step 1. If the voice allocator looks at velocity, it won't
work, since that information is not available when you do the
allocation. Likewise for setting up waveforms with velocity maps and
the like.
When are you supposed to do that sort of stuff? VOICE_ON is what
triggers it in a normal synth, but with this scheme, you have to wait
for some vaguely defined "all parameters available" point. Host: I know
SYNTH has voices 1, 2, 3 active. So I send params for
voice 4.
Actually, it doesn't know anything about that. The physical
VVID->voice mapping is a synth implementation thing, and is entirely
dependent on how the synth manages voices. s/voice/VVID/, and you get
closer to what VVIDs are about. 0-VVID is just
so you can have one control for voice on and off.
Positive means ON, negative means OFF. abs(event->vvid) is the
VVID.
Ok. Why not just use the "value" field instead, like normal Voice
Controls? :-) Not really - but whoever *sends* to the synth will
care, when running
out of VVIDs. (Unless it's a MIDI based sequencer, VVID management
isn't as easy as "one VVID per MIDI pitch value".)
Ahh, this does get interesting.
way you can know when it's safe to reuse a VVID.
(Release
envelopes...) Polling the synth for voice status, or having synths
return voice status events doesn't seem very nice to me. The very
It seems to me that voice allocation and de-allocation HAS to be a two-way
dialogue, or you have use-once VVIDs. Maybe this is OK - 2^32 VVIDs per
synth. The host only really needs to store a small number - the active
list. Obviously it can't be a linear index EVER, but it makes a fine hash
key or index modulo N.
1) Voice Control. (Keep the VVID for as long as you
need it!)
2) Channel Control. ("Kill All Notes" type of controls.)
My header already has a 'stop all sound' event. :)
Although the VOICE control might actually be the
VELOCITY control,
where anything non-0 means "on"... A specific, non-optional VOICE
control doesn't make sense for all types of instruments, but there
may be implementational reasons to have it anyway; not sure yet.
VELOCITY can be continuous - as you pointed out with strings and such. The
creation of a voice must be separate in the API, I think.
This all needs more thinking. I haven't had too much time to think on these
hard subjects the past two weeks, and I might not for a few more. I'll try
to usurp work-time when I can :)
This all leads me back to my original thoughts, that the voice-management
MUST be a two-way dialog. I don't like the idea of use-once VVIDs because
eventually SOMEONE will hit the limit. I hate limits :)
more thought needed
Tim
10:27 p.m.
On Tuesday 07 January 2003 01.55, Tim Hockin wrote:
So maybe VOICE creation needs to be a three-step process.
* Allocate voice
* Set initial voice-controls
* Voice on
This way the instrument is alerted to the fact that a new voice is
being created without deciding which entry in the velocity map to
use.
...and then there's no need for a DETACH_VVID event either, as the
"allocate voice" event implies that whatever VVID it uses will be
used for a new note for now on, regardless of what that VVID might
have been used for before.
Two problems solved! (Well, almost... Still need temporary space for
the "parameters", unless voice allocation is non-conditional.)
That doesn't really work for normal polyphonic instruments, unless
the host *fully* understands the synth's voice allocation rules,
release envelopes and whatnot. The polyphonic synth is effectively
reduced to a tracker style synth with N monophonic channels.
The POLYPHONY could be interesting, though, but I think most things
you can do with it should really be done with monophonic channels...
Because VOICE is actually a channel control?
But it's really just a per-Voice on/off switch, right? (It's just
that you don't address voices directly, but you never do that anyway.)
Yep. I ran into it when I started messing with VVIDs in Audiality.
For the MIDI sequencer, one can just grab one VVID for each MIDI
pitch for each channel and bo done with it, but for the future
"native" sequencer (no MIDI crap), there won't be any fixed limit on
the number of voices you can control on one channel, and no fixed
relation between "pitch" and "ID"...
Why would the host (or rather, sender) care about the VVIDs that are
*not* active? (Remember; "Kill All Notes" is a Channel Control, and
if you want per-voice note killing, you simply keep your VVIDs until
you're done with them - as always.)
My point is that when the host/sender no longer cares about a voice,
it can grab the VVID and tell the synth to allocate a new voice for
it. Whether or not that results in a voice without a VVID is
irrelevant, since when the host/sender reuses the VVID, it
*explicitly* says it no longer cares about whatever voice might have
been assigned to that VVID.
Cool. :-)
Why? It's up to the *instrument* to decide when the string (or
whatever) actually starts to vibrate, isn't it? (Could be VELOCITY >=
0.5, or whatever!) Then, what use is it for hosts/senders to try to
figure out where notes start and end?
1. Recv VOICE_ON, allocate a voice struct
2. Recv VELOCITY, set velocity in voice struct
3. No more events for timestamp X, next is timestamp Y
4. Process audio until stamp Y
4.a. Start playing the voice with given velocity
Problem is step 1. If the voice allocator looks at velocity, it
won't work, since that information is not available when you do
the allocation. Likewise for setting up waveforms with velocity
maps and the like.
When are you supposed to do that sort of stuff? VOICE_ON is what
triggers it in a normal synth, but with this scheme, you have to
wait for some vaguely defined "all parameters available" point. This is essentially saying that initial parameters
are
'special', and they are in many-ways (I'm sure velocity maps are
just one case).
Yes; there can be a whole lot of such parameters for percussion
instruments, for example. (Drums, cymbals, marimba etc...)
Or we can make the rule that you do not choose an
entry in a
velocity map until you start PROCESSING a voice, not when you
create it. VOICE_ON is a placeholder. The plugin should see that
a voice is on that has no velocity-map entry and deal with it whn
processing starts. Maybe not.
No, I think that's just moving the problem deeper into synth
implementations.
[...]
Actually, it
doesn't know anything about that. The physical
VVID->voice mapping is a synth implementation thing, and is
entirely dependent on how the synth manages voices.
s/voice/VVID/, and you get closer to what VVIDs are about.
But it COULD. This could become more exported. The plugin tells
the host what it's max polyphony is (a POLYPHONY control?). The
host manages voices 0 to (MAX_POLY-1) for each synth. 0-VVID is just so you can have one control for voice
on and
off. Positive means ON, negative means OFF. abs(event->vvid)
is the VVID.
Ok. Why not just use the "value" field instead, like normal Voice
Controls? :-) I dunno, being thick,
probably. :) VOICE(vid, 1) and VOICE(vid, 0) are the notation I
will use to indicate that a voice 'vid' has been turned on or off.
:)
Ok. Well, those look like Voice Controls to me. :-)
Not really -
but whoever *sends* to the synth will care, when
running out of VVIDs. (Unless it's a MIDI based sequencer, VVID
management isn't as easy as "one VVID per MIDI pitch value".)
Ahh, this does get interesting. way you can
know when it's safe to reuse a VVID. (Release
envelopes...) Polling the synth for voice status, or having
synths return voice status events doesn't seem very nice to me.
The very
It seems to me that voice allocation and de-allocation HAS to be a
two-way dialogue, or you have use-once VVIDs. Maybe this is OK -
2^32 VVIDs per synth. The host only really needs to store a small
number - the active list. Obviously it can't be a linear index
EVER, but it makes a fine hash key or index modulo N.
Yeah - but then we're back at square one, basically... (And I doubt
hashing is much point for "sane" voice counts.)
1) Voice
Control. (Keep the VVID for as long as you need it!)
2) Channel Control. ("Kill All Notes" type of controls.)
My header already has a 'stop all sound' event. :) Although the
VOICE control might actually be the VELOCITY
control, where anything non-0 means "on"... A specific,
non-optional VOICE control doesn't make sense for all types of
instruments, but there may be implementational reasons to have it
anyway; not sure yet.
VELOCITY can be continuous - as you pointed out with strings and
such. The creation of a voice must be separate in the API, I
think. This all needs more thinking. I haven't had too
much time to think
on these hard subjects the past two weeks, and I might not for a
few more. I'll try to usurp work-time when I can :)
This all leads me back to my original thoughts, that the
voice-management MUST be a two-way dialog. I don't like the idea
of use-once VVIDs because eventually SOMEONE will hit the limit. I
hate limits :)
Of course - but I don't think it has to be a two-way dialog for this
reason. And I don't think a two-way dialog can work very well in this
context anyway. Either you have to bypass the event system, or you
have to allow for quite substantial latency in the feedback direction.
Maybe synths need to have a bunch of Virtual Voices, as well as
Physical Voices? Virtual Voices would basically be stripped, "dead"
voice structs, that just track Voice Controls for VVIDs without
Physical Voices.
Then there would be two levels of "overload":
Out Of Physical Voices:
* Synth starts allocating Virtual Voices for VVIDs.
* All Voice Controls are still tracked.
* Synth may actively reevaluate Voices, switching
VVIDs from/to Physical Voices as desired.
Out Of Virtual Voices:
* Synth starts hooking VVIDs up to the "NULL Voice",
and/or starts doing instant voice stealing.
* Voice Controls may be ignored!
* Voice allocation may be suboptimal.
Note that when a synth starts stealing voices, that's actually *error
handling* going on. If a soft synth with say, 32 physical and 32
virtual voices runs out of *virtual voices*, you're deep in it; that
is nothing but serious abuse! You'll probably want to increase the
polyphony long before you get to the "50% of voices are ignored"
point.
more thought needed
Yes...
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
11:30 p.m.
Two problems solved! (Well, almost... Still need
temporary space for
the "parameters", unless voice allocation is non-conditional.)
I think if you get an allocate voice event, you MUST get a voice on event.
That doesn't really work for normal polyphonic
instruments, unless
the host *fully* understands the synth's voice allocation rules,
release envelopes and whatnot. The polyphonic synth is effectively
reduced to a tracker style synth with N monophonic channels.
two-way
dialogue, or you have use-once VVIDs. Maybe this is OK -
2^32 VVIDs per synth. The host only really needs to store a small
number - the active list.
Why would the host (or rather, sender) care about the VVIDs that are
*not* active? (Remember; "Kill All Notes" is a Channel Control, and
if you want per-voice note killing, you simply keep your VVIDs until
you're done with them - as always.) VELOCITY can
be continuous - as you pointed out with strings and
such. The creation of a voice must be separate in the API, I
think.
Why? It's up to the *instrument* to decide when the string (or
whatever) actually starts to vibrate, isn't it? (Could be VELOCITY >=
0.5, or whatever!) Then, what use is it for hosts/senders to try to
figure out where notes start and end? Of course - but I don't think it has to be a
two-way dialog for this
reason. And I don't think a two-way dialog can work very well in this
context anyway. Either you have to bypass the event system, or you
have to allow for quite substantial latency in the feedback direction.
I once had the idea that you send all your events in a given block with
negative voice-ids. The plugin responds with the proper per-plugin
voice-id.
Block start:
time X: voice(-1, ALLOC) /* a new voice is coming */
time X: velocity(-1, 100) /* set init controls */
time X: voice(-1, ON) /* start the voice */
time X: (plugin sends host 'voice -1 = 16')
time Y: voice(-2, ALLOC)
time Y: velocity(-2, 66)
time Y: voice(-2, ON)
time Y: (plugin sends host 'voice -2 = 17')
From then out the host uses the plugin-allocated
voice-ids. We get a large
(all negative numbers) namespace for new notes per block.
We get
plugin-specific voice-ids (no hashing/translating). Plugin handles voice
stealing in a plugin specific way (ask for a voice, it's all full, it returns
a voice-id you already have and internally sends voice_off).
I found it ugly at first. I like that it all is plugin-specific. Poke
holes in it?
Note that when a synth starts stealing voices,
that's actually *error
handling* going on. If a soft synth with say, 32 physical and 32
Not necessarily. I've played with soft-synths with no envelope control,
which I wanted to be mono. I set maxpoly to 1, and let it cut off tails
automatically. It isn't _necessarily_ an error.
Tim
7 Jan
7 Jan
7:58 a.m.
On Tuesday 07 January 2003 04.24, Tim Hockin wrote:
Why? Isn't a "voice on event" actually just "something" that makes
the synth activate a voice?
[...]
Ok, but I don't see the advantage of this, vs explicitly assigning
preallocated VVIDs to new voices. All I see is a rather significant
performance hit when looking up voices.
And for a continuous velocity instrument, how do you make a new
voice?
Just grab a new VVID and start playing. The synth will decide when a
physical voice should be used, just as it decides what exactly to do
with that physical voice.
Well, that's a special case, I'd say. I'm not even sure if your
average synth handles voice stealing well enough to be used that way.
(*Should* work, but it does require click free voice stealing without
too much delay. That basically requires a set of spare voices, or a
"mix twice" feature, so new notes can start playing while stolen
voices do a quick fade-out or similar.)
Anyway, with the VVID system, you do this by using a single, fixed
VVID. (No "new voice for this VVID" events.) No need to mess with the
polyphony.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
Two problems
solved! (Well, almost... Still need temporary space
for the "parameters", unless voice allocation is
non-conditional.)
I think if you get an allocate voice event, you MUST get a voice on
event. Why would the
host (or rather, sender) care about the VVIDs that
are *not* active? (Remember; "Kill All Notes" is a Channel
Control, and if you want per-voice note killing, you simply keep
your VVIDs until you're done with them - as always.)
It wouldn't - if the host has a limit of 128 voice polyphony, it
keeps a hash or array of 128 VVIDs. There is a per-instrument (or
per-channel) next_vvid variable. Whenever host wants a new voice
on an instrument it finds an empty slot on the VVID table (or the
oldest VVID if full) and sets it to next_vvid++. That is then the
VVID for the new voice. If we had to steal one, it's because the
user went too far. In that case, VOICE(oldest_vvid, 0) is probably
acceptable.
The plugin sees a stream of new VVIDs (maybe wrapping every 2^32
notes - probably OK). It has it's own internal rules about voice
allocation, and probably has less polyphony than 128 (or whatever
the host sets). It can do smart voice stealing (though the LRU
algorithm the host uses is probably good enough). It hashes VVIDs
in the 0-2^32 namespace on it's real voices internally. You only
re-use VVIDs every 2^32 notes. VELOCITY can be continuous - as you pointed out with
strings
and such. The creation of a voice must be separate in the API,
I think.
Why? It's up to the *instrument* to decide when the string (or
whatever) actually starts to vibrate, isn't it? (Could be
VELOCITY >= 0.5, or whatever!) Then, what use is it for
hosts/senders to try to figure out where notes start and end? And why is velocity becoming special again?
It isn't. VELOCITY was just an example; any control - or a
combination of controls - would do.
I think voice-on/off is well understood and applies
pretty well to
everything. I am all for inventing new concepts, but this will be
more confusing than useful, I think. Open to convincing, but
dubious.
I think the voice on/off concept is little more than a MIDIism. Since
basic MIDI does not support continous velocity at all, it makes sense
to merge "note on" and "velocity" into one, and assume that a note
starts when the resulting message is received.
With continous velocity, it is no longer obvious when the synth
should actually start playing. Consequently, it seems like wasted
code the have the host/sender "guess" when the synth might want to
allocate or free voices, since the synth may ignore that information
anyway. This is why the explicit note on/off logic seems broken to me.
Note that using an event for VVID allocation has very little to do
with this. VVID allocation is just a way for the host/sender to
explicitly tell the synth when it's talking about a new "voice
context" without somehow grabbing a new VVID. It doesn't imply
anything about physical voice allocation.
[...]
Block start:
time X: voice(-1, ALLOC) /* a new voice is coming */
time X: velocity(-1, 100) /* set init controls */
time X: voice(-1, ON) /* start the voice */
time X: (plugin sends host 'voice -1 = 16')
time Y: voice(-2, ALLOC)
time Y: velocity(-2, 66)
time Y: voice(-2, ON)
time Y: (plugin sends host 'voice -2 = 17')
From then out the host uses the plugin-allocated voice-ids. We get
a large (all negative numbers) namespace for new notes per block.
Short term VVIDs, basically. (Which means there will be voice
marking, LUTs or similar internally in synths.)
We get plugin-specific voice-ids (no
hashing/translating).
Actually, you *always* need to do some sort of translation if you
have anything but actual voice indices. Also note that there must be
a way to assign voice IDs to non-voices (ie NULL voices) or similar,
when running out of physical voices.
Plugin
handles voice stealing in a plugin specific way (ask for a voice,
it's all full, it returns a voice-id you already have and
internally sends voice_off).
You can never return an in-use voice ID, unless the sender is
supposed to check every returned voice ID. Better return an invalid
voice ID or something...
I found it ugly at first. I like that it all is
plugin-specific.
Poke holes in it?
Well, it's an interesting idea, but it has exactly the same problem
as VVIDs, and doesn't solve any of the problems with VVIDs. The fact
that it's all plugin specific looks more like a problem than an
advantage to me. We're basically back at square 1 (with "tag +
search" and/or hashing), and it doesn't really buy us much, compared
to the wrapping 32 bit VVID idea.
Note that when
a synth starts stealing voices, that's actually
*error handling* going on. If a soft synth with say, 32 physical
and 32
Not necessarily. I've played with soft-synths with no envelope
control, which I wanted to be mono. I set maxpoly to 1, and let it
cut off tails automatically. It isn't _necessarily_ an error.
8 Jan
8 Jan
4:16 a.m.
The plugin
sees a stream of new VVIDs (maybe wrapping every 2^32
notes - probably OK). It has it's own internal rules about voice
allocation, and probably has less polyphony than 128 (or whatever
the host sets). It can do smart voice stealing (though the LRU
algorithm the host uses is probably good enough). It hashes VVIDs
in the 0-2^32 namespace on it's real voices internally. You only
re-use VVIDs every 2^32 notes.
Ok, but I don't see the advantage of this, vs explicitly assigning
preallocated VVIDs to new voices. All I see is a rather significant
performance hit when looking up voices. Just grab a new VVID and start playing. The synth will
decide when a
physical voice should be used, just as it decides what exactly to do
with that physical voice.
So how does a synth tell the host how it gets activated? A VOICE_ON event
tells the host and the user 'we are allocating a VVID to use'. It also
tells the synth. If the synth wants to not play anything for Velocity <
0.5, then it should just not play anything. Just because a Voice is silent,
doesn't mean it is not active. This is a separate discussion entirely from
VVIDs.
With continous velocity, it is no longer obvious when
the synth
should actually start playing. Consequently, it seems like wasted
code the have the host/sender "guess" when the synth might want to
allocate or free voices, since the synth may ignore that information
anyway. This is why the explicit note on/off logic seems broken to me.
_Your_ logic seems broken to me :) If you have a continuous controller for
Velocity, you have one voice. So you want a new voice, you use a new VVID.
How do you standardize this interface so a host can present a UI that makes
sense?
If VOICE_ON doesn't make sense for some synth, then it still makes sense for
the user.
Block start:
time X: voice(-1, ALLOC) /* a new voice is coming */
time X: velocity(-1, 100) /* set init controls */
time X: voice(-1, ON) /* start the voice */
time X: (plugin sends host 'voice -1 = 16')
time Y: voice(-2, ALLOC)
time Y: velocity(-2, 66)
time Y: voice(-2, ON)
time Y: (plugin sends host 'voice -2 = 17')
From then out the host uses the plugin-allocated voice-ids. We get
a large (all negative numbers) namespace for new notes per block.
Short term VVIDs, basically. (Which means there will be voice
marking, LUTs or similar internally in synths.) We get
plugin-specific voice-ids (no hashing/translating).
Actually, you *always* need to do some sort of translation if you
have anything but actual voice indices. Also note that there must be a way to assign voice IDs to non-voices (ie NULL
voices) or similar,
when running out of physical voices.
if voice-ids are allocated by the plugin, there is no NULL voice. If you
run out of physical voices you steal a voice or you send back a failure for
the positive voice id.
You can never return an in-use voice ID, unless the
sender is
supposed to check every returned voice ID. Better return an invalid
voice ID or something...
Host:
send voice_on for temp vid -1
run
read events
find a voice-id -1 => new_vid
if (new_vid < 0) {
/* crap, that voice failed - handle it */
} else {
if (hash_lookup(plug->voices, new_vid)) {
/* woops, plugin stole that voice - handle it */
}
hash_insert(plug->voices, new_vid, something)
}
If the plugin wants to steal a voice, do so. If it wants to reject new
voices, do so. It is simple, easy to code and to understand.
Well, it's an interesting idea, but it has exactly
the same problem
as VVIDs, and doesn't solve any of the problems with VVIDs. The fact
It has none of the problems of VVIDs. The only problem is that it requires
dialog.
* no carving of a VVID namespace for controller plugins
* the plugin and the host always agree on the active list of voices
* host sends voice_off no release
- plugin puts the VID in the free-list immediately
- host never sends voice_off
- plugin puts the VID in the free-list whenever it finishes
- plugin can alert the host or not
- host sends events or voice_off too late
- plugin recognizes that the voice is off and ignores events
- host sends voice_off with a long release
- plugin puts the VID in the free-list as soon as possible
- host overruns plugin's max poly
- plugin chooses a VID and stops it, returns that VID (steals the voice)
or plugin rejects new voice
what am I missing?
search" and/or hashing), and it doesn't
really buy us much, compared
to the wrapping 32 bit VVID idea.
With a large VVID pool we still need:
host:
/* be sure we can make a new vvid */
if (cur_poly == max_poly) {
find an eligible vvid
tell the plugin it can re-use the voice on this vvid (voice_off?)
} else {
cur_poly++;
}
/* find a vvid that is not currently playing */
do {
this_vvid = vvid_next++;
while (vvid_is_active(this_vvid);
send_event(queue, VOICE_ON, this_vvid);
[voice-stealing...]
(*Should* work, but it does require click free voice
stealing without
Which is the plugin's problem in any solution we devise.
1:24 p.m.
On Wed, Jan 08, 2003 at 12:09:56 -0800, Tim Hockin
wrote:
Can you elucidate what your objections are? I've stated my problems with
VVIDs :)
Tim
What is LUT? What is voice-marking? The
negative VVIDs are valid for the
duration of the block, after which they use their new names. It seems
simple to me.
It doesn't to me!
2:29 p.m.
On Wed, Jan 08, 2003 at 09:18:38AM -0800, Tim Hockin wrote:
I dont like the fact that the id changes after the first block its used in
and that the instrument has to comminicate the internal VID back to the
host.
- Steve
On Wed, Jan
08, 2003 at 12:09:56 -0800, Tim Hockin wrote:
Can you elucidate what your objections are? I've stated my problems with
VVIDs :) What is LUT? What is voice-marking? The
negative VVIDs are valid for the
duration of the block, after which they use their new names. It seems
simple to me.
It doesn't to me!
3:02 p.m.
On Wed, Jan 08, 2003 at 10:32:20AM -0800, Tim Hockin wrote:
As a plugin author I like that the host does it ;) One less thing to take
care of.
- Steve
I dont like
the fact that the id changes after the first block its used in
and that the instrument has to comminicate the internal VID back to the
host.
Hrrm, I can't argue that a temp ID is pretty, but I _like_ that the plugin
allocates the VID.
3:15 p.m.
Hrrm, I
can't argue that a temp ID is pretty, but I _like_ that the plugin
allocates the VID.
As a plugin author I like that the host does it ;) One less thing to take
care of.
3:42 p.m.
On Wed, Jan 08, 2003 at 11:09:50 -0800, Tim Hockin wrote:
As a host author, I like that I can account for your
voices by REAL voice
IDs. :) Besides that, don't you have an array of voice structs or something
similar in EVERY plugin? Just return me your key. They don't have to be
sequential or even small, just positive (or if you prefer, non-zero).
There needs to be some kind of abstraction because you might be talking
about a previous incarnation of voice that I've stolen from.
- Steve
3:50 p.m.
On Wed, Jan 08, 2003 at 11:09:50 -0800, Tim Hockin
wrote:
You will have told me that already, so I will know better. Complexity
belongs in the host or SDK.
(I like these short messages - easier to follow :)
As a host author, I like that I can account for
your voices by REAL voice
IDs. :) Besides that, don't you have an array of voice structs or something
similar in EVERY plugin? Just return me your key. They don't have to be
sequential or even small, just positive (or if you prefer, non-zero).
There needs to be some kind of abstraction because you might be talking
about a previous incarnation of voice that I've stolen from.
6:14 p.m.
On Wednesday 08 January 2003 20.09, Tim Hockin wrote:
As a host author, I like that I can account for your voices by REAL
voice IDs. :)
Well, I still can't see why. Trackers used to do it this way, but h/w
synths stopped doing it about when CV started to lose popularity,
AFAIK.
That said, one VVID == one physical voice, or possibly no voice at
all. (And if you care, the latter only happens when you're
overloading your polyphony.) That is, you can still do whatever you
like with a single voice for as long as you like. The problems that
MIDI has with addressing voices does not apply here, whether voices
are addressed directly or virtually.
Hrrm, I can't argue that a temp ID is pretty, but
I _like_ that
the plugin allocates the VID.
As a plugin author I like that the host does it ;) One less thing
to take care of. Besides that, don't you have an array of voice
structs or something similar in EVERY plugin?
Nope - so why care what the synth actually does?
Just return me your
key.
Why? What do you want it for?
Why not just give *me* (the synth) somewhere to put my key instead,
so it comes with the VVID without anyone but me ever having to look
at it?
They don't have to be sequential or even small,
just positive
(or if you prefer, non-zero).
How about 32 bit, or void *; no additional restrictions?
In the end, it makes your life easy, too, since your
key is my key
- you don't need to hash or map anything.
That's great, but with VVIDs + table, you can have that as well -
without two-way communication or senders having to know anything
about it. (Senders deal only with indices, and the host manages the
table. Only synths will ever access the entries in the table)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
8:02 p.m.
That said, one VVID == one physical voice, or possibly
no voice at
all. (And if you care, the latter only happens when you're
overloading your polyphony.) That is, you can still do whatever you
Or when the hihat sound is done, but the user has programmed events for
later on that same VVID.
That's great, but with VVIDs + table, you can have
that as well -
without two-way communication or senders having to know anything
about it. (Senders deal only with indices, and the host manages the
table. Only synths will ever access the entries in the table)
Synth needs to know where the table is - We'd need to do double-indirection
so that the table can move if needed.
struct voice *v = myvoices[(*(host->vvid_table))[vvid]];
6:05 p.m.
On Wednesday 08 January 2003 19.56, Steve Harris wrote:
On Wed, Jan 08, 2003 at 10:32:20AM -0800, Tim Hockin
wrote:
As a plugin author I like that the host does it ;) One less thing
to take care of.
Well, you still have to keep track of your voices, but indeed; let
the host do as much as possible of the work.
(And BTW: Again, the sender is *not* always the host - or you can't
have event processors in the net.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
I dont
like the fact that the id changes after the first block
its used in and that the instrument has to comminicate the
internal VID back to the host.
Hrrm, I can't argue that a temp ID is pretty, but I _like_ that
the plugin allocates the VID.
6:02 p.m.
On Wednesday 08 January 2003 19.32, Tim Hockin wrote:
So do I, but I think there are too many side effects.
And each VVID actually being the index of a void * to do what you
want with isn't *that* much worse, is it? Not as effecient as "VVID
*is* my value", but "VVID is an index to my value" isn't many cycles
from it.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
I dont like
the fact that the id changes after the first block
its used in and that the instrument has to comminicate the
internal VID back to the host.
Hrrm, I can't argue that a temp ID is pretty, but I _like_ that the
plugin allocates the VID.
5:58 p.m.
On Wednesday 08 January 2003 19.23, Steve Harris wrote:
On Wed, Jan 08, 2003 at 09:18:38AM -0800, Tim Hockin
wrote:
I dont like the fact that the id changes after the first block its
used in and that the instrument has to comminicate the internal VID
back to the host.
And (somewhat related to that), even though VVIDs come with a host
managed table of void *, int32 or whatever, it doesn't have any
issues with inter-process gateways, wire connections and the like
that any two-way communication system has. It's not latency sensitive
(obviously), and the table isn't an issue, since it's only used by
the *synth*. (The sender only uses the VVIDs, which are just indices
into the table.)
That is, if you want to talk to a remote synth, just allocate VVIDs
from the remote *host*, and everything will Just Work(TM).
(Which reminds me; the alloc_vvids() call needs to know which
receiver the VVIDs are for, obviously. The target queue as an
argument should be sufficient, as the host should be able to keep
track of which queues are gateways to remote hosts.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
On Wed,
Jan 08, 2003 at 12:09:56 -0800, Tim Hockin wrote:
Can you elucidate what your objections are? I've stated my
problems with VVIDs :) What is LUT? What is voice-marking? The
negative VVIDs are
valid for the duration of the block, after which they use
their new names. It seems simple to me.
It doesn't to me!
4:42 p.m.
On Wednesday 08 January 2003 09.09, Tim Hockin wrote:
[...]
You get a 32 bit integer value, and you have to look up the voice
object it refers to. No matter how you do it, it's going to be more
expensive than grabbing the pointer from an array indexed by the
value.
It doesn't because the host/sender doesn't really care. A controller
or sequencer is just supposed to deliver events. It shouldn't care
more about voice activation than it does about the exact relation
between events and audio output.
This VVID thing is just the same thing as MIDI pitch - except that
VVIDs don't double as note pitch. When you want to control a specific
note in MIDI, you address it using the MIDI pitch of that note. The
only difference with VVIDs is that the VVID you use for a particular
note does not imply a specific pitch.
As to the UI, that's entirely up to the application designer. If you
want it to look and act like a traditional MIDI sequencer, just use
one VVID for each pitch in the MIDI scale, and address Voice Controls
by MIDI pitch.
What is LUT?
Look-Up Table. (So you can find objects without searching.)
Because the plugin can allocate them, the plugin need not hash or
translate. It can be a direct index.
So, how do you perform voice stealing?
You have to tell the host/sender when a voice index becomes invalid,
and you have to make damn sure the timing is right, so you don't end
up getting some events for the "old" voice with the same ID. You can
forget about "unstealing" voices, of course, as the host/sender will
have to stop sending events to a voice when you tell it it has been
stolen.
It's possible to get right (I think), but again, I don't see the
point in going down this path.
Why not just leave voice allocation to synths, the way it's been done
in professional MIDI gear all the time? It works! The only thing
we're really adding here is the ability to separate voices from pitch
- that's all.
Yeah - and what do you do with the stray events you'll get because of
the feedback latency? (This is an issue with one block latency
already, and can only get worse in SMP hosts and other distributed
systems.)
Well, it looks a whole lot more complicated than VVIDs to me. :-)
(And regardless; hashing is definitely more expensive than grabbing a
pointer from an array.)
Probably not, if I understand the above correctly.
No, it has nothing to do with VOICE_OFF. We're only saying we won't
talk about that voice any more. The synth may do whatever it likes.
(Obviously, it's generally a good idea to trigger the release before
doing this.)
Ok, but I
don't see the advantage of this, vs explicitly
assigning preallocated VVIDs to new voices. All I see is a rather
significant performance hit when looking up voices.
Where a perf hit? Just grab a
new VVID and start playing. The synth will decide
when a physical voice should be used, just as it decides what
exactly to do with that physical voice.
So how does a synth tell the host how it gets activated? A
VOICE_ON event tells the host and the user 'we are allocating a
VVID to use'. It also tells the synth.
Yes, but why call it "VOICE_ON" when that's not what it means?
If the synth wants to not
play anything for Velocity < 0.5, then it should just not play
anything. Just because a Voice is silent, doesn't mean it is not
active.
Right.
For implementational reasons, I'm claiming that it makes a lot of
sense to assume that synths know what to do when they receive the
first event to a VVID that doesn't have a voice. I don't see why the
case "this VVID has no voice" should be something that the
host/sender *has* to worry about. (Especially since the whole concept
is irrelevant to monophonic synths. These will ignore VVIDs anyway.)
This is a separate discussion entirely from VVIDs.
Yes; VVIDs are just a means of addressing voices. Voice allocation is
a synth implementation issue. That's *exactly* why I don't like the
idea of mixing these two things up on the API level.
With continous
velocity, it is no longer obvious when the synth
should actually start playing. Consequently, it seems like wasted
code the have the host/sender "guess" when the synth might want
to allocate or free voices, since the synth may ignore that
information anyway. This is why the explicit note on/off logic
seems broken to me.
_Your_ logic seems broken to me :) If you have a continuous
controller for Velocity, you have one voice. So you want a new
voice, you use a new VVID. How do you standardize this interface so
a host can present a UI that makes sense? If VOICE_ON doesn't make sense for some synth,
then it still makes
sense for the user.
Why? (Unless the user is a tracker die-hard.)
VOICE_ON, assuming that there can be continous velocity synths, has
no corresponding MIDI event, and doesn't really mean anything to the
user, so I don't see why it would make sense to any user. It's an API
thing entirely.
Block start:
time X: voice(-1, ALLOC) /* a new voice is coming */
time X: velocity(-1, 100) /* set init controls */
time X: voice(-1, ON) /* start the voice */
time X: (plugin sends host 'voice -1 = 16')
time Y: voice(-2, ALLOC)
time Y: velocity(-2, 66)
time Y: voice(-2, ON)
time Y: (plugin sends host 'voice -2 = 17')
From then out the host uses the plugin-allocated voice-ids. We
get a large (all negative numbers) namespace for new notes per
block.
Short term VVIDs, basically. (Which means there will be voice
marking, LUTs or similar internally in synths.) What is voice-marking?
What I'm doing in Audiality; sender hands the synth a Voice ID, and
the synth puts that in the voice it allocates. When further events
referring to that Voice ID are received, the synth searches the
voices for the Voice ID, and then (if a voice is found) performs the
requested action on that voice.
The negative VVIDs are valid
for the duration of the block, after which they use their new
names. It seems simple to me.
It's less simple than what I'm doing in Audiality, and pretty much
only succeeds in providing half a solution to the main problem with
that system ("When can I safely reuse a voice ID?"), while
introducing another, more serious problem: The host/sender
eventually(*) gets another ID, which will either have the same
problem as the negative ID, or (much worse) will be a direct voice
index, preventing the synth from performing voice stealing.
(*) When does the sender get the "real" voice ID? Well, forget about
the next block, unless the controller/sender and the synth are
running on the same CPU, or possibly the same SMP machine.
Also, keep in mind that any feedback of this kind requires a real
connection in the reverse direction. This makes the API and hosts
more complex - and I still can't see any benefit, really.
We get plugin-specific voice-ids (no
hashing/translating).
Actually, you *always* need to do some sort of translation if you
have anything but actual voice indices. Also note that there must
be a way to
assign voice IDs to non-voices (ie NULL voices) or
similar, when running out of physical voices.
if voice-ids are allocated by the plugin, there is no NULL voice.
If you run out of physical voices you steal a voice or you send
back a failure for the positive voice id. You can never
return an in-use voice ID, unless the sender is
supposed to check every returned voice ID. Better return an
invalid voice ID or something...
Host:
send voice_on for temp vid -1
run
read events
find a voice-id -1 => new_vid
if (new_vid < 0) {
/* crap, that voice failed - handle it */
} else {
if (hash_lookup(plug->voices, new_vid)) {
/* woops, plugin stole that voice - handle it */
}
hash_insert(plug->voices, new_vid, something)
}
If the plugin wants to steal a voice, do so. If it wants to reject
new voices, do so. It is simple, easy to code and to understand. Well, it's
an interesting idea, but it has exactly the same
problem as VVIDs, and doesn't solve any of the problems with
VVIDs. The fact
It has none of the problems of VVIDs. The only problem is that it requires dialog.
That's a rather serious problem, OTOH...
* no carving of a VVID namespace for controller
plugins
No, plugins have to do that in real time instead.
* the plugin and the host always agree on the active
list of voices
I don't see how this is possible. The one block latency means there
will be occasional events that must be detected and thrown away, one
way or another.
Maybe it's sufficient to have synths mark newly stolen voices, so
they ignore directly addressed events until it's known that the no
more events for the old context will arrive? (Problem is, when you do
know that? If the latency is allowed to be more than one block,
synths will have to await a "voice renamed" acknowledge event from
the host/sender...)
* host sends voice_off no release
- plugin puts the VID in the free-list immediately
- host never sends voice_off
- plugin puts the VID in the free-list whenever it finishes
- plugin can alert the host or not
- host sends events or voice_off too late
- plugin recognizes that the voice is off and ignores events
- host sends voice_off with a long release
- plugin puts the VID in the free-list as soon as possible
- host overruns plugin's max poly
- plugin chooses a VID and stops it, returns that VID (steals
the voice) or plugin rejects new voice
what am I missing?
Well, this should work, but I think the two issues; the feedback
requirement, and the inability to cope with more than one block of
feedback latency, are a bit too serious.
search"
and/or hashing), and it doesn't really buy us much,
compared to the wrapping 32 bit VVID idea.
With a large VVID pool we still need:
host:
/* be sure we can make a new vvid */
if (cur_poly == max_poly) {
find an eligible vvid
tell the plugin it can re-use the voice on this vvid
(voice_off?) } else {
cur_poly++;
}
What does cur_poly has to do with anything? (Sequencers and the like
shouldn't care about polyphony or voice allocation, IMNSHO.)
/* find a vvid that is not currently playing */
do {
this_vvid = vvid_next++;
while (vvid_is_active(this_vvid);
Again, this is voice allocation. Leave this to the synth.
Anyway, what you describe above has very little in common with my
idea of VVIDs. The whole point with VVIDs is that they're *virtual* -
and that obviously means they have no fixed relation to physical
voices. The very reason why they were suggested at all was to
eliminate two-way communication between senders and synths.
The approach I have in mind is this:
SENDER:
pool = xap_alloc_vvids(<as many as we need>);
Start voice context:
* //(if this can happen at all)
if(we're out of VVIDs)
{
//Add some to our local pool
pool += xap_alloc_vvids(<some>);
}
* vvid = get_vvid()
* xap_send(synth, DETACH_VVID, vvid)
Send Voice Control event:
* xap_send(synth, VOICE_<whatever>, vvid, ...)
Stop using voice context:
* free_vvid(vvid)
* (Synth doesn't care about this.)
pool and get/free_vvid() are local to the sender. It could be as
simple as a base index for the 128 VVIDs needed to cover the range of
MIDI pitch values for a MIDI channel. In that case, get_vvid() would
be
get_vvid(int pitch)
{
return vvid_base + pitch;
}
and free_vvid() would be a NOP.
SYNTH:
Handle Voice Control event:
if(!vvid_table[ev->vvid])
vvid_table[ev->vvid] = alloc_voice();
...
Handle event for (SYNTH_voice *)(vvid_table[ev->vvid])
...
Handle DETACH_VVID, "Voice Finished" or "Voice Stolen":
vvid_table[ev->vvid] = NULL;
Note that the vvid_table entries could be integers, void * or
whatever; the point is just that the space is for the *synth* to use
as it sees fit.
Also note that this example assumes that alloc_voice() returns a
dummy voice if allocation fails. (Most synths will probably just
steal a voice, though.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
5:31 p.m.
On Wed, Jan 08, 2003 at 09:36:08 +0100, David Olofson wrote:
For implementational reasons, I'm claiming that it
makes a lot of
sense to assume that synths know what to do when they receive the
first event to a VVID that doesn't have a voice. I don't see why the
case "this VVID has no voice" should be something that the
host/sender *has* to worry about. (Especially since the whole concept
is irrelevant to monophonic synths. These will ignore VVIDs anyway.)
But the instrument has to be able to tell control changes to stolen
voices from control changes for a new voice from a voice that should
replace the new voice in the same id (like with midi's pitch=id).
Its easier if it doesn't have to keep track of which are which.
Again, this is voice allocation. Leave this to the
synth.
Absolutly.
- Steve
6:40 p.m.
On Wednesday 08 January 2003 22.25, Steve Harris wrote:
On Wed, Jan 08, 2003 at 09:36:08 +0100, David Olofson
wrote:
Well, instead of NULLing VVID entries for stolen voices, connect them
to a dummy voice.
Another alternative (which is looking more and more attractive to me)
is to use 'int' instead of 'void *' for VVID entries. Then you can
just use one value (-1) for "no voice" and another (-2) for "dead
VVID". Other values would be physical voice indices or whatever fits
the implementation.
(Well, you *can* do that by pointing VVID entries at various objects
that are not voices, and check the pointers, but that's not too
sexy... :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
For implementational reasons, I'm claiming
that it makes a lot of
sense to assume that synths know what to do when they receive the
first event to a VVID that doesn't have a voice. I don't see why
the case "this VVID has no voice" should be something that the
host/sender *has* to worry about. (Especially since the whole
concept is irrelevant to monophonic synths. These will ignore
VVIDs anyway.)
But the instrument has to be able to tell control changes to stolen
voices from control changes for a new voice from a voice that
should replace the new voice in the same id (like with midi's
pitch=id).
Its easier if it doesn't have to keep track of which are which.
8:05 p.m.
Another alternative (which is looking more and more
attractive to me)
is to use 'int' instead of 'void *' for VVID entries. Then you can
just use one value (-1) for "no voice" and another (-2) for "dead
VVID". Other values would be physical voice indices or whatever fits
the implementation.
It's attractive to use special values for meanings. The plugin could tell
the host that a VVID is done by setting it to a value. Same for errors.
How is this different from a plugin sending event back to the host? And
what of remote plugins? Do they have shared-memory access to the VVID table
or is it function-call based?
Tim
7:01 p.m.
It doesn't because the host/sender doesn't
really care. A controller
or sequencer is just supposed to deliver events. It shouldn't care
more about voice activation than it does about the exact relation
between events and audio output.
OK, and we seem to agree that a VOICE_ALLOC or PREP_VOICE or something is
needed to mark that voice as re-usable.
VOICE_INIT_START
VOICE_CONTROL_SET
VOICE_INIT_STOP
It's not NAMED VOICE_ON, but it is semantically the same, yes?
If VOICE_ON
doesn't make sense for some synth, then it still makes
sense for the user.
Why? (Unless the user is a tracker die-hard.) VOICE_ON, assuming that there can be continous
velocity synths, has
a voice has to be started. Maybe not. Maybe the synth can report that it
has N voices on at all times. Hmm. Still, VOICE_ALLOC is akin to note_on.
Also, keep in mind that any feedback of this kind
requires a real
connection in the reverse direction. This makes the API and hosts
more complex - and I still can't see any benefit, really.
We already have a rudimentary reverse path.
So, how do you perform voice stealing?
You have to tell the host/sender when a voice index becomes invalid,
yep - as you point out, it requires 1-block latency.
It has none of
the problems of VVIDs.
Probably not, if I understand the above correctly.
The only problem is that it requires dialog.
That's a rather serious problem, OTOH... * no carving
of a VVID namespace for controller plugins
No, plugins have to do that in real time instead. /* find a
vvid that is not currently playing */
do {
this_vvid = vvid_next++;
while (vvid_is_active(this_vvid);
Again, this is voice allocation. Leave this to the synth.
9 Jan
9 Jan
2:19 a.m.
[Replying to some posts by Tim Hockin.]
On Wednesday 08 January 2003 23.55, Tim Hockin wrote:
[...]
Where? (The VVID entries? No, those are "private" to synths!)
[...]
And that is what I am not convinced of - I'm not against VVIDs, I
just want to play it out..
Well, unless I'm forgetting something, it's basicaly "just" the
latency issue, which seems to make controlling remote synths
impractical, if at all possible. (I think it needs further API logic
to work. See below.)
Apart from that, I just think it's ugly having both hosts and senders
mess with "keys" that really belong in the synth internals. Even
having hosts provide VVID entries (which they never access) is
stretching it, but it's the cleanest way of avoiding "voice
searching" proposed so far, and it's a synth<->local host thing only.
BTW, we've already agreed on doing this for control addressing. (The
cookies that replaced control indices.) The big difference is that
that's not a sample accurate real time protocol.
No, plugins have a fixed namespace - they dole out real VIDs to
whomever asks for them.
Well, yes. It's just that VIDs become illegal as voices are stolen,
so synths have to remember which voices should not accept direct
addressing. (Those should respond only to the temporary negative
virtual VIDs, until the host starts using the real VID - whenever it
find out about that. That's where >1 block latency becomes seriously
troublesome - the *real* latency issue.)
I think that's really rather counter-intuitive. Isn't part of the
point with handing out a VID that you generate yourself that you
shouldn't have to check incoming VIDs all the time?
Further, I don't like the idea of forcing senders to virtualize VIDs
internally, just to be able to use *both* VIDs they invent themselves
(the negative ones) and "real" VIDs returned from the synths.
You have a pool of VVIDs. Some of them are long-lasting. Some are
short lasting. You always want to find the LRU VVID. If there are
available VVIDs, take the LRU free one. If there are not, you
either need to voice-steal at the host or alloc more VVIDs. Right?
Well, what *actually* made me comment on that, is that I thought
"vvid_is_active()" had something to do with whether or not the
*synth* is using the VVID.
Was that the idea? If so; again; VVID entries are not for feedback;
they simply do not exist to senders. They're a host provided VVID
mapping service for synths; nothing else.
So, as to "allocating" VVIDs, it's nothing more than a matter of
keeping "note contexts" apart. In many cases, you don't even need a
VVID manager for that. All you have to guarantee is that there is one
VVID for each note you want to control at any time.
On Thursday 09 January 2003 00.06, Tim Hockin wrote:
They can handle it by actually doing what the hint suggests; sample
the "initializer" control values only when a note is started. That
way, they'll "sort of" do the right thing even when driven by data
generated/recorded for synths/sounds that use these controls as
continous. And more interestingly; continous control synth/sounds can
be driven properly by initializer oriented data.
On Thursday 09 January 2003 00.49, Tim Hockin wrote:
This is where the confusion/disagreement is, I think: I don't think
of this event as "INIT_START", but rather as "CONTEXT_START". I
don't
see the need for a specific "init" part of the lifetime of a context.
Initialization ends whenever the synth decides to start playing
instead of just tracking controls.
When you want to play a note, you create a context (by grabbing a
VVID and saying "VOICE_ALLOC" or whatever), and then you just send
control events. Some control changes will get the synth to play
sound, and some will instantly or eventually stop the sound. It's
entirely possible that the synth will sometimes just track controls,
using a fake voice, or that it will just disable most of the voice
code, when no sound is to be generated. (It's really two ways of
doing the same thing, only the former seems more "honest" in terms of
actual polyphony vs CPU load, since "fake voices" wouldn't count
towards polyphony.)
The context never *explicitly* ends, but you could say that it ends
physically when the sender has reassigned the VVID and the synth has
killed the voice. Thus, no need for a "VOICE_END" or similar event
either.
a voice has to be started. Maybe not. Maybe the
synth can report
that it has N voices on at all times. Hmm. Still, VOICE_ALLOC is
akin to note_on.
Well, if a voice can be "started" and still actually both silent and
physically deactivated (that is, acting as or being a dump control
tracker) - then yes.
(A sensible API shouldn't make this illegal, and I can't really see
how it could prevent it.)
Also, keep in
mind that any feedback of this kind requires a real
connection in the reverse direction. This makes the API and hosts
more complex - and I still can't see any benefit, really.
We already have a rudimentary reverse path. The only problem is that it requires dialog.
That's a rather serious problem, OTOH... * no carving of a VVID namespace for controller
plugins
No, plugins have to do that in real time instead. Are VVIDs global or per-plugin? Sorry, I
forget what we had decided on that..
For practical reasons, I think they're best handled as per-host. That
is, they're "global" as long as you're only talking to local synths,
but you really should think of them as *per-plugin* when you want to
talk to synths. (That way, you can connect to remote synths
transparently WRT VVIDs.)
So, officially:
VVIDs are per plugin.
For host authors:
VVIDs *can* be managed globaly for the local host.
/* find a vvid that is not currently playing */
do {
this_vvid = vvid_next++;
while (vvid_is_active(this_vvid);
Again, this is voice allocation. Leave this to the synth. Yes, and
that's my problem with it. Or rather; it's ok for synths
to be able to hint that they use controls this way, but designing
the voice addressing/allocation scheme around it has serious
implications.
Yes, definitely hint. Anal-retentive hosts will show it as an
init-option only if it is flagged as such. Synths still need to
handle spurious and incorrect events (fall through I'd guess), but
it is a nice hint to the UI. Seriously,
though; there has to be *one* of DETACH_VVID and
VOICE_ALLOCATE. From the implementation POV, it seems to me that
they are essentially equivalent, as both are effectively used
when you want to say "I'll use this VVID for a new context from
now on." VOICE_ALLOCATE is obviously closer to the right name for
that action.
Agreed - they are semantically the same. The question is whether
or not it has a counterpart to say that init-time controls are
done. As for redundancy - I see it as minimum requirement.
Suppose I want to turn a voice on with no control changes from the
default (no velocity, nothing).
Well, that's equivalent to a MIDI NoteOn with a velocity of 0.
(NoteOff shorthand for running status, that is.) Why would you want
to do that?
For a continous velocity instrument, this is obvious; default
velocity has to be 0, or you'll have a "random" note started soon as
a voice is allocated. Thus you *have* to change the velocity control
to start a note.
For a "latched velocity" instrument (MIDI style), it's exactly the
same thing. There will be a NOTE control, and it has to be "off" by
default. Just set it to "on" to start a note with default velocity.
BTW, it might be a good idea to always provide NOTE output from
senders, even though continous velocity and similar synths won't care
about it. Then again, continous velocity data doesn't work very well
as velocity data for note based synths, so it's probably not much
use...
Something will have to do some transformations to make this work -
and that's way beyond the API level. Analyze entire "notes" of
continous velocity data and calculate a note-on velocity from that;
that sort of stuff. Or just connect VELOCITY to the VOLUME input, and
use the synth's default velocity for note-ons? Maybe...
I need to send SOMETHING to say
"connect this VVID to a voice". The minimum required is a VOICE_ON
or similar.
Yes. "VOICE_ALLOC" doesn't trigger a MIDIism allergy reaction for me
at least, but it's still a bit confusing...
For something that has no per-voice controls (e.g. a
white-noise machine) you still need to send some event.
Fiddle with the NOTE control, maybe? (Which would default to "off",
of course.)
And I'd
rather see the voice-on protocol be consistent for all instruments.
Me too, but controlling note based and continous control synths the
same way is tricky...
Though, you *can* make the NOTE control continous, rather than a
switch... Traditional synths would just check it for >0, while
continous velocity synths would actually interpret it as the note
velocity input.
So why not call it VELOCITY, then, and ditch NOTE?
Well, the main reason is release velocity for note based synths. If
you have only a VELOCITY control, you can interpret the change from 0
to >0 as "note on", and the actual value as the note velocity. Then
you would just wait until VELOCITY becomes 0 again, which means "note
off".
Now, how do we express release velocity with that scheme? Negative
values? (Could make a continous velocity synth blow up!) Current
VELOCITY value before VELOCITY goes 0? (Requires two VELOCITY events
to implement note off with velocity, and that would make no sense to
a continous velocity synth.)
Use both NOTE and VELOCITY controls (both continous), and have NOTE
be the primary one? Continous velocity synths would normally not have
a VELOCITY input, but would look at the value of NOTE. Other synths
would look at both, but interpret NOTE as a switch, where >0 means
"on".
Still broken, though: Release velocity doesn's fit in... :-/
Use a third control for that!? Actually, that makes quite some sense,
since many real instruments use totally different mechanisms for
starting and stopping notes. Pianos. Cymbals...
VELOCITY vs DAMPING, or something. (Makes sense for continous
velocity instruments as well!)
If that means you have to send two events
(VOICE_ALLOC, VOICE_ON)
for the white-noise maker, then I can live with that.
Well, yes. And you'll also have to send a third event (corresponding
to VOICE_OFF) to stop it, since just "letting go" of a VVID doesn't
affect anything. (It's a NOP, as far as the API and synths are
concerned.)
If nothing else, *that* should indicate where this VOICE_ON really
belongs - and I don't think it's anywhere near VVID/voice management.
It's a Voice Control thing.
On Thursday 09 January 2003 00.55, Tim Hockin wrote:
[...]
Synth needs to know where the table is - We'd need
to do
double-indirection so that the table can move if needed.
struct voice *v = myvoices[(*(host->vvid_table))[vvid]];
Why double indirection? I think it's enough to say that you must
never store the pointer across process() calls. Note that senders
don't use the table, so it doesn't matter if they cause reallocation
by asking for more VVIDs while processing. Event processors might
have to worry about it, though.
On a sidenote, event processors may also want to be able to find out
whether or not input VVIDs are compatible with the target of the
output. Doesn't make much sense to manage your own VVIDs if you never
need to allocate your own voices... (Transpose and delay plugins, for
example.)
On Thursday 09 January 2003 00.59, Tim Hockin wrote:
[...]
It's attractive to use special values for
meanings. The plugin
could tell the host that a VVID is done by setting it to a value.
Same for errors.
How is this different from a plugin sending event back to the host?
(See above. VVID entries are for synths only.)
And what of remote plugins?
Allocate VVIDs from the remote host.
Obviously, you are not allowed to assume that a VVID (the index) is
globally unique. VVIDs for remote synths may well overlap with VVIDs
for local synths, or remote synths on other hosts.
Do they have shared-memory access to
the VVID table or is it function-call based?
They have no access at all, except indirectly through the events sent
to the synth. (And that's write-only.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
5:23 a.m.
that it has N
voices on at all times. Hmm. Still, VOICE_ALLOC is
akin to note_on.
Well, if a voice can be "started" and still actually both silent and
physically deactivated (that is, acting as or being a dump control
tracker) - then yes. Apart from that, I just think it's ugly having
both hosts and senders
mess with "keys" that really belong in the synth internals. Even
I agree to some extent. I'm just idearizing still.
having hosts provide VVID entries (which they never
access) is
stretching it, but it's the cleanest way of avoiding "voice
searching" proposed so far, and it's a synth<->local host thing only.
If the host never accesses the VVID table, why is it in the host domain and
not the plugins? Simpler linearity? I don't buy that.
The plugin CAN use the VVID table to store flags about the voice, as you
suggested. I just want to point out that this is essentially the same as
the plugin communicating to the host about voices, just more passively. It
seems useful.
If the plugin can flag VVID table entries as released, the host can have a
better idea of which VVIDs it can reuse.
Well, what *actually* made me comment on that, is that
I thought
"vvid_is_active()" had something to do with whether or not the
*synth* is using the VVID.
Was that the idea? If so; again; VVID entries are not for feedback;
they simply do not exist to senders. They're a host provided VVID
mapping service for synths; nothing else.
That wasn't the idea until you suggested using int32 for error status :)
They can handle it by actually doing what the hint
suggests; sample
the "initializer" control values only when a note is started. That
way, they'll "sort of" do the right thing even when driven by data
generated/recorded for synths/sounds that use these controls as
continous. And more interestingly; continous control synth/sounds can
be driven properly by initializer oriented data.
Am I losing my mind or are we back at a prior scenario?
Init controls:
time X: ALLOC_VOICE
time X: CONTROL A SET
time X: CONTROL B SET
This tastes just like VOICE_ON, SET, SET. If controls A and B are both
required to start a voice, the synth has to expect both.
Agreed - they
are semantically the same. The question is whether
or not it has a counterpart to say that init-time controls are
done.
This is where the confusion/disagreement is, I think: I don't think
of this event as "INIT_START", but rather as "CONTEXT_START". I
don't
see the need for a specific "init" part of the lifetime of a context.
Initialization ends whenever the synth decides to start playing
instead of just tracking controls. physically when the sender has reassigned the VVID and
the synth has
killed the voice. Thus, no need for a "VOICE_END" or similar event
either.
The host still has to be able to end a voice, without starting a new one.
For a continous velocity instrument, this is obvious;
default
velocity has to be 0, or you'll have a "random" note started soon as
a voice is allocated. Thus you *have* to change the velocity control
to start a note.
For a "latched velocity" instrument (MIDI style), it's exactly the
same thing. There will be a NOTE control, and it has to be "off" by
default. Just set it to "on" to start a note with default velocity.
That's fine, but can't it be consistent? The continuous velocity instrument
does not suffer because it has to accept a VOICE_ON (what you called NOTE
here). Does it map perfectly, no. Does it map well enough, yes - and it
has the benefit of being consistent, and easy to explain.
Realistically MOST synths will have at least one init-time control
(velocity). As we evolve, this can go away and just be a normal control.
But until then we need a consistent way to handle init-latched controls.
Because they ARE special. They all need to be sent before the voice is
activated.
BTW, it might be a good idea to always provide NOTE
output from
senders, even though continous velocity and similar synths won't care
about it. Then again, continous velocity data doesn't work very well
as velocity data for note based synths, so it's probably not much
use...
We should - I agree. I just wrote that diatribe without reading ahead :)
Yes. So every voice creation involves a VOICE_ALLOC and a VOICE_ON. Once
VOICE_ON is received, the synth may make sound for the voice. It may be
silent, also, but the voice IS active.
Yes. "VOICE_ALLOC" doesn't trigger a
MIDIism allergy reaction for me
at least, but it's still a bit confusing...
Well, names are meant to be changed. Once we agree on WHAT it is, we can
name it properly.
For something
that has no per-voice controls (e.g. a
white-noise machine) you still need to send some event.
Fiddle with the NOTE control, maybe? (Which would default to "off",
of course.) Now, how do we express release velocity with that
scheme? Negative
Still broken, though: Release velocity doesn's fit
in... :-/
Use a third control for that!? Actually, that makes
quite some sense,
since many real instruments use totally different mechanisms for
starting and stopping notes. Pianos. Cymbals...
VELOCITY vs DAMPING, or something. (Makes sense for continous
velocity instruments as well!)
I'll think about this scheme. As a simple alternative - mirror the
VOICE_ON? VOICE_RELEASE, CONTROL SET, VOICE_OFF.
It actually is starting to taste more like VOICE_PAUSE, now. Tell the synth
not to react to changes until unpause. I don't like that. Perhaps release
velocity is a different control. But let's not make velocity special again.
If VELOCITY means something special to the end of a note, maybe there are
others.
Still needs thought.
Well, yes. And you'll also have to send a third
event (corresponding
to VOICE_OFF) to stop it, since just "letting go" of a VVID doesn't
affect anything. (It's a NOP, as far as the API and synths are
concerned.)
Yes, I've always assumed that, and it makes perfect sense to me and doesn't
offend me at all :)
struct voice
*v = myvoices[(*(host->vvid_table))[vvid]];
Why double indirection? I think it's enough to say that you must
never store the pointer across process() calls. Note that senders
11:46 a.m.
On Thursday 09 January 2003 10.17, Tim Hockin wrote:
I personally find this notion bizarre and counter-intuitive. The
idea that the note is turned on by some random control is just
awkward. I'm willing to concede it, but I just want to be on the
record that I find it bizarre.
Well, maybe it's just that continous control synths are bizarre by
definition? They just work this way, and there's nothing an API can
do about it.
The way I see it, this "random control" that triggers a note is
equivalent to MIDI NoteOn. It can even be a standardized NOTE control
that all synths must respond to, one way or another.
The event that binds a voice to a VVID however, doesn't really have a
counterpart in MIDI, and I belive that's where the confusion is.
Initializing a VVID is actually rather similar to picking a MIDI
channel for future notes, in that it doesn't trigger a real action in
the synth.
Well, MIDI *does* actually have virtual voice allocation. It's
implicit: voice ID == MIDI pitch. The only difference with our VVIDs
is that they have no fixed relation to note pitch, so you have to
allocate them in some other way. (Unless you just simulate the MIDI
approach, that is.)
No, the real reason is that having synths allocate the entries would
force senders to indirectly communicate with synths when making
connections. And it move the anagement work from the host into
plugins, obviously.
I just don't see a good reason not to have the host do it if it can.
* Less code in plugins.
* Less risk of plugins leaking memory.
* Hosts don't have to ask synths for extra VVIDs
when making connections.
* VVID entry allocation can be made RT safe by the host,
instead of requiring fully RT safe generic memory
management for RT safe connections.
Right - this is the bit I find insane. From the user perspective:
I want to start a note. Not whenever you feel like it. Now. Here
are the non-default control values for this voice. Anything I did
not send you, assume the default. Go.
So, bowed string instruments, wind instruments and the like are
insane designs? :-)
What you describe only applies to certain instruments, such as
keyboard instruments and to some extent, percussion.
A bowed string instrument is "triggered" by the bow pressure and
speed exceeding certain levels; not directly by the player thinking
"note!". Why would the instrument care what the player is *thinking*
while playing? I don't see the logic in forcing that into the API.
Why? What does "end a voice" actually mean?
Fine, I have no problems with that. I just don't see why it should be
assumed to be more special than it really is. NOTE/VOICE_ON/VOICE_OFF
is a gate control. What more do you need to say about it?
Yes. (If there's no "active" voice of some sort, there's nothing to
track the control changes.)
[...]
Well, then we can probably conclude that most of this is a matter of
terminology confusion. :-)
[...]
Well, the VOICE_RELEASE would be implicit and *after* the VOICE_OFF,
I think.
Either way, what I'm trying to figure out is a way to have both
note-on latched and continous control synths do sensible things even
if the sender doesn't know which type it's dealing with.
If this can't be done, we have *serious* trouble; the whole idea of
playing back sequenced data goes down the drain, basically.
that it has N voices on at all times. Hmm. Still,
VOICE_ALLOC
is akin to note_on.
Well, if a voice can be "started" and still actually both silent
and physically deactivated (that is, acting as or being a dump
control tracker) - then yes. I still believe that the VOICE_ON approach is simpler
to
comprehend, and more consistent. I want to toss MIDI, but not
where the convention makes things easy to understand. I think that
explaining the idea that a voice is created but not 'on' until the
instrument decides is going to confuse people. Over engineered.
I think the alternative would render continous control synths even
more confusing. "Why do I have to send a VOICE_ON to make the synth
work at all?"
I think VOICE_ON is like telling people that sequencers know better
than synths when to start and stop physical voices, and that's very
far from the truth, especially with continous control synths.
Anyway, it's really an implementation issue. Just don't mention it in
the API docs. Just say that the NOTE control corresponds to MIDI
NoteOn/Off. Problem solved!
[...]
having hosts
provide VVID entries (which they never access) is
stretching it, but it's the cleanest way of avoiding "voice
searching" proposed so far, and it's a synth<->local host thing
only.
If the host never accesses the VVID table, why is it in the host
domain and not the plugins? Simpler linearity? I don't buy that. The plugin CAN use the VVID table to store flags about
the voice,
as you suggested. I just want to point out that this is
essentially the same as the plugin communicating to the host about
voices, just more passively.
Only the host can't really make any sense of the data.
It seems useful.
Not really, because of the latency, the polling requirement and the
coarse timing.
If the plugin can flag VVID table entries as released,
the host can
have a better idea of which VVIDs it can reuse.
Why would this matter? Again, the host does *not* do physical voice
management.
You can reuse a VVID at any time, because *you* know whether or not
you'll need it again. The synth just doesn't care, as all it will
ever notice is that you stopped talking about whatever voice was
previously attached to that VVID.
[...]
Am I losing my mind or are we back at a prior
scenario?
Init controls:
time X: ALLOC_VOICE
time X: CONTROL A SET
time X: CONTROL B SET
This tastes just like VOICE_ON, SET, SET.
Except that
1) VOICE_ON implies that something is actually "started"
instantly, whereas ALLOC_VOICE just says "I'm going to
talk about a new voice, referring to it using this VVID."
2) There is no requirement that the controls are set at
time X.
If controls A and B are
both required to start a voice, the synth has to expect both.
Actually, *values* would trigger the synth; not the events
themselves. (The difference is important when dealing with ramp
events!)
The synth may not bother to start playing until A > 0.5 and B > 0,
for example. If B is > 0 by default, you only need to fiddle with A
to get the synth to play.
Agreed - they are semantically the same. The question
is
whether or not it has a counterpart to say that init-time
controls are done.
This is where the confusion/disagreement is, I think: I don't
think of this event as "INIT_START", but rather as
"CONTEXT_START". I don't see the need for a specific "init" part
of the lifetime of a context. Initialization ends whenever the
synth decides to start playing instead of just tracking controls. I can map this onto your same behavior, but I
don't like the way
you characterize it. The init period is instantaneous. If I did
not provide enough information (e.g.: no velocity, and default is
0.0) then the voice is silent. Same behavior different
characterization.
The difference comes when the host sends the 'magic' start-voice
control too soon.
Assume a synth with a bunch of init-latched controls.
Assume velocity is the 'magic trigger'.
time0: Host sends VOICE_START/ALLOC/whatever
time0: Host sends controls A, B, C (latched, but no effect from
the synth) time0: Host sends control VELOCITY (host activates
voice)
time0: Host sends controls D, E, F (ignored - they are
init-latched, and init is over!)
Do you see the problem?
No, I see a host sending continous control data to an init-latched
synth. This is nothing that an API can fix automatically.
It is easily solved by declaring a
context, then setting init controls, then activating the voice.
Yes, but that's a matter of sequencing; not API design.
But the activation of the voice has to be consistent
for all
Instruments, or the host can't get it right.
Yes, it has to be triggered by a standardized control, so hosts
and/or users will know how to hook synths up with sequencers,
controllers and other senders.
If that means that the whitenoise generator with no
per-voice
controls has to receive VOICE_ALLOC(vvid) and VOICE_ON(vvid), then
that is OK.
If it has no voice controls, there will be no VVIDs. You can still
allocate and use one if you don't want to special case this, though.
Sending voice control events to channel control inputs is safe, since
the receiver will just ignore the 'vvid' field of events.
Anyway, assuming this plugin has a gate control, that could be
implemented as a NOTE control. That would make it more obvious how to
make a sequencer gate the plugin using "note data". If you just
insert a "cable" between the sender and the plugin, you'd get this
setup automatically, since the host sees NOTE on both ends, and
connects them.
physically
when the sender has reassigned the VVID and the synth
has killed the voice. Thus, no need for a "VOICE_END" or similar
event either.
The host still has to be able to end a voice, without starting a
new one. From the sender POV:
I'm done with this
context, and won't send any more events
referring to it's VVID.
From the synth POV:
The voice assigned to this
VVID is now silent and passive,
just waiting for further instructions. If no events arrive,
nothing will happen. If the voice is stolen, the VVID is
detached, and voice allocation will be reevaluated, should
any further events for this VVID arrive.
Maybe it would be "interesting" for synths to find out when a sender
really intends never to use a context again, but I don't see why.
It's like telling a MIDI synth that you've stopped using a certain
MIDI pitch for now. Who cares? You can just conclude that nothing is
playing on that pitch at the moment, and think no further.
For a
continous velocity instrument, this is obvious; default
velocity has to be 0, or you'll have a "random" note started soon
as a voice is allocated. Thus you *have* to change the velocity
control to start a note.
For a "latched velocity" instrument (MIDI style), it's exactly
the same thing. There will be a NOTE control, and it has to be
"off" by default. Just set it to "on" to start a note with
default velocity.
That's fine, but can't it be consistent? The continuous velocity
instrument does not suffer because it has to accept a VOICE_ON
(what you called NOTE here). Does it map perfectly, no. Does it
map well enough, yes - and it has the benefit of being consistent,
and easy to explain. Realistically MOST synths will have at least one
init-time control
(velocity). As we evolve, this can go away and just be a normal
control. But until then we need a consistent way to handle
init-latched controls. Because they ARE special. They all need to
be sent before the voice is activated.
Yes - just like you have to send MIDI Program Change *before* playing
notes. It's not really a continous control, but MIDI sequencers don't
special case it, since it's obvious enough that the user should say
what sound he/she wants *before* starting to play.
BTW, it might
be a good idea to always provide NOTE output from
senders, even though continous velocity and similar synths won't
care about it. Then again, continous velocity data doesn't work
very well as velocity data for note based synths, so it's
probably not much use...
We should - I agree. I just wrote that diatribe without reading
ahead :) Yes. So every voice creation involves a VOICE_ALLOC and a
VOICE_ON. Once VOICE_ON is received, the synth may make sound for
the voice. It may be silent, also, but the voice IS active. Fiddle with
the NOTE control, maybe? (Which would default to
"off", of course.)
YES! The same as a VOICE_ON. or send a 1 to the VOICE control.
Describe it how you will, it tastes like VOICE_ON. Remember before
when I said I would concede this point? I lied! I might concede
VVIDs and give up on plugin-allocated VIDs, but this seems more and
more right, and you yourself talked me back into it. VELOCITY vs
DAMPING, or something. (Makes sense for continous
velocity instruments as well!)
I'll think about this scheme. As a simple alternative - mirror the
VOICE_ON? VOICE_RELEASE, CONTROL SET, VOICE_OFF. It actually is starting to taste more like
VOICE_PAUSE, now. Tell
the synth not to react to changes until unpause.
Only the synth actually *does* react - it tracks the control changes.
(Or it would have no values to latch when a note is to start.)
I don't like
that. Perhaps release velocity is a different control.
Yes, I think so.
But let's
not make velocity special again. If VELOCITY means something
special to the end of a note, maybe there are others.
Sure. (There are many ways to stop a cymbal...)
The only control that has to be special is NOTE/GATE/whatever (I kind
of like GATE, BTW) - and I'm not even sure it's all that special.
It's not equivalent to VELOCITY, but "abusing" it as that for
continous velocity synths make them playable with data recorded for
note-on latched synths. Not very nice, though, and I'm thinking it
might be better to solve this with hints. (GATE can still be a
continous control, of course, but that's not the same thing as
"equivalent to VELOCITY".)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
6:55 p.m.
> I personally find this notion bizarre and
counter-intuitive. The
> idea that the note is turned on by some random control is just
> awkward. I'm willing to concede it, but I just want to be on the
> record that I find it bizarre.
The way I see it, this "random control" that
triggers a note is
equivalent to MIDI NoteOn. It can even be a standardized NOTE control
that all synths must respond to, one way or another.
OK - in my own notes I had been referring to it as the VOICE control. You
send the VOICE control a VOICE_ON message and a VOICE_OFF message, or
simpler send 0 and 1.
comprehend,
and more consistent. I want to toss MIDI, but not
where the convention makes things easy to understand. I think that
explaining the idea that a voice is created but not 'on' until the
instrument decides is going to confuse people. Over engineered.
I think the alternative would render continous control synths even
more confusing. "Why do I have to send a VOICE_ON to make the synth
work at all?" Anyway, it's really an implementation issue. Just
don't mention it in
the API docs. Just say that the NOTE control corresponds to MIDI
NoteOn/Off. Problem solved!
So stroking the NOTE control in your mind is *identical* to sending a 1 to
the VOICE control in my mind.
The plugin CAN
use the VVID table to store flags about the voice,
as you suggested. I just want to point out that this is
essentially the same as the plugin communicating to the host about
voices, just more passively.
Only the host can't really make any sense of the data. It seems
useful.
Not really, because of the latency, the polling requirement and the
coarse timing. If the plugin
can flag VVID table entries as released, the host can
have a better idea of which VVIDs it can reuse.
Why would this matter? Again, the host does *not* do physical voice
management.
You can reuse a VVID at any time, because *you* know whether or not
you'll need it again. The synth just doesn't care, as all it will This is where the confusion/disagreement is, I think:
I don't
think of this event as "INIT_START", but rather as
"CONTEXT_START". I don't see the need for a specific "init" part
of the lifetime of a context. Initialization ends whenever the
synth decides to start playing instead of just tracking controls.
Right - this is the bit I find insane. From the user perspective:
I want to start a note. Not whenever you feel like it. Now. Here
are the non-default control values for this voice. Anything I did
not send you, assume the default. Go. A bowed string instrument is "triggered" by
the bow pressure and
speed exceeding certain levels; not directly by the player thinking
Disagree. SOUND is triggered by pressure/velocity. The instrument is ready
as soon as bow contacts the string.
The difference
comes when the host sends the 'magic' start-voice
control too soon.
Assume a synth with a bunch of init-latched controls.
Assume velocity is the 'magic trigger'.
time0: Host sends VOICE_START/ALLOC/whatever
time0: Host sends controls A, B, C (latched, but no effect from
the synth) time0: Host sends control VELOCITY (host activates
voice)
time0: Host sends controls D, E, F (ignored - they are
init-latched, and init is over!)
Do you see the problem?
No, I see a host sending continous control data to an init-latched
synth. This is nothing that an API can fix automatically. Yes, it has to be triggered by a standardized control,
so hosts
and/or users will know how to hook synths up with sequencers,
controllers and other senders.
Precisely.
If it has no voice controls, there will be no VVIDs.
You can still
allocate and use one if you don't want to special case this, though.
Sending voice control events to channel control inputs is safe, since
the receiver will just ignore the 'vvid' field of events.
I think that if it wants to be a synth, it understands VVIDS. It doesn't
have to DO anything with them, but it needs to be aware. And the NOTE/VOICE
starter is a voice-control, so any Instrument MUST have that.
has killed the voice. Thus, no need for a
"VOICE_END" or similar
event either.
The host still has to be able to end a voice, without starting a
new one. From the sender
POV:
I'm done with this context, and won't send any more events
referring to it's VVID. From the synth
POV:
The voice assigned to this VVID is now silent and passive, assumed to be more special than it really is.
NOTE/VOICE_ON/VOICE_OFF
is a gate control. What more do you need to say about it?
Only if you assume a voice lives forever, which is wasteful. Besides that,
a gate that gets turned off and on and off and on does not restart a voice,
just mutes it temporarily. Not pause, not restart - mute.
control. But
until then we need a consistent way to handle
init-latched controls. Because they ARE special. They all need to
be sent before the voice is activated.
Yes - just like you have to send MIDI Program Change *before* playing
notes. It's not really a continous control, but MIDI sequencers don't
special case it, since it's obvious enough that the user should say
what sound he/she wants *before* starting to play. YES! The same
as a VOICE_ON. or send a 1 to the VOICE control.
Describe it how you will, it tastes like VOICE_ON. Remember before
when I said I would concede this point? I lied! I might concede
VVIDs and give up on plugin-allocated VIDs, but this seems more and
more right, and you yourself talked me back into it.
Well, then we can probably conclude that most of this is a matter of
terminology confusion. :-) Either way, what I'm trying to figure out is a way
to have both
note-on latched and continous control synths do sensible things even
if the sender doesn't know which type it's dealing with.
Of course. See below again :)
I don't
like
that. Perhaps release velocity is a different control.
Yes, I think so.
12 Jan
12 Jan
5:31 p.m.
Paging David, David are you there? I'm bored - send me more arguments!!
If flags are standardized, it can. Int32: 0 = unused, +ve = plugin owned,
-ve = special meaning.
When does the host allocate from the VVID list? Between blocks. As long as
a synth flags or releases a VVID during it's block, the host benefits from
it. The host has to keep a list of which VVIDs it still is working with,
right?
right, but if you hit the ned of the list and loop back to the start, you
need to find the next VVID that is not in use by the HOST. That can include
VVIDs that have ended spontaneously (again, hihat sample or whatever). The
host just needs to discard any currently queued events for that (expired)
VVID. The plugin is already ignoreing them.
So, bowed string instruments, wind instruments and the like are
insane designs? :-)
No, they just might not have init params. The voice is started when the bow
contacts the string.
Ok, let me make it more clear. Again, same example. The host wants to send
7 parameters to the Note-on. It sends 3 then VELOCITY. But as soon as
VELOCITY is received 'init-time' is over. This is bad. The host has to
know which control ends init time. Thus the NOTE/VOICE control we seem to
be agreeing on.
Why? What does "end a voice" actually mean?
It means that the host wants this voice to stop. If there is a release
phase, go to it. If not, end this voice (in a plugin-dpecific way).
Without it, how do you enter the release phase?
No. It means I want the sound on this voice to stop. It implies the above,
too. After a VOICE_OFF, no more events will be sent for this VVID.
More, the VVID is done. No more events for this VVID. The reason that
VVID_ALLOC is needed at voice_start is because the host might never have
sent a VOICE_OFF. Or maybe we can make it simpler:
Host turns the NOTE/VOICE on.
It can either turn the NOTE/VOICE off or DETACH it. Here your detach name
makes more sense. A step sequencer would turn a note on, then immediately
detach.
Well, you CAN change Program any time you like - it is not a per-voice
control.
MOSTLY. We still have agree on the problem of init- and release-latched
controls. See below.
Release velocity is a release-latched control.
Control set events can have three forms (a control can handle any
combination of them by flags or something):
1) events that apply to the starting of the voice
2) events that apply to an active voice
3) events that apply to the ending of an event
Controls which are init-latched ONLY (e.g. velocity for a velo map) need to be
grouped together before the voice is started.
Controls which are release-latched ONLY (e.g. release velocity) need to be
grouped together before the voice is ended.
We need to standardize the way of sending these.
Idea 1: as we've been discussing, have some window during which events are
KNOWN to be init (or release).
-- INIT:
send VOICE_INIT(new_vvid) /* declare a vvid */
send SET(new_vvid, ctrl) /* set controls for init */
send VOICE_ON(new_vvid) /* start the vvid */
-- RELEASE:
send VOICE_DEINIT(vvid) /* going into release */
send SET(vvid, ctrl) /* set controls for release */
send VOICE_OFF(vvid) /* do release */
Idea 2: similar to idea 1, but less explicit.
-- INIT:
send SET(new_vvid, ctrl) /* implicitly creates a voice */
send VOICE_ON(new_vvid) /* start the vvid */
-- RELEASE:
send SET(new_vvid, ctrl) /* send with time X */
send VOICE_OFF(vvid) /* also time X - plug 'knows' it was for release */
Idea 3: different events for init/release/active sets.
Of those, I like #1. It feels familiar. You declare a variable before you
use it, and you unlink something before you kill it.
#2 init is ok. I don't like the release. #3 is not pretty.
we're gettig there...
Tim
> I personally find this notion bizarre and
counter-intuitive. The
> idea that the note is turned on by some random control is just
> awkward. I'm willing to concede it, but I just want to be on the
> record that I find it bizarre.
The way I see it, this "random control"
that triggers a note is
equivalent to MIDI NoteOn. It can even be a standardized NOTE control
that all synths must respond to, one way or another.
OK - in my own notes I had been referring to it as the VOICE control. You
send the VOICE control a VOICE_ON message and a VOICE_OFF message, or
simpler send 0 and 1.
comprehend, and more consistent. I want to toss MIDI, but not
where the convention makes things easy to understand. I think that
explaining the idea that a voice is created but not 'on' until the
instrument decides is going to confuse people. Over engineered.
I think the alternative would render continous control synths even
more confusing. "Why do I have to send a VOICE_ON to make the synth
work at all?" Anyway, it's really an implementation issue.
Just don't mention it in
the API docs. Just say that the NOTE control corresponds to MIDI
NoteOn/Off. Problem solved!
So stroking the NOTE control in your mind is *identical* to sending a 1 to
the VOICE control in my mind.
The
plugin CAN use the VVID table to store flags about the voice,
as you suggested. I just want to point out that this is
essentially the same as the plugin communicating to the host about
voices, just more passively.
Only the host can't really make any sense of the data. It seems
useful.
Not really, because of the latency, the polling requirement and the
coarse timing. If the
plugin can flag VVID table entries as released, the host can
have a better idea of which VVIDs it can reuse.
Why would this matter? Again, the host does *not* do physical voice
management.
You can reuse a VVID at any time, because *you* know whether or not
you'll need it again. The synth just doesn't care, as all it will This is where the confusion/disagreement is, I think:
I don't
think of this event as "INIT_START", but rather as
"CONTEXT_START". I don't see the need for a specific "init" part
of the lifetime of a context. Initialization ends whenever the
synth decides to start playing instead of just tracking controls.
Right - this is the bit I find insane. From the user perspective:
I want to start a note. Not whenever you feel like it. Now. Here
are the non-default control values for this voice. Anything I did
not send you, assume the default. Go. A bowed string instrument is
"triggered" by the bow pressure and
speed exceeding certain levels; not directly by the player thinking
Disagree. SOUND is triggered by pressure/velocity. The instrument is ready
as soon as bow contacts the string.
The
difference comes when the host sends the 'magic' start-voice
control too soon.
Assume a synth with a bunch of init-latched controls.
Assume velocity is the 'magic trigger'.
time0: Host sends VOICE_START/ALLOC/whatever
time0: Host sends controls A, B, C (latched, but no effect from
the synth) time0: Host sends control VELOCITY (host activates
voice)
time0: Host sends controls D, E, F (ignored - they are
init-latched, and init is over!)
Do you see the problem?
No, I see a host sending continous control data to an init-latched
synth. This is nothing that an API can fix automatically. Yes, it has to be triggered by a standardized
control, so hosts
and/or users will know how to hook synths up with sequencers,
controllers and other senders.
Precisely.
If it has no voice controls, there will be no
VVIDs. You can still
allocate and use one if you don't want to special case this, though.
Sending voice control events to channel control inputs is safe, since
the receiver will just ignore the 'vvid' field of events.
I think that if it wants to be a synth, it understands VVIDS. It doesn't
have to DO anything with them, but it needs to be aware. And the NOTE/VOICE
starter is a voice-control, so any Instrument MUST have that.
has killed the voice. Thus, no need for a
"VOICE_END" or similar
event either.
The host still has to be able to end a voice, without starting a
new one. From the
sender POV:
I'm done with this context, and won't send any more events
referring to it's VVID. From the
synth POV:
The voice assigned to this VVID is now silent and passive, assumed to be more special than it really is.
NOTE/VOICE_ON/VOICE_OFF
is a gate control. What more do you need to say about it?
Only if you assume a voice lives forever, which is wasteful. Besides that,
a gate that gets turned off and on and off and on does not restart a voice,
just mutes it temporarily. Not pause, not restart - mute.
control.
But until then we need a consistent way to handle
init-latched controls. Because they ARE special. They all need to
be sent before the voice is activated.
Yes - just like you have to send MIDI Program Change *before* playing
notes. It's not really a continous control, but MIDI sequencers don't
special case it, since it's obvious enough that the user should say
what sound he/she wants *before* starting to play. YES! The
same as a VOICE_ON. or send a 1 to the VOICE control.
Describe it how you will, it tastes like VOICE_ON. Remember before
when I said I would concede this point? I lied! I might concede
VVIDs and give up on plugin-allocated VIDs, but this seems more and
more right, and you yourself talked me back into it.
Well, then we can probably conclude that most of this is a matter of
terminology confusion. :-) Either way, what I'm trying to figure out is
a way to have both
note-on latched and continous control synths do sensible things even
if the sender doesn't know which type it's dealing with.
Of course. See below again :)
I
don't like
that. Perhaps release velocity is a different control.
Yes, I think so.
7 Jan
7 Jan
5:25 a.m.
On Tue, Jan 07, 2003 at 03:21:22 +0100, David Olofson wrote:
I still dont think there special. Velicty maps only behave this way in
midi because you cant change velovity during the note in midi, you still
need to be able to call up the map instantly, so it doesn't matter if you
dont know the map at the point the note is 'created'.
Why? You can create it with the map for velocity=0.0 or whatever, and
change it if needed. This seems like it will lead to cleaner instrument
code.
- Steve
> > Problem is step 1. If the voice allocator
looks at velocity, it
> > won't work, since that information is not available when you do
> > the allocation. Likewise for setting up waveforms with velocity
> > maps and the like.
But in the general case this is just mapping to parameters, you have to be
able to handle parameter changes during the run of the instrument, so why
not at creation time too?
for samples
if (event)
if (event == new_voice)
voice = allocate_voice()
if (event == velocity)
voice.set_voice_map(event)
out = voice.run()
> > When are you supposed to do that sort of
stuff? VOICE_ON is what
> > triggers it in a normal synth, but with this scheme, you have to
> > wait for some vaguely defined "all parameters available" point.
>
> So maybe VOICE creation needs to be a three-step process.
> * Allocate voice
> * Set initial voice-controls
> * Voice on
I think this is harder to handle.
This is
essentially saying that initial parameters are
'special', and they are in many-ways (I'm sure velocity maps are
just one case).
Yes; there can be a whole lot of such parameters for percussion
instruments, for example. (Drums, cymbals, marimba etc...) Or we can make
the rule that you do not choose an entry in a
velocity map until you start PROCESSING a voice, not when you
create it. VOICE_ON is a placeholder. The plugin should see that
a voice is on that has no velocity-map entry and deal with it whn
processing starts. Maybe not.
No, I think that's just moving the problem deeper into synth
implementations.
8:47 a.m.
On Tuesday 07 January 2003 10.19, Steve Harris wrote:
Why?
I still dont think there special. Velicty maps only behave this way
in midi because you cant change velovity during the note in midi,
you still need to be able to call up the map instantly, so it
doesn't matter if you dont know the map at the point the note is
'created'.
It's just that there's a *big* difference between latching control
values when starting a note and being able to "morph" while the note
is played... I think it makes a lot of sense to allow synths to do it
either way.
Why? You can create it with the map for velocity=0.0 or whatever,
and change it if needed. This seems like it will lead to cleaner
instrument code.
Cleaner, maybe, but slower and more importantly, incorrect.
Bad Things(TM) will happen if you happen to play a "note-on latched
velocity" synth with data that was recorded from a continous velocity
controller, for example. What are you supposed to do with the
sequenced data (or real time input, for that matter!) to have correct
playback? I don't like the idea of having two different *types* of
controls (continous and "event latched") for everything, just to deal
with this.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
On Tue, Jan 07, 2003 at 03:21:22 +0100, David Olofson
wrote:
[...]
Yeah, byt you may not want control values to be latched except when a
note is actually triggered (be it explicitly, or as a result of a
contro change). Also, this voice.set_voice_map() may have significant
cost, and it seems like a bad idea to have the API practically
enforce that such things are done twice for every note.
> > Problem is step 1. If the voice
allocator looks at velocity,
> > it won't work, since that information is not available when
> > you do the allocation. Likewise for setting up waveforms with
> > velocity maps and the like.
But in the general case this is just mapping to parameters, you
have to be able to handle parameter changes during the run of the
instrument, so why not at creation time too? > > When
are you supposed to do that sort of stuff? VOICE_ON is
> > what triggers it in a normal synth, but with this scheme, you
> > have to wait for some vaguely defined "all parameters
> > available" point.
>
> So maybe VOICE creation needs to be a three-step process.
> * Allocate voice
> * Set initial voice-controls
> * Voice on
I think this is harder to handle. This is essentially saying that initial parameters
are
'special', and they are in many-ways (I'm sure velocity maps
are just one case).
Yes; there can be a whole lot of such parameters for percussion
instruments, for example. (Drums, cymbals, marimba etc...) Or we can make the rule that you do not choose an
entry in a
velocity map until you start PROCESSING a voice, not when you
create it. VOICE_ON is a placeholder. The plugin should see
that a voice is on that has no velocity-map entry and deal with
it whn processing starts. Maybe not.
No, I think that's just moving the problem deeper into synth
implementations.
10:09 a.m.
On Tue, Jan 07, 2003 at 01:41:43 +0100, David Olofson wrote:
Why?
More events. I guess its not impartant now I think about it.
Yeah, byt you may not want control values to be
latched except when a
note is actually triggered (be it explicitly, or as a result of a
contro change). Also, this voice.set_voice_map() may have significant
cost, and it seems like a bad idea to have the API practically
enforce that such things are done twice for every note.
Right, but the coust is not doubled.
> So maybe VOICE creation needs to be a three-step
process.
> * Allocate voice
> * Set initial voice-controls
> * Voice on
I think this is harder to handle. It's just that there's a *big* difference
between latching control
values when starting a note and being able to "morph" while the note
is played... I think it makes a lot of sense to allow synths to do it
either way.
I'm not convinced there are many things that should be latched. I guess if
you're trying to emulate MIDI hardware, but there you can just ignore
velocity that arrives after the voice on.
I guess I have no real probelm with two stage voice initialisation. It
certainly beets having two classes of event.
- Steve
10:44 a.m.
On Tuesday 07 January 2003 15.03, Steve Harris wrote:
[...]
I don't think velocity mapping qualifies as "emulating MIDI
hardware", though. Likewise with "impact position" for drums.
Selecting a waveform at voice on is very different from switching
between waveforms during playback in a useful way. Changing the
position dependent parameters for playing sounds just because "the
drummer moves his aim" is simply incorrect.
Either way, the problem with ignoring velocity after voice on is that
you have to consider event *timestamps* rather than event ordering.
This breaks the logic of timestamped event processing, IMHO.
It's just
that there's a *big* difference between latching
control values when starting a note and being able to "morph"
while the note is played... I think it makes a lot of sense to
allow synths to do it either way.
I'm not convinced there are many things that should be latched. I
guess if you're trying to emulate MIDI hardware, but there you can
just ignore velocity that arrives after the voice on. I guess I have no real probelm with two stage voice
initialisation.
It certainly beets having two classes of event.
Yes, and that's the more important side of this. Treating
"parameters" as different from controls has implications for both
hosts/senders and synths, whereas defining "voice on latched
controls" as a synth implementation thing has no implications for
hosts/senders.
It might seem handy to allow synths to explicitly say that some
controls *must* be rewritten at the instant of a VOICE_ON, but I
don't think it's useful (it's useless for continous velocity
instruments, at least) enough to motivate the cost.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
12:12 p.m.
On Tue, Jan 07, 2003 at 03:38:05 +0100, David Olofson wrote:
It might seem handy to allow synths to explicitly say
that some
controls *must* be rewritten at the instant of a VOICE_ON, but I
don't think it's useful (it's useless for continous velocity
instruments, at least) enough to motivate the cost.
Right, we are in agreement then :)
- Steve
8 Jan
8 Jan
4:21 a.m.
It's just that there's a *big* difference
between latching control
values when starting a note and being able to "morph" while the note
is played... I think it makes a lot of sense to allow synths to do it
either way.
Should controls have a flag that indicates whether they are continuous vs
note-on ? They can certainly be both or either one. It is a hint to allow
the host to send init-params at init time only (and a hint to the user).
Obviously the plugin has to ignore it no matter what.
4:52 p.m.
On Wednesday 08 January 2003 09.15, Tim Hockin wrote:
They would have to be different *types*, as the semantics are totally
different.
It's just
that there's a *big* difference between latching
control values when starting a note and being able to "morph"
while the note is played... I think it makes a lot of sense to
allow synths to do it either way.
Should controls have a flag that indicates whether they are
continuous vs note-on ? They can certainly be both or either one.
Yes, and that's my problem with it. Or rather; it's ok for synths to
be able to hint that they use controls this way, but designing the
voice addressing/allocation scheme around it has serious implications.
It is a hint to allow the host to send init-params at
init time
only (and a hint to the user). Obviously the plugin has to ignore
it no matter what.
Right, I think... As long as they're really just normal controls, and
work *exactly* like normal controls (apart from the way the synth
"samples" the values), this is fine.
Hosts may or may not care, though; if the user *really* wants to put
initializers some time before the actual start of notes, it's not
really a problem, although it may indeed cause some synths to waste
real voices on tracking voice controls. (That's why I suggested some
synths might want to use Virtual Voices until sound is to be
produced.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
7:12 p.m.
Yes, and that's my problem with it. Or rather;
it's ok for synths to
be able to hint that they use controls this way, but designing the
voice addressing/allocation scheme around it has serious implications.
Yes, definitely hint. Anal-retentive hosts will show it as an init-option
only if it is flagged as such. Synths still need to handle spurious and
incorrect events (fall through I'd guess), but it is a nice hint to the UI.
3:41 a.m.
> So maybe
VOICE creation needs to be a three-step process.
> * Allocate voice
> * Set initial voice-controls
> * Voice on
I think this is harder to handle.
7:11 a.m.
On Tue, Jan 07, 2003 at 11:35:20 -0800, Tim Hockin wrote:
All the further discussion leads me to understand we
like this? Eek. I
proposed it as a straw man.
So we send 1 VOICE_ALLOC, n control SETs, and 1 VOICE_ON event?
is that what we're converging on?
Yes, that now seems reasonable to me. My suspicion is that its not
neccesary, but I dont think it will hurt, and it makes MIDI->XAP
interfaces simple.
- Steve
7976
days inactive
7982
days old
linux-audio-dev@lists.linuxaudio.org
55 comments
4 participants
participants (4)
-
David Olofson -
robbins jacob -
Steve Harris -
Tim Hockin