Re: [Linuxsampler-devel] envelopes, events, Re: LS click/pop investigation

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

On Tuesday 30 December 2003 10.26, be...@ga... wrote:
[...]
> David (Olofson), what do you suggest ? Using an event system
> similar to the one you use in audiality ?

Well, that's really more about scalability and accuracy; with a sample=20
accurate event system, you can put ramps (of whatever kind you may=20
have) exactly where you want them, and the "new ramp" calculations=20
hit you only when you actually start a new ramp. If you're using=20
linear ramps only, the code in the inner DSP loop is very simple and=20
fast, but depending on what you're playing, you *may* get extra=20
overhead due to the greater number of ramp events needed at times.

Basically, an event system has a low, fixed cost in the DSP units that=20
use it. It does not have the accuracy limitations of systems with a=20
control rate lower than the audio sample rate, nor does it have the=20
higher fixed cost of converting control values to internal audio rate=20
"control change coefficients" eveny N audio frames.

So, in short, I'd recommend an event system regardless of what kind of=20
ramping is used, for any serious system that doesn't use audio rate=20
control streams. Any fixed lower control rates will cause trouble in=20
some situation, forcing sound programmers to use prerendered samples=20
for trivial things like short attack noises and the like.

OTOH, this is probably not a major issue in a sampler. A virtual=20
analog synth *must* have very accurate envelope timing for serious=20
percussive sounds, but on a sampler, you tend to use envelopes and=20
effects to tweak the timbre of complex sounds, rather than to create=20
new sounds from very simple waveforms. A fixed control rate might=20
work, but it would make LinuxSampler more specifically a sampler,=20
without much scalability into "real" synthesis.


> For performance reasons I'd opt for a system that uses only linear
> segments for both volume and pitch enveloping.
> exp curves and other kind of envelopes can be easily simulated by
> using a serie of linear segments.

Note that Ian points out, non-linear segments aren't all that=20
expensive. However, reverse calculations, splitting, combining and=20
otherwise manipulating streams of "ramp" events, gets more=20
complicated with non-linear functions, so in some cases, the=20
reduction of event density at the targets may not be worth the=20
increased complexity in other places.

If only performance matters, I guess non-linear ramps could be faster=20
than linear only, but I suspect the code would be a lot more=20
complicated, if we are to do things like combining and manipulating=20
event streams. Not sure, though. It's a balance thing. If there isn't=20
too much code that's affected, a more complex data format might pay=20
off.


> Keep in mind it must for example handle following tasks:
> assume there is a pitch envelope running (composed of linear
> segments). Now the user operates the pitchbender.
> The real time event is timestamped and delayed till the next audio
> fragment gets processed. If there is already an envelope running
> the pitchbender needs to "add" his own pitch to the current one
> possibly using an event. for example if we want two pitch envelopes
> modulating the same sample what's the best way to do it ?

Right; this is where linear segments become a bit easier.

However, note that not even linear segments are trivial in a system=20
where the ramps of streams to combine can start and end at any time.=20
There's also a risk of event density exploding, if you combine too=20
many streams, as the normal solution would be to just split every=20
time a new ramp event comes in from either source. If there is a risk=20
that you'll frequently be combining streams with high density, you'll=20
need to take care of this one way or another. Meanwhile, this problem=20
does not exist in a fixed control rate system.

Hybrid solution: Dynamic control rate. Use timestamped events, but try=20
to keep events locked to a common heartbeat as far as possible, so=20
you get events from multiple inputs simultaneously most of the time.=20
You could even require that all plugins in a sub-net use the same=20
heartbeat at all times, so your event processors will only ever see=20
simultaneous events.

I guess one could come up with hybrids from all over the scale between=20
fixed control rate and timestamped events.


> Since pitch envelopes are made of "deltas" in theory one could
> simply add up the deltas when events come in.

Yes - if the adding is done where events turn into parameters for some=20
DSP code. However, if you have dedicated event processing plugins,=20
the normal action would be to update the internal deltas and generate=20
new events. Thus, every input event results in one output events.=20
Even eliminating doubles with the same timestamp requires extra work.=20
(Not much, though. Just keep a flag to trig the generation of the=20
output event before checking the # of frames to the next input=20
event.)


> eg ... if there is only one envelope then the events should
> overwrite the current pitch delta but if you want to mix two or
> more envelopes then deltas should added up (basically you could
> calculate the delta of the delta between events and simply add up
> that to the current delta. That way AFAIK it should work with one
> single and multiple active envelopes.
> Am I missing something ? :-)

Well, if you're going to do this in a seriously useful way, I don't=20
think you can do it at the delta level near the DSP code. Combining=20
controls usually includes some scaling as well as adding. More=20
importantly, unless you want to hardwire the control routing, you'll=20
proper nets of event processor plugins, rather than support for=20
multiple outputs to one input.


//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 ---