7 Jan
2003
7 Jan
'03
3:49 p.m.
>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).
The initial mention of the VVID is the issue here; certain types of voice
events are assumed not to allocate a voice (parameter-set events). THis is
because there is no difference between a tweak on a VVID that has had its
voice stolen and a tweak intended to initialize a voice that arrives before
voice-on. We must conclude that the plugin will discard both of them. There
must be a signal to the plugin that a VVID is targeted for activation. we
have a few options:
---a voice-activation event is sent, then any initializing events, then a
voice-on event
---a voice-on event is sent, with any following events on the same timestamp
assumed to be initializers
---a voice-activation event is sent and there is no notion of voice-on, one
or more of the parameters must be changed to produce sound but it is a
mystery to the sequencer which those are. (I don't like this because it make
sequences not portable between different instruments)
---events sent to voiceless VVID's are attached to a temporary voice by the
plugin and which may later use that to initialize an actual voice. This
negates the assumption that voiceless VVID events are discarded.
#2 is just an abbreviated form of #1, as i argue below. (unless you allow
the activate-to-voice_on cycle to span multiple timestamps which seems
undesireable)
> > 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.
7 Jan
7 Jan
6:43 p.m.
New subject: [linux-audio-dev] more on XAP Virtual Voice ID system
On Tuesday 07 January 2003 20.42, robbins jacob wrote:
[...]
That should work, and allows normal Voice Controls to be used as
initializers.
Also note that nothing says that the synth must allocate a *physical*
voice for this; it could start with a non-playing virtual voice and
allocate a physical voice only when it decides to actually make some
noise. (Or decides to ditch the voice, based on the state of the
initializers when "voice on" is triggered.)
We can precisely define initialization parameters to be all the
events sharing the same VVID and timestamp as the VOICE_ON event.
Yes - but that's not compatible with standard Control sematics in any
way...
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).
The initial mention of the VVID is the issue here; certain types of
voice events are assumed not to allocate a voice (parameter-set
events). THis is because there is no difference between a tweak on
a VVID that has had its voice stolen and a tweak intended to
initialize a voice that arrives before voice-on. We must conclude
that the plugin will discard both of them. There must be a signal
to the plugin that a VVID is targeted for activation. we have a few
options:
---a voice-activation event is sent, then any initializing events,
then a voice-on event ---a voice-on event is sent, with any following events
on the same
timestamp assumed to be initializers
That breaks control/initializer compatibility totally. Initializers
cannot be Voice Controls if they're special-cased like this.
---a voice-activation event is sent and there is no
notion of
voice-on, one or more of the parameters must be changed to produce
sound but it is a mystery to the sequencer which those are. (I
don't like this because it make sequences not portable between
different instruments)
Sequences are still "portable" if controls are hinted in a sensible
way. Obviously, you can't make a "note on velocity" synth play
continous velocity sequences properly, but there isn't much that can
be done about that, really. The note on velocity data just isn't
there.
---events sent to voiceless VVID's are attached to
a temporary
voice by the plugin and which may later use that to initialize an
actual voice. This negates the assumption that voiceless VVID
events are discarded.
Sort of. It's hard to avoid this if initializers really are supposed
to have any similarities with controls, though.
Also, I don't think it's much of a problem. When you run out of
voices, you're basically abusing the synth, and problems are to be
expected. (Though, we obviously want to minimize the side effects.
Thus voice stealing - which still works with this scheme.)
#2 is just an abbreviated form of #1, as i argue
below. (unless
you allow the activate-to-voice_on cycle to span multiple
timestamps which seems undesireable)
Well, you can't really prevent it, if initializers are supposed to be
control values, can you?
> > 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 means that the "all parameters
available" point is at the same
timestamp as the VOICE_ON event, but after the last event with that
timestamp.
And that point is a bit harder for synths to keep track of than
"whenever voice on occurs." This is more like script parsing than
event decoding.
No major issue, but the special casing of initializers is, IMO.
If we want to include a VOICE_ALLOCATE event then the
sequence
goes: timestamp-X:voice-allocate,
timestamp-X:voice-parameter-set(considered an initializer if
appropriate), timestamp-X:voice-on, timestamp-X+1:more
voice-parameter-sets (same as any other parameter-set)
But this sequence can be shortened by assuming that the voice-on
event at the last position for timestamp-X is implicit:
timestamp-X:voice-on(signifying the same thing as voice-allocate
above) timestamp-X:voice-parameter-set(considered an initializer if
appropriate), (synth actually activates voice here),
timestamp-X+1:other-events
The latter isn't very different from assuming that the first control
event that references a VVID results in a (virtual or physical) voice
being allocated. In fact, the synth will have to do *something* to
keep track of controls as soon as you start talking to a voice, and,
when appropriate, play some sound. Whether or not the synth allocates
a *physical* voice right away is really an implementation issue.
VOICE_ALLOCATE is really just a way of saying "I want this VVID
hooked up to a new voice - forget about whatever it was connected
to." You don't *have* to send one for every note, although you'll
probably want to, most of the time. It's a separate feature, and
doesn't imply anything about voice allocation; that's what I'm
actually trying to say.
So... Maybe we should actually just go back to the original idea of
"DETACH_VVID", but instead use it right before we want a VVID to be
attached to a new voice? (The original idea was to send a DETACH_VVID
"some time" after you're done with a voice.)
That way, the first Voice Control Change for a VVID implicitly and
"indirectly" causes voice allocation, as a result of no voice (or
some sort of marked fake voice - synth implementation dependent)
being attached to the VVID.
Obviously, this eliminates the need for senders/hosts to clear any
VVID entries and that kind of mess. (And thus, the requirement that a
cleared/unassigned VVID entry is 0 or NULL.) Just make sure to send a
DETACH_VVID before you use any VVID the first time.
//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
5:07 a.m.
New subject: [linux-audio-dev] more on XAP Virtual Voice ID system
VOICE_ALLOCATE is really just a way of saying "I
want this VVID
hooked up to a new voice - forget about whatever it was connected
to." You don't *have* to send one for every note, although you'll
probably want to, most of the time. It's a separate feature, and
doesn't imply anything about voice allocation; that's what I'm
actually trying to say.
So... Maybe we should actually just go back to the original idea of
"DETACH_VVID", but instead use it right before we want a VVID to be
attached to a new voice? (The original idea was to send a DETACH_VVID
"some time" after you're done with a voice.)
That way, the first Voice Control Change for a VVID implicitly and
"indirectly" causes voice allocation, as a result of no voice (or
some sort of marked fake voice - synth implementation dependent)
being attached to the VVID.
All this is ok in concept. I still think it is too implicit and it feels
'sneaky'. I'd MUCH rather see a rigid, well-defined protocol that forces the
few bizarre instruments to do a bit more work (really, just a BIT) than a
loose, implicit one that is going to be easy to screw up.
VOICE_ALLOCATE: declare a VID as in-use
VOICE_CONTROL_SET: set values for a per-voice control for a VID
VOICE_ON: declare that a VID is ready for play
Any VOICE_CONTROL_SET for a VID that does not exist is discarded.
I don't think there is any instrument for which this can't work. It may not
be a perfect fit for some, but I think they are the vast minority.
This model fits and doesn't taste too bad.
5:43 p.m.
New subject: [linux-audio-dev] more on XAP Virtual Voice ID system
On Wednesday 08 January 2003 10.01, Tim Hockin wrote:
[...]
All this is ok in concept. I still think it is too
implicit and it
feels 'sneaky'. I'd MUCH rather see a rigid, well-defined protocol
that forces the few bizarre instruments to do a bit more work
(really, just a BIT) than a loose, implicit one that is going to be
easy to screw up.
What's implicit about it, and how can you screw it up?
If a MIDI synth gets Poly Pressur or NoteOn/Off events, it has to
handle them properly. The MIDI pitch is the "VVID".
This is exactly the same thing, only a VVID does not imply a note
pitch value.
As to VVID management, that's a separate issue, and I'm just looking
for the cleanest and simplest approach. I still think VVIDs with a
host global table of VVID entries is the simplest way that can
actually work, but there are other ways - maybe even simler ways.
VOICE_ALLOCATE: declare a VID as in-use
Ok, this eliminates the need for ever checking VVID entries in a
synth. Good.
(Although the name is probably not right. You don't really care
whether you get a physical voice or not, and it doesn't matter to the
sender. It can confuse things, though - see below.)
VOICE_CONTROL_SET: set values for a per-voice control
for a VID
Yes - and this is where your average synth will have to allocate a
voice (or a fake "control tracer" voice) - unless it's done in
VOICE_ALLOCATE.
Anyway, it's optional for synths. My only argument against
VOICE_ALLOCATE is that it is redundant. Sending any other event to a
Voice could have the same effect, and would also bring more
information. (The only information VOICE_ALLOCATE brings is "the
sender is about to use this voice ID at some point".)
VOICE_ON: declare that a VID is ready for play
I still don't really see the point with this one. Synths will have to
allocate a voice as soon as the first voice control event arrives
anyway, so all this says is "start a note!" - and that doesn't even
apply to continous velocity instruments.
Sure, I can see where VOICE_ON can be a handy feature (the gong, for
example), but it's not strictly related to voice allocation or
anything like that; it's just a form of control data. I don't see
what justifies making this more special than a "standardized" NOTE
control.
Any VOICE_CONTROL_SET for a VID that does not exist is
discarded.
Or just never talk about VVIDs you haven't "initialized". Seems dead
simple to me, since all you have to do is VOICE_ALLOCATE(vvid) at
least once before you start using 'vvid'.
(This is where I find "VOICE_ALLOCATE" confusing. To the synth, is an
"allocated VVID" one that currently has a physical voice, or does any
initialized VVID count? I can see sequencer and synth coders using
the same term for two rather different things, if the term "ALLOCATE"
is used for this.)
I don't think there is any instrument for which
this can't work.
Right - it's just slightly too much redundancy for my taste. ;-)
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.
It may not be a perfect fit for some, but I think they
are the vast
minority.
This model fits and doesn't taste too bad.
Well, some synths may ignore VOICE_ON entirely, so I don't see why it
deserves to be special, but that's my only real problem with this.
Can't see a technical problem with VOICE_ON, 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 ---
7:55 p.m.
New subject: [linux-audio-dev] more on XAP Virtual Voice ID system
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). I
need to send SOMETHING to say "connect this VVID to a voice". The minimum
required is a VOICE_ON or similar. For something that has no per-voice
controls (e.g. a white-noise machine) you still need to send some event.
And I'd rather see the voice-on protocol be consistent for all instruments.
If that means you have to send two events (VOICE_ALLOC, VOICE_ON) for the
white-noise maker, then I can live with that.
Tim
7926
days inactive
7927
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
David Olofson -
robbins jacob -
Tim Hockin