Thread: [Linuxsampler-devel] Linuxsampler status,thoughts etc (long)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hello,
sorry for being that quiet during the last weeks, work overload you know ..
Anyway during the last days a few of us (me, Marek, Juan L. and others)
discussed about the possible roadmaps for linuxsampler.

While we haven't produced useful code lately, some of us came up with
nice ideas. Some say linuxsampler will never happen, or that
some do "voice" too much, but hey I think passionate discussion sparks interest
and creativity. Plus good things take time to develops and unfortunately
 we are not in the fortunate situation like Paul D. where we can
work full time on our favorite OSS project.

That said, personally I'm still convinced that it should become a "modular
sampler" because I do not like hardcoded engines that much since they limit the
creativity of the user.
Obviously should allow importing multiple sampleformats but in this regard
there is a opinion split: some (like me) say we should write separate
sample loading modules for each format (gig, akai etc) that store the samples in
datastructures using the native representation, while others say that it
would be better to create some powerful (and if possible extensible) internal
format that can accomodate most common formats in order to simplify things.

I'm not sure about that and if we really write a modular sampler
(where you can assemble the various engines using a GUI editor along the
lines of NI Reaktor) if in case of using "native sampleformat loaders" the
 code duplication would really be that high as some state (Marek).

Of course it would be cool to use the GIG engine to play AKAI samples
and viceversa. But when using native loaders you could alway write a
GIG to AKAI converter module that reads the GIG metadata that the GIG loader
 put into mem and converts them to the AKAI datastuctures.
Of course the "universal internal format" has the advantage that
you can convert form any input format to any output format by writing
 a converter module that can convert from/to the universal to/from the
 specific format.
That way if you have N formats you only need to write N converter modules
instead of N*(N-1) if you are using only native formats.

I back the native format loader solution since you can tune the engine
 exactly to work hand in hand with that format instead of going through
the intermediate universal format.

This mean you can tune the GIG engine to work exactly with GIG specific
enveloping data, filters, looping etc. Same applies to all other formats.

