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

[<be...@ga...>]

Scrive David Olofson <da...@ol...>:

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

Agreed, but I think that the density of linear ramp segments is relatively low
even in the most complex cases. 
I mean: I guess it's impossible to hear the difference between exponential
envelope that is rendered sample for sample and one that is made up
of linear segments that are let's say 8 samples long.
As said our event system is not limited, we can even change values
EVERY sample if we need to but I guess it would be totally overkill because
you are entering the AM/FM modulation domain then :-).
My only concern is if we want envelopes whose shape and characteristics
can be changed by realtime user inputs (eg a MIDI controller).
To keep overhead low we would probably need to precompute such envelopes
and the limitation could be if there are too many variables that
the number of tables gets too big. But these are extreme cases.
Perhaps you could even compute them in real time since 
MIDI CC events occur relatively seldom compared to the samplerate.

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

Yes, I'm against such systems too.
We want sample accurate events because we want future interoperability
with sequencers that can send sample accurate events and we want
LS to provide decent synth-like modulation stuff.
Think about the dynamic DSP recompiler. I guess users will come up with
very interesting "synths" made out of LS modules.
Perhaps in future the "Sampler" word in LinuxSampler will not be 
appropriate anymore. Who knows, we will see .... :-)
> 
> 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.

As said pure sampling is nice and you can reproduce natural instruments
 faithfully by using very large multisamples (many velocity layers plus
 sampling each note/key), but for electronic instrument stuff etc it's 
much better if samples can be modified and shaped by a good modulation engine.
you know .... total world domination in the sampler domain requires high quality
engines :-)

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

That is exactly my point. I'm against fixed control rate and other
 quick-n-dirty tradeoffs I guess you guys are too.

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

Exactly.

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

As said as soon as you have less than one ramping event every 8-10 samples
 (assuming that the there is no audible difference between envelopes
 rendered for each sample) then it pays off to use linear ramps because
the difference between linear and higher order ones is so small.

Plus if you have an event every 8 samples the overhead compared to having
an event let's say every 20-30 samples (because using higher order ramps
require a lower event density) is low since "most of times" there will
not be an event that needs to be handled (at max 1 every 8 samples).
> 
> 
> > 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.

Yes this is one of the disadvantages of event based systems.
Perhaps Christian's proposed bidimensional event arrray is a good solution ?
The only thing I worry about is the time it takes to figure out if there
are events pending.
With the event list you know the samples_to_next_event value and can
simply skip over it in the inntermost audio loop thus when
no events occur there is no CPU overhead.
Christian any idea if the samples_to_next_event can be applied to
your bidimensional event array too ?

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

Interesting but I guess it makes the system even more complex perhaps
not buying us much in terms of performance.
I don't know ... we would need some realworld benchmarks to see what's
 better for us.

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

We will see, I think that after some discussions, we can come up with a good
tradeoff that is both performant, flexible and provided high audio quality.

cheers,
Benno


-------------------------------------------------
This mail sent through http://www.gardena.net