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

[Christian S. <chr...@ep...>]

Es geschah am Sonntag, 11. Januar 2004 23:20 als David Olofson schrieb:
> On Sunday 11 January 2004 18.10, Christian Schoenebeck wrote:
> [..]
>
> > PADSDR
>
> [..]
>
> ???-Attack-Decay-Sustain-Delay-Release?
>
> Some questions:
> 	* What's the first state?

Sorry, that's just the PreAttack value, thus the value from which the Attack 
stage will start. That's actually already honored in the current EG. The EG 
sequence is as follows:

Attack (start from PreAttack value) -> [ optionally] hold -> Decay1 -> Decay2 
or instead Sustain (this is a flag option) -> Release

>
> 	* Why no Hold between Attack and Decay?
> 	  (Nice for tweaking fast, percussive sounds.)

Yes, that will definitely be added. The Giga format has a flag for this in the 
patch format to turn this on / off (for those who don't know what we're 
talking about - this "hold" parameter will postpone the first Decay stage 
until the sample playback reached the loop begin). But again, I'm just very 
priority driven at the moment. I first do all the basic things with the 
highest priority and postpone fine adjustments later if that doesn't hurt the 
design.

>
> 	* Is Delay a minimum note-off->release delay,
> 	  the maximum duration of the sustain state,
> 	  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?

>
> Anyway, I still prefer generic N-stage EGs, something like those in
> FastTracker (and clones) and some h/w synths. They can easily be
> extended with conditional loops and stuff, to handle release and to
> double as event sync'ed LFOs.

Of course, we'll add an artbitrary N-stage EG later, but at the moment the 
goal is just to fullfill all Giga synthesis requirements and Giga has only 
that mentioned EG.

Maybe I should clearify the development roadmap: First we'll finish a complete 
Gig Engine, restructure LS for multi engine support, add network socket for 
the LSCP so we can control LS with a GUI (Qt GUi, VSTi host and whatever). 
Then we will implement other engines, like Akai engine, DLS engine 
perhaps, ...  and as well as our own very modular engine which will get all 
the features you just can dream about. For that we'll add the recompilation 
feature which just came out of Benno's mind. This means you will be able e.g. 
select all the features you want to have in your very custom sampler engine, 
click an "Apply" button in the GUI and on LS side your custom engine will 
just be compiled and deployed in realtime. So you have your own custom engine 
that is as efficient as it only could be. There are really a lot of parameter 
here where you could choose from: e.g. as mentioned which kind of EG to be 
used (and how many of them, with which influence), frequency of the event 
handling (sample accurate or an arbitrary frequency), various filters (or 
even no filter at all - to save CPU cycles), various interpolators (simple 
lin., cubic or even a sophisticated interpolator with formant frequency 
correction),  and and and....

For example if somebody needs an Engine for playbing samples or something, he 
wouldn't probably need to pitch the samples at all, so he will disable 
interpolation and things like modulators completely and thus saves CPU 
cycles. Or if somebody wants to use real (singer) voices, he'll probably 
needs a more heavy setup with an interpolator that is capable to correct 
formant frequencies, so the voices don't sound unnaturally if pitched over 
several semi tones.

That's the idea and overall roadmap for LinuxSampler I currently have in mind.

CU
Christian