Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[David O. <da...@ol...>]

On Monday 12 January 2004 01.50, Mark Knecht wrote:
> On Sun, 2004-01-11 at 15:55, Christian Schoenebeck wrote:
> > > =09* Is Delay a minimum note-off->release delay,
> > > =09  the maximum duration of the sustain state,
> > > =09  or what? (Both seem useful to me...)
> >
> > That 2nd "D" is actually Decay2. It's an exponential fall from
> > the last Decay1 level to the first level of the Release stage.
> > Decay2 will only become applied in case this "infinite sustain"
> > is disabled, but I'm not that sure. Maybe Mark can confirm that?
>
> I believe this is a correct description.
>
> With Infinite Sustain enabled Decay 2 is not used.
>
> With Infinite Sustain disabled, Decay 2 begins at the end of Decay
> 1. This appears (in my mind) to create a first, normally faster
> decay region like everyone is used to. After that first decay
> period, Decay 2 kicks in and GSt will then does a second decay
> period that takes you down to 0 volume. I think the intention here
> is to ensure that all notes eventually go to zero even if their
> keys are never released.

Actually, I think the intention is to make it easy to program natural=20
envelopes for looping samples. Nature tends to be exponential rather=20
than linear. :-)

And indeed, I *am* having trouble with the linear envelopes in=20
Audiality, even with the off-line synth, which has multi-section EGs.=20
Just look at the cymbals and stuff like that... *hehe* There's a new=20
EG output transformation feature now, but it doesn't seem to do the=20
job well enough. Could have screwed something up there, though; that=20
feature has hardly been tested.


> This does raise one unsolved issue I've seen with LS. To date I
> think LS has no mechanism for releasing the oldest notes when it
> reaches its maximum note count. Press sustain and start hitting
> keys. Eventually you get messages about not being able to play
> notes.

Or "voice stealing", as it's usually called... When allocating a new=20
voice, I just
=091) look for free voices
=092) look for the softest voice with same or lower priority
=093) steal the lowest priority voice (same or lower)
=094) fail

Now that I think of it, I'm not quite sure what I was thinking there,=20
around steps 2 and 3. Hmm... It should probably look like this:

=091) look for free voices
=092) look for softer voices with same or lower priority
=093) use the softest voice with same or lower priority
=094) fail

(That is, first try to find a softer voice. If that fails, just use=20
the softest one found.)


Anyway, I just brutally kill stolen voices. It appears that quite a=20
few h/w synths do that as well, but that doesn't make it an=20
acceptable solution, IMHO. One should use some "low cost" temporary=20
voice mixer or something, to allow the stolen voice to die without=20
clicking.


BTW, priorities is what I use to keep sound effects from killing long=20
notes in in-game music and stuff like that. Simple and handy, and=20
works well as a generic improvement of the voice stealing system. You=20
can't (ab)use it to make polyphonic patches monophonic, though.

Some Roland synths use a "voice reserve" system instead, which allows=20
you to allocate a fixed number of voices for each part (ie "MIDI=20
channel", sort of). That has other limitations, but it sort of does=20
the job, unless you're very low on voices and have many parts. All=20
parts without voice reserves just fight for the remaining voices.


> LS needs to be able to release the oldest notes to that new notes
> can be played. Generally it will be better to get a release or
> something from very old notes going away vs. not playing the newest
> notes.

Right, but don't forget to actually check whether the voices just have=20
a slow release, or if they're in the sustain state, waiting for=20
note-off. However, even if you do that, there's always the risk of=20
stealing the wrong voice. You'd probably have to do a continuous=20
spectrum analysis of all playing voices to reliably tell which one is=20
the least audible - and even then, you can't tell whether the note=20
you just killed will be the only one still playing a second from now!=20
:-)

That reminds me; I once had this idea about "voice unstealing".

I'm thinking about implementing it in Audiality, using dummy voices to=20
keep the EGs and stuff alive and running, until there are free=20
physical voices available. The dummy voices would not mix or=20
anything, but just do what they need to keep track of the current=20
pitch, volume, playback position etc, so they can force load a=20
physical voice at any time.

Before I do that, though, I should probably benchmark the code and see=20
what kind of CPU time ratio there is between the control stuff and=20
the voice mixers... :-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---