Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

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

Hi all,
sorry for this quiet phase, but the work at the ISP I work for
took a month longer than expected.
Before the end of the month it will be done thus I will finally
 be able to get back on linuxsampler. (hopefully I'll not be regarded
 as the vaporware man because of these delays ;-) )

Anyway in december I wrote some benchmark code and enveloping and
 event schemes for basic building blocks (the sampler engine).
I have not implemented this stuff in code but I have some stuff
written on paper.
Now I see this XAP stuff from David O., it looks very cool but due
of my scarce spare time during the last weeks I was unable to
 read all the gigabytes of text that David and other produced.

Perhaps it would be beneficial for all us to implement LinuxSampler
 as a XAP plugin ? who knows ? 
The fact that LinuxSampler's goal is to being able to user compiler
techniques (you "draw" the signal graph on the screen , compile the
result into C code and then run it through loading the .so module),
 means that the API needs to be flexible and/or extensible so I
 have currently no idea if it would be a good idea to build LinuxSampler
 on XAP internally or treat it as a black box and export only the
 audio-out channels, the MIDI-ins plus some internal controls.

I think it will be a good idea to keep the thoughts of XAP and
 LinuxSampler guys in sync in order to optimize both the API and
 the sampler engine.

In a week or so I will discuss and ask for comments about my ideas of
implementing the modular sample playback engine that uses compilation.
One of the most interesting topics will be how we implement efficient
 event passing between the sampler's modules (eg two envelop generators
that output to an adder module which in turn drives the sampler's pitch
 or volume.
Being a bit of a nitpicker, I'd like to achieve sample accurate
or near sample accurate event timing, allow dense streams of events
(eg up to 1/4 - 1/8 samplerate) without too much performance penalty
while retaining modularity and flexible event routing).
It's not an easy task to solve, but my preliminary brainstorming
 suggests me that it is possible to retain high accuracy with only
 a few small tradeoffs.
David is a quite good "event-hacker" so I hope that he gives us the
right advices in order to avoid design mistakes.

Immagine the handyness of loading an akai.so, module and start playing
AKAI libraries with the speed of a hardcoded engine.
The same can be said of GIG libraries.
Fortunately the disk playback was solved a few years ago so what's missing
 is mainly some good event/modulation system, sample loading libriaries
(swami etc) and a GUI (the proposal was
to decouple the GUI from the engine using a TCP socket so that you can
build headless "sampler farms" that can be controlled remotely from an
 arbitrary machine (even a TCP/IP equipped PDA :-))

I know many would like quick results fast (I would like them too), but
 unfortunately a good audio engine takes time to design and we have only
 few complex open source audio projects where we can learn from.

I think the biggest near term challenge is to get the basic sampler
(with recompiler) and even system up and running.
From this point it will be easy to parallelize work so that people
can start working on sample libraries, GUIs etc, testing and improving 
the accuracy of reproduction of sample libraries etc. (filters, envelopes, 
modulators, keyzones etc)


cheers,
Benno





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

> On Monday 20 January 2003 17.09, David Gerard Matthews wrote:
> > Hey Mark,
> >                 I've been on this list for a few months as well and
> > noticed it's kind of died down.  Not sure what's up with that - it
> > was very active around November, iirc.  There has been some
> > discussion about Swami, but I think the real hope for sampling
> > under Linux might be XAP (discussed extensively on
> > linux-audio-dev.)
> 
> Well, I'm not really involved with Linuxsampler, but I'm certainly 
> responsible for most of the bandwidth in the XAP discussion. ;-)
> 
> XAP is a plugin API, so it doesn't really deal with sampling or any 
> other form of synthesis directly. Linuxsampler would be very useful 
> as a XAP plugin, but that's really more of an API selection matter 
> from Linuxsampler's POV. That is, we still need something to turn 
> into a XAP plugin. :-)
> 
> 
> //David Olofson - Programmer, Composer, Open Source Advocate
> 


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