[Linuxsampler-devel] status update for LinuxSampler

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

Hello LinuxSampler guys :-)

sorry for being that quiet but was a bit overloaded again during
the last two few months.

I've read all pending mails and I will try to summarize my thoughts about
the project and its future and the current status and how we can collaborate
in order to maximize parallelism.

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.

Regarding the engine:

some said they do not like C++ and want do to everything in C etc:

My take on this is that we should find some good compromise between performance
and modularity and flexibility of the engine.
My old evo code is written in C++ and IMHO it offered various advantages over
a C implementation without any performance degradation.
I'm not a heavy-duty C++ programmer thus usually I use only basic C++ features
like classes and methods.
In the case of a sample player C++ helps you to bind data structures to certain
 objects (eg voices) without messing around with tons of structures and passing
 around pointers of structures between various functions.
Ringbuffer C++ templates (lock-free FIFOs) proved to work very well in terms of
speed (the resulting assembly code is almost optimal) while helping to 
keep the code clean.
When speaking of code cleaness I do not mean only that it is beauty to read but
 with clean I mean that object oriented design reduces chances that the object
 itself accesses data that is not meant to be accessed by that object possibly
resulting in a program crash or glitch.

Some say they cannot program in C++ so they only contribute if the core is
written in C.
I see this as a bit lame excuse since it is really not that hard to learn what
a class and a method is in C++.
If as a coder, you are able to write good C apps then I do not see why one
should back away from a sample engine written in lightweight C++.

As said, I have nothing in contrary to go plain C, but commonsense says me 
that C++ is the better choice because the sampler project will probably grow
over time and OO design helps you to keep the design of the project/engine cleaner.

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.

Some on this list say this is overkill for a sampler and that we should start
with a hardcoded engine and later switch to a moduler one (just-in-time compiled).
I think rather than duplicating the effort it is better to write a very simple
 modular engine and at a later time enhance its capabilities.

My idea was to start with a RAM sampleplayback module that can do only very 
simple stuff:

- it has a pointer to the sample to be played 
- it knows how much samples to play and possibily can access to a simple
 looping list 
- pitch can be modulated
- volume can be modulated

In order to create a very simple MIDI-playable instrument

along with the ram sampleplayer, an instrument loading library is needed.
(loads samples and patches in RAM  and exports pointers to samples and parameters)

another basic module we need to implement is a MIDI input module that maps
incoming MIDI data (MIDI ins or alsa sequencer) to instruments which in turn
point to samples in memory and modulation data that can be used to drive
the RAM sampleplayback module along with some modulators (volume modulator
for creating envelopes and pitch modulator for creating vibratos etc).

I think this would costitute a nice starting point for building a full fledged
 sampler which accepts multiple formats and engines.

I'm not 100% but in my opinion it would be wise to associate a playback engine
o each samplelibrary format.
Eg the GIG engine plays GIG files, the AKAI engine plays AKAI samples.
I do not believe that the "one size fits all" model always work.
As Peter Hanappe pointed out it is better Fluid tries to specialize on playing
 SoundFont samples as good as possible rather than trying to become the 
allround sampler that can play everything.

I think the best way to make LinuxSampler a sampler that can reproduce various
 formats is to make it modular as described above.
Once a handful of basic modules are implemented, I think it will be quite easy
to add new engines since the goal is basically of being able to assemble new
engines using a graphical editor where you wire toghether basic building blocks.
If a new engine needs features that are not covered by the available modules,
fire up your editor, code the module, and then get back to the GUI and complete
the building of the instrument engine you had in mind.

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


I'm currently writing a multichannel sample playback engine (not instruments but
sounds and music) for doing ambient music and noise in a museum room.
I use a Linux PC with two Delta cards (8+8 outs) under ALSA.
This is not a big project but LinuxSampler will profit from this since I will
 get familiar with multichannel audio hardware which should be supported by
professional apps. (as LinuxSampler should be)

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.

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 ?

In the next days I will explain my ideas about volume and pitch modulators
and how to build modulation networks.

To eliminate some confusion: there are currently two codebases for linuxsampler:
one is evo which is basically a proof-of-concept code of a very rudimentary
disk based sampler and the other is the code on CVS uploaded by Juan L. which
is based on the legasynth codebase.
I regard both apps only as proof of concept applications and I suppose 
the real linuxsampler codebase will probably be built from scratch especially
 if we go the modular-recompiler way.
As said the project lacks a bit of organization right now since our goals
are not well defined yet but I think over time things will get better.
Anyway I'd like to discuss with you guys which route to go for building
the sampler's engine.
I know some are getting impatient while other may think this will become another
dead project, but I think there are just too many talented folks on this list
 to let such a cool project die off.
Yes, we all have daytime jobs so sometimes the project's advance will slow down
 a bit but hey, that's life in the open source domain. As long as there will
be interested and enthusiastic people partecipating I do not fear that the
project will die. Linux and powerful GNU software was not built in a day and 
I'm confident too that through collaborative work and discussion linuxsampler
 will some day deliver the funcionality we dreamed of for long time.
(argh too much rethoric, back to code :-) )

PS: Welcome to the ML to the Kurzweil guy too  :-)

waiting for your feedback guys.
 
cheers,
Benno

http://linuxsampler.sourceforge.net




 

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