Re: [Linuxsampler-devel] GUI screenshot , Linuxsampler status,thoughts etc (long)

[Simon J. <sje...@bl...>]

Benno Senoner wrote:

>For audio it's obvious that it is a continuous stream of data but for
>modulation data I was thinking about using events as described above.
>That way you avoid wasting memory, bandwidth and cpu cycles doing like other
>modular synths where you send modulation data as it were an audio stream (at k
>rate like in csound).
>
IMHO events are best used for units of "musical meaning" eg the sorts of
things that MIDI encodes moderately well (provided you are a pianist).
That sort of stuff enters a synthesis engine's inputs, may get moved
around and processed a bit, but sooner or later its got to be turned
into something the audio end of the engine can actually *work* with...
a continuous stream of data either at sample-rate or some low-fi
subdivision of it. Why delay the inevitable? Its an envelope-generator's
*job* to turn some events into a data-stream according to some parameters.

>Of course nothing forbids us to implement that approach too. 
>But I think modulation by linear segments is flexible enough
>
Linear segments aren't so much "events" as they are data-compressed
versions of continuous streams. The recipient has to decompress them
back into a stream (probably "on the fly" by interpolating along the
segments as it goes) before modulating any audio with them.

Its a performance overhead, not a saving, to do...

events+params -> envelope encoding -> envelope data stream

rather than directly

events+params -> envelope data stream

unless...

> and is IMHO
>one of the fastest approaches since the amount data moved between modules
>is small.
>
...you are planning to win back the time by moving less data around.

However:

If the synth engines are going to be compiled, then data streams
don't have to be moved anywhere. Nothing except the final audio
outputs ever needs to leave the engine, and the compiler can
generate code which *takes each value from wherever it already is*.

(If the generated code were internally blockless and reasonably
optimised then the data for a lot of streams would never even
make it to RAM: It would appear in an FPU register as a result
of one FP operation and be almost immediately consumed
from there by a subsequent FP operation.)

Simon Jenkins
(Bristol, UK)