Of course one would want to use the GIG engine to play AKAI samples but we can
write a converter module (that is probably quite simple since AKAI's sample
 engine is simpler than GIG's one).
But I think the N*(N-1) n. of converter modules equation does not apply here
since I think it is unlikely to want to play GIGs using the limited AKAI engine.
Since we include both engines it makes sense to use the native one.
So probably the number of format converter modules is more likely determined
by (N of simple formats) *( N of complex formats).
Since the N of complex formats (like GIG) is not that high I guess the number
of converter modules would still stay quite low but with the benefits of
having native loaders and native engines that go hand in hand.

Marek would object here but I think using an internal universal format
make it hard to avoid conversion losses that makes it hard to achieve
faithful playback.
Of course many sampleformats share many properties like keymaps,
envelopes, filters, looping information etc, but unfortunately often each
format uses its own representation where a bijective A<->B converter function
 does not exist.

For example when speaking about envelopes: some formats use simple ADSR models
 while others allow arbitrary linear or exponential enveloping segments.

How to avoid the code duplication in the loaders and engines ?
Use the modular approach !
Since the final engines will be compiled using the following approach:
module editor -> C source code -> compiled .so file that gets loaded by the sampler
the speed will be OK even if we assemble the engines using a Reaktor-like GUI
(and it will be very userfriendly and handy to add new custom engines).

So basically when we have implemented enough basic building blocks (filters,
envelope generators, etc) designing new engines becomes a breeze.

Not sure about the loaders (if we could use a GUI editor to compose loaders too).
Most sampling formats are based on the RIFF format (GIG, DLS, SF2, WAV etc)
so a RIFF parser is needed anyway but the individual modules that interpret
the data contained in various RIFF chunks still need be written by hand.
But to achieve maximum flexibility instead of writing a monolithic format
 importer we could write let's say a general RIFF parser and then specialized
 modules that interpret the various RIFF chunks.
That way if we happen to support formats that share some characterisics
(eg GIG is nothing more than DLS with some proprietary additions) can can
fully reuse the modules.

I think using the approaches described above the "code duplication" can
be kept really low while the flexibility increases quite.

Regarding the GUIs: As you know I support the idea of totally decoupling
 the engine from the GUI. It improves code quality because you do not
mix GUI stuff with engine stuff. Plus if you use a TCP socket you can
even run the GUI on a remote machine that can run even another OS than
Linux. (eg. assume a Mac OS X frontend box networked with a headless
linuxsampler box).

As for the module composer form the discussion we had on IRC we seem to agree
that the best thing to do would be making a "stupid" GUI which only forward
commands to the engine.
That way when you wire togheter the basic building blocks in the GUI editor
apart from displaying them wired together it does nothing than issuing
a connect(module1.out,module2.in) command to the engine which does the
appropriate stuff.

That way you can even use scripts, commandlines or textual interfaces
that can manage and construct audio rendering engines.

Regarding the sample importing modules: I think it would be wise to use a bottom
up approach thus IMHO it would be better to not use and extend complex
monolithic applications that can read/edit samples.

Josh is writing LibInstPatch and I think it is a nice lib but I'm unsure if
it is the right way to go.
I think the only way we can solve the problems that linuxsampler poses is a
divide et impera approach. So write many "micro modules" and "wire" them toghether
 using a GUI.
That way you can, as Steve Harris said some time ago, make a good "sampler
construction kit".

Regarding the code and what to implement first.
I admit we haven't done much lately but meanwhile the ideas kept flowing and I
think it helps to avoid design errors.

Thanks to Sebastien and Christian we now have libakai running on Linux.
(libakai is a small lib that reads an parses AKAI sample images).
I think this is the right kind of lib for linuxsampler since it is lean, very
low level, does not contain a GUI and can easily be embedded into linuxsampler
 importing modules.

So basically we need to figure out which kind of modules we should start
implementing.
It is not easy to choose where to start since design errors in one module
can later affect the design of other modules.

So I think it would probably be the best to start with the GUI.
A module editor similar to Reaktor where you can assemble basic building blocks.
The real DSP network building process will occur within the sampler engine
so the GUI will remain quite simple and stupid.

I think once the GUI runs we can start to implement the necessary backend.
The logic that manages DSP modules networks and then at a later stage
the code that turns the DSP network in a C file that can be compiled into
a .so file that runs the actual DSP stuff.

I'm using Qt and will post a few screenshots for commenting in a few weeks.
At least we will have some code and stuff to play with.
The Qt Designer has the nice capability to allow the integration of custom
 made Widgets which can be used to build more complex ones.
That way you can for example make audio in, audio out, midi in,midi out, CV in,
CV out widget which you can use to make new basic building blocks.

Some of the developers (Marek ? ;-) ) do not like Qt that much (because it is
C++ based or because it Qt si GPL and not LGPL like gtk) but that is not a
problem. GUIs can be implemented by using any toolkit (even curses etc) since the
 engine it totally decoupled from the GUI.
Personally I like Qt very much because I think GUIs can be implemented easier
 in an object oriented language rather than in C plus Qt classes are IMHO
 much cleaner (and easier to use) than Gtk/gtkmm ones.
It is just a personal taste so if at a later stage someone wants to implement
a gtk based GUI feel free to do so. The engine just does not care what kind
 of GUI drives it.

Returning to the sample importer modules: as said before it would be nice
to support the AKAI (via libakai) and GIG formats.
GIG is a bit more tricky since we need to decode the GIG specific chunks.
Ruben Van Royen has done some good stuff some ago (Paul K. and Marek do have
 Rubens header files) but it is still not complete.
So one task that it open to some of you developers (the ones that do have
gigasampler) is to continue that stuff (contact Paul K. or Marek for more infos).
So it would be cool if you could produce a small and lean
libgig that does something like libakai does: parse and read GIG files, decode
the various chunks (envelope data, filters, looping data, MIDI keymaps) etc.
While it is not a really hard task, it is not very easy either.
You need a running gigasampler, some sample libraries. Decode data, change
parameters, see what changes in the data chunks on the GIG file etc.
Not to mention that you need a copy of the DLS2 specs (since GIG is based on
DLS2) which are not publicy available on the net. (but some on the list like
Paul K seem to have a copy so just ask him how to obtain one).

While I would technically able to do such stuff I'd rather prefer to focus on
building an efficient low level engine so it would be handy if some of you could
 implement the GIG importing lib.
Any volounteers ?
Such a lib would not only benefit linuxsampler but other OSS projects too.
(sample editors, softsamplers etc).

Ok shutting up now ;-)
I'd like you guys to comment on the various issues (if my reasoning is flawed,
what you would do in different ways etc).

cheers,
Benno
http://linuxsampler.sourceforge.net

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

Thread: [Linuxsampler-devel] Linuxsampler status,thoughts etc (long)

linuxsampler-devel