Re: [Linuxsampler-devel] status update for LinuxSampler

[Josh G. <jg...@us...>]

On Mon, 2003-03-24 at 12:41, Benno Senoner wrote:
> 
> As far as I can see it, the sampler consists of several sub-projects
> which are related:
> 
> 1) instrument loading library
> 
> 2) sample playback engine for each kind of sample library format
>   which permits real time / sequenced playback and real time modulation
>   of parameters (LFO, filters, ecc)
> 
> 3) a graphical editor that permits loading (through 1) ),creation and
> manipulation of instrument libraries.
> 
> 
> Personally  I will focus on 2) since it involves
> real time stuff, optimized data flow mechanisms, streaming etc.
> 
> I think swami could solve 1) and 3) as long as it is flexible in providing
> support for various sample formats.
> 

Yes, I could see Swami/libInstPatch fitting nicely with 1 and 3.
libInstPatch and Swami aim to be as flexible as possible with patch file
formats. In other words, I haven't tried to integrate all patch formats
(an insane task), so each important format will be supported natively
(all details of the format for load/manipulate/store). Many old or not
so important formats will probably just have import support. Much of the
API is integrated in the use of GObject though (all objects have "name"
based properties with a fairly extensive type and parameter system).

libInstPatch does have in mind multi-threading capability. There is
still a bit that should be done in the area of performance versus
multi-threading though, particularly relating to item lists.

I'd like to get a better idea of how linuxsampler will be accessing
patch objects. I remember this was discussed a little. It seems like the
synthesis process should be constructed when an instrument is selected
(MIDI bank:program change, whatever). So it might go something like
this:

- instrument selection (MIDI bank:program change)
- linuxsampler patch type specific synthesis constructor called
- synthesis network setup and populated from libInstPatch objects
- wait for input events (MIDI note on/off, real time effect control
requests, etc)

In this scenario the performance requirements of libInstPatch are
minimized as the parameters are fetched at instrument select time. Real
time sensitive parameter changes could be sent via linuxsampler API
calls while other changes could be monitored via property change signal
callbacks.

> Regarding the engine:
> 
> some said they do not like C++ and want do to everything in C etc:
> 

I'm a C coder myself, but I also like OO stuff. GObject is what I have
decided to use for libInstPatch/Swami. Its taken me a while to
understand GObject fully and a lot of things seem kind of hackish (and I
guess kind of are since C wasn't designed for OO stuff), but I'm
beginning to like it. I'm not real sure of the performance implications,
but I know GStreamer uses this same platform. glib (what GObject is now
part of) is a nice utility library that has lots of things like hash
tables, linked lists, binary trees, memory chunks, cross platform
threading and variable types (guint32, gint16, etc).
I'm not opposed to C++ though. I am curious how well GObject related
stuff would mesh with C++ code.

> 
> Regarding the audio rendering:
> 
> My idea was to make sort of modular sampler where you assemble the basic
> building blocks with the most important module being the sampleplayback module
> (a RAM and a disk-streaming version).
> The idea was to assemble modules at source code level so that the compiler
> can create a very efficient engine which is almost as fast as a handcoded one
> but provides the flexibility of permitting the creation of instruments in a
> modular fashion though a GUI, similar as Native Instruments Reaktor and others do.
> 

<cut>

> 
> Do you agree of going down that road or should we take other paths ?
> 

I think the modular design fits with what linuxsampler is supposed to
be. So yes, I agree with that path. I like the idea of a system that
builds custom code though (I was looking into a similar thing a while
back where each module was an assembler macro and then a master routine
would be auto-generated with the calls to the macros). Even just
starting out with each module being a subroutine would give us the basis
of a modular synth and optimization tricks to remove subroutine
overhead, etc could be implemented later (self building code). I think
thought should first be put into the different types of modules, how
they will route their inputs and outputs and the range of patch formats
that we are looking to support. Wavetable interpolators, envelopes,
LFOs, filters, LADSPA plugins, reverb, and chorus O MY!

> 
> Josh: I added you to the project admins (full access to everything) on the
> project page of LinuxSampler since I assume you will be the main contributor to
> the sample library handling for linux sampler.
> 

Hmm. For right now I think I will be using Swami/libInstPatch project
site/CVS/etc as the source of information. Perhaps we could try and
cross link the two sites more in this regard though. I can see
linuxsampler and libInstPatch/Swami being a nice marriage of programs,
but they will probably also be useful separately as well. This is the
design that has been followed with FluidSynth. Our projects don't depend
on each other, they just work well together :) I'd be more than happy to
help with stuff on the linuxsampler site, but I kind of feel like my
effort is best concentrated on libInstPatch and Swami right now (which
I'm sure will help linuxsampler in the end).

> Regarding the GIG format docs (I assume Paul Kellett sent you Ruben's header
> files), how about posting them on the LinuxSampler site (you can now upload
> stuff yourself) so that others can see the structure of the chunks too ?
> 

Yes, I got the GIG format docs. They will come in real handy :) I'm not
quite at the stage where I will be adding .gig support yet though (still
adding DLS2 support). If there are requests for these docs (anyone?), I
will certainly put them up. I just hesitate to do non-coding stuff when
it won't be that useful, he he.

> waiting for your feedback guys.
>  
> cheers,
> Benno
> 
> http://linuxsampler.sourceforge.net
> 

Its nice to feel like a part of a community here. I'm constantly working
on libInstPatch and Swami and much of the work that I have been doing
has not yet seen the light of day. API work is very time consuming and
sometimes frustrating when one doesn't get the rewards of seeing it in
action. The time to see this work in action is close at hand, I can feel
it. There is still a bit more that I need to do to get the patch
pluggable architecture of Swami in order (mostly GUI stuff). The
addition of DLS2 will pave the way for this and things should go
smoother afterwards. When this starts to come together I will start
looking into how to interface it with linuxsampler. Cheers.
	Josh Green