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

[David O. <da...@ol...>]

On Monday 20 January 2003 18.35, be...@ga... wrote:
> 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 ;-) )

That used to be me, but I'm not sure I qualify any more... ;-)

(Audiality was resurrected for the third time, and inherited the code=20
from a games sound FX engine that came be by pretty much "by=20
accident", when I worked on an SDL port of the old game XKobo; Kobo=20
Deluxe. That is, I finally have something that can actually play=20
music. :-)


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

Sounds interesting. (I remember seeing something about this on LAD,=20
or somewhere.) Will you make your findings and thoughs available in=20
digital form?


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

Oops. Sorry 'bout that! ;-)


> Perhaps it would be beneficial for all us to implement LinuxSampler
>  as a XAP plugin ? who knows ?

I think it would be beneficial, provided it works at all, basically.=20
And - obviously - provided there will be usable XAP hosts before=20
LinuxSampler is mature enough for serious use.

Note that XAP plugins need to have their GUIs in separate processes,=20
to avoid GUI toolkit conflicts with the hosts! This applies to=20
in-process JACK as well, though, and shouldn't be a surprize to Un*x=20
developers. (BTW, is in-process actually implemented in JACK? Wasn't=20
last time I looked.)

Besides, I think total separation of GUI and DSP code is a good idea=20
anyway, for a number of reasons. (Stability, GUIs can be left out or=20
replaced, etc...)


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

This wouldn't be a problem. Just have the GUI do the compiling, and=20
then tell the plugin to load the .so and "mount" it. The latter is a=20
perfect job for the background worker calls I've suggested.

This isn't very different from loading patches into a normal synth or=20
sampler. There's just no way you can do it in the RT thread without=20
causing drop-outs, so you *have* to make someone do it in a separate=20
thread.

And it can't be easier than telling the host to call a function from=20
a suitable context and send you a RESULT event when the call returns,=20
can it? (Much easier than using pthreads, and - free bonus: it=20
doesn't break down when running off-line.)


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

Yes, that's=A0what I've been thinking - but it seems that most others=20
in the XAP discussion have very little interest in plugins that don't=20
concist of 100% RT safe code... Could just be that I've failed to=20
explain the issues properly, though, or that we have so many other=20
things to worry about first.


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

Well, in fact, I'm messing with that kind of stuff right now. :-)

I've been trying to find the optimal set of events for ramped=20
controls, and Steve's suggestion to use only *one* event looks like a=20
great idea!

Next, I'll probably have the envelope generator multiply it's output=20
with incoming "scale" events, to implement click free volume and pan=20
and things like that. That is, multiplication of two ramped event=20
streams.

If all goes well, the result will be in Audiality 0.1.1, to be=20
released sometime before everyone's forgotten the name, hopefully. ;-)


> 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 :-))

With XAP, it seems like GUIs will interface to plugins through the=20
standard control system. You could think of them as XAP plugins,=20
running in their own soft RT hosts, connecting to the RT hosts=20
through an RT/non-RT gateway. No custom interfaces needed, that is.=20
The plugin<->GUI transport layer can become part of XAP.

In short, I think it's better to wrap this stuff in a XAP host SDK=20
lib, so you can use raw TCP/IP, JACK or whatnot, without rewriting=20
hosts and GUIs.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---