Paging David, David are you there? I'm bored - send me more arguments!!
>
> > > 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
> > > rec
> > 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
On Thursday 09 January 2003 10.17, Tim Hockin wrote:
> > > 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
> > contro
> > 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 personally find this notion bizarre
[Replying to some posts by Tim Hockin.]
On Wednesday 08 January 2003 23.55, Tim Hockin wrote:
[...]
> 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 st
> 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 implement
> 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
> 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 obvious
> 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 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_
On Wednesday 08 January 2003 23.28, Steve Harris wrote:
> On Wed, Jan 08, 2003 at 10:38:44 +0100, David Olofson 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..
On Wednesday 08 January 2003 22.50, Tim Hockin wrote:
> > > Here are the ones we all agree on:
> >
> > [...]
> >
> > Can I grab that for the site?
>
> That's why I posted it :)
(Well, I kind of suspected that. ;-)
Thanks! Will get to it as soon as I've caught up with the mail...
//David Olofson
On Wednesday 08 January 2003 22.25, Steve Harris wrote:
> 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 h
On Wed, Jan 08, 2003 at 10:38:44 +0100, David Olofson 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.
Well there would be some other c
On Wednesday 08 January 2003 20.09, Tim Hockin wrote:
> > > 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.
>
> As a host author, I like that I can acco
On Wednesday 08 January 2003 19.56, Steve Harris wrote:
> On Wed, Jan 08, 2003 at 10:32:20AM -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.
> >
> > Hr
On Wednesday 08 January 2003 19.32, 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.
>
> Hrrm, I can't argue that a temp ID is pretty, but I _like_ that the
> plugin
On Wednesday 08 January 2003 19.23, Steve Harris wrote:
> On Wed, Jan 08, 2003 at 09:18:38AM -0800, Tim Hockin wrote:
> > > On Wed, Jan 08, 2003 at 12:09:56 -0800, Tim Hockin wrote:
> > > > What is LUT? What is voice-marking? The negative VVIDs are
> > > > valid for the duration of the block, aft
> > Here are the ones we all agree on:
> [...]
>
> Can I grab that for the site?
That's why I posted it :)
On Wednesday 08 January 2003 14.27, Kjetil S. Matheussen wrote:
[...]
> > Ny if you map CC1 (say) to a map then changing that will change
> > the sample, its just that, in MIDI, velocity cant change after
> > the voice has started.
>
> Not quite right, _I guess_ that in some synths you can change
>
On Wednesday 08 January 2003 11.50, Steve Harris wrote:
> On Tue, Jan 07, 2003 at 10:40:15 -0800, Tim Hockin wrote:
> > > ONe great thing about this scheme is that it encourages people
> > > not to think of certain, arbitary parameters as instantiation
> > > parameters, withc are special in some wa
On Wednesday 08 January 2003 11.49, Steve Harris wrote:
> On Wed, Jan 08, 2003 at 12:23:23 -0800, Tim Hockin 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
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,
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 voi
On Wednesday 08 January 2003 09.48, Tim Hockin wrote:
> > > I agree entirely. If each VVID=a voice then we should just call
> > > them Voice ID's, and let the event-sender make decisions about
> > > voice reappropriation.
> >
> > Actually, they're still virtual, unless we have zero latency
> > feed
On Wednesday 08 January 2003 09.42, Tim Hockin wrote:
> > >I made a post a while back defining all the XAP terminology to
[...]
> Here are the ones we all agree on:
[...]
Can I grab that for the site?
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! -
On Wednesday 08 January 2003 09.15, Tim Hockin wrote:
> > 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
On Wednesday 08 January 2003 09.09, Tim Hockin wrote:
[...]
> > 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?
You get a 32 bit integer valu
On Wednesday 08 January 2003 08.37, Tim Hockin wrote:
> > > Either you need to NEVER re-use a VVID, or you need to tell the
> > > host when an ended VVID is actually re-usable. Or you need to
> > > have voice-ids allocated by the plugin, and NOT the host, which
> > > I like more.
> >
> > Having th
> 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
>
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
> sequenti
> > 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.
As a host author, I like that I can account for your voices by REAL voice
IDs. :) Besides that, don't you
On Wed, Jan 08, 2003 at 10:32:20AM -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.
>
> Hrrm, I can't argue that a temp ID is pretty, but I _like_ that the p
> 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.
On Wed, Jan 08, 2003 at 09:18:38AM -0800, Tim Hockin wrote:
> > On Wed, Jan 08, 2003 at 12:09:56 -0800, Tim Hockin wrote:
> > > 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.
> On Wed, Jan 08, 2003 at 12:09:56 -0800, Tim Hockin wrote:
> > 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!
Can you elucidate what your objections are
On Wed, Jan 08, 2003 at 02:27:51PM +0100, Kjetil S. Matheussen wrote:
> > Ny if you map CC1 (say) to a map then changing that will change the
> > sample, its just that, in MIDI, velocity cant change after the voice has
> > started.
> >
> Not quite right, _I guess_ that in some synths you can change
On Wed, 8 Jan 2003, Steve Harris wrote:
> On Tue, Jan 07, 2003 at 10:40:15 -0800, Tim Hockin wrote:
> > > ONe great thing about this scheme is that it encourages people not to
> > > think of certain, arbitary parameters as instantiation parameters, withc
> > > are special in some way, 'cos there
On Wed, Jan 08, 2003 at 12:09:56 -0800, Tim Hockin wrote:
> 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!
- Steve
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 reasona
On Tue, Jan 07, 2003 at 10:40:15 -0800, Tim Hockin wrote:
> > ONe great thing about this scheme is that it encourages people not to
> > think of certain, arbitary parameters as instantiation parameters, withc
> > are special in some way, 'cos there not.
>
> The way I've seen velocity-mapped sample
On Tue, Jan 07, 2003 at 11:37:51 -0800, Tim Hockin wrote:
> > > Either you need to NEVER re-use a VVID, or you need to tell the host when an
> > > ended VVID is actually re-usable. Or you need to have voice-ids allocated
> > > by the plugin, and NOT the host, which I like more.
> >
> > Having the
On Wed, Jan 08, 2003 at 12:23:23 -0800, Tim Hockin 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 s
> 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 a
> > I agree entirely. If each VVID=a voice then we should just call
> > them Voice ID's, and let the event-sender make decisions about
> > voice reappropriation.
>
> Actually, they're still virtual, unless we have zero latency feedback
> from the synths. (Which is not possible, unless everything
> >I made a post a while back defining all the XAP terminology to date. Read
> >it if you haven't - it is useful :)
>
> I was hoping something of this sort existed. It would be very helpful if you
> could put the list of XAP terminology on the webpage. It would help keep
Here are the ones we
> 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'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 continuou
> > 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
> > Either you need to NEVER re-use a VVID, or you need to tell the host when an
> > ended VVID is actually re-usable. Or you need to have voice-ids allocated
> > by the plugin, and NOT the host, which I like more.
>
> Having the plugins allocate them is a pain, its much easier if the host
> aloo
> > > 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.
All the further discussion leads me to understand we like this? Eek. I
proposed it as a straw man.
So we send 1 VOICE
On Tuesday 07 January 2003 20.42, robbins jacob 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
On Tuesday 07 January 2003 20.40, robbins jacob wrote:
> >I made a post a while back defining all the XAP terminology to
> > date. Read it if you haven't - it is useful :)
>
> I was hoping something of this sort existed. It would be very
> helpful if you could put the list of XAP terminology on the
I made a post a while back defining all the XAP terminology to date. Read
it if you haven't - it is useful :)
I was hoping something of this sort existed. It would be very helpful if you
could put the list of XAP terminology on the webpage. It would help keep
everybody on the same page when dis
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 co
> ONe great thing about this scheme is that it encourages people not to
> think of certain, arbitary parameters as instantiation parameters, withc
> are special in some way, 'cos there not.
The way I've seen velocity-mapped samplers is not to change the sample later
- you get the sample that maps
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 vo
On Tue, Jan 07, 2003 at 03:50:26 +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 ob
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 moti
On Tuesday 07 January 2003 15.08, Steve Harris wrote:
> On Tue, Jan 07, 2003 at 01:49:23 +0100, David Olofson wrote:
> > > > The issue here is this: Where does control data go when there
> > > > is no voice assigned to the VVID?
> > >
> > > They get thrown away.
> >
> > Right - so you can't play a
On Tuesday 07 January 2003 15.03, Steve Harris wrote:
[...]
> > 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
On Tue, Jan 07, 2003 at 01:49:23 +0100, David Olofson wrote:
> > > The issue here is this: Where does control data go when there is
> > > no voice assigned to the VVID?
> >
> > They get thrown away.
>
> Right - so you can't play a polyphonic synth with a continous
> velocity controller, unless yo
On Tue, Jan 07, 2003 at 01:41:43 +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 li
On Tuesday 07 January 2003 10.28, Steve Harris wrote:
[...]
> > This is also for debate - David dislikes (and I agree) the notion
> > that you have to send a note-on but the plugin does not have
> > enough info to handle (for example) a velocity-mapped sampler
> > until later. Process events in or
On Tuesday 07 January 2003 10.23, Steve Harris wrote:
> 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: Wh
On Tuesday 07 January 2003 10.19, Steve Harris wrote:
> On Tue, Jan 07, 2003 at 03:21:22 +0100, David Olofson wrote:
> > > > 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 s
On Tuesday 07 January 2003 09.15, Tim Hockin wrote:
> > continuous note on a particular VVID. The sequencer only reuses a
> > VVID once it has ended any previous notes on that VVID. The
> > sequencer can allocate a
>
> This is the current issue at hand - just because the sequencer has
> ended a VVI
On Tuesday 07 January 2003 04.24, Tim Hockin wrote:
> > 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? Isn't a "voice o
On Tue, Jan 07, 2003 at 12:15:40 -0800, Tim Hockin wrote:
> > continuous note on a particular VVID. The sequencer only reuses a VVID once
> > it has ended any previous notes on that VVID. The sequencer can allocate a
>
> This is the current issue at hand - just because the sequencer has ended a
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
On Tue, Jan 07, 2003 at 03:21:22 +0100, David Olofson wrote:
> > > 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.
Bu
> continuous note on a particular VVID. The sequencer only reuses a VVID once
> it has ended any previous notes on that VVID. The sequencer can allocate a
This is the current issue at hand - just because the sequencer has ended a
VVID with a voice-off, doesn't mean the voice is off. It just beg
My understanding of VVID's is that the sequencer puts one complete,
continuous note on a particular VVID. The sequencer only reuses a VVID once
it has ended any previous notes on that VVID. The sequencer can allocate a
large number of VVIDs so that it never has to make a voice stealing decision
> 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 *ful
On Tuesday 07 January 2003 01.55, Tim Hockin wrote:
> > > 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 ve
> > 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
On Tuesday 07 January 2003 00.31, 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.
>
> You always process all events for timestamp X
> 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, al
On Monday 06 January 2003 23.04, Tim Hockin wrote:
> > 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 arr
On Monday 06 January 2003 22.03, Steve Harris wrote:
> 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
> 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
w
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
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 o
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 parameter
84 matches
Mail list logo
