Re: [Linuxsampler-devel] Suupporting various sample library formats and engines

[Juan L. <co...@re...>]

On Mon, 4 Nov 2002 14:13:16 +0000
Steve Harris <S.W...@ec...> wrote:

> On Tue, Nov 05, 2002 at 12:03:36 +1000, [3] wrote:
> > >So, I think it is better to have seperate sub-engines that communicate
> > >with the main engine at a high level (eg. to the sub-engine: "Here is a
> > >bunch of event data ...", from the sub-engine: "I want 8 outputs", "here
> > >is a lump of audio data ...").
> 
> > >The alternative would be to normalise all the sample formats into one,
> > >grand unified sample format and just handle that (I believe that is how
> > >gigasampler works?).
> 
> Of course, the counter argument too all this is that writing a full
> sampler engine for every format we want to support fully sucks, no-one
> probably needs all that functionlaity anyway, and we should just write
> translators ont a common, comprehensive format and live with the slight
> conversion loss. <shrug>
> 
> - Steve
> 

I think i said this over IRC, but i'd like to say it again.
Being the central part of the issue the "Voice".
The abstration to me should be like this:
(hope you have fixed font, in any other case, left item connects to last :)

#Sample Library reading engine -> *Disk Streamer -> #Voice <- *Engine Manager <- #Engine
|_________________________________________________________________________________^

* means common-to-all object
# means specific implementation inheriting from a common base (through a polymorfic interface).

So, I think the Engine/Voice processing/Library File reading should be implementation specific (giga/akai/etc),
but it should communicate with the existing framework through common objects to make our life easier
while programming. Remember, not everything is just reading and streaming, all the midi event handling,
voice mixing/allocation, effect processing and buffer exporting must be common to all interfaces. 
This would end up in a framework for emulating existing samplers. I used this approach in legasynth
(http://reduz.com.ar/legasynth) with a lot of success already, and it should make writing specific implementations
of sampling engines a _lot_ easier.


Juan Linietsky