Re: SoundFont/DLS2/Gig (was Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity)

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

Scrive Josh Green <jg...@us...>:

> Yep, I'm here :) 

Hi Josh !
Pressure is mounting on you, we will have soon a fully working
streaming capable sampler and I guess it will not take much time
for user begin asking for an editor that can edit and create
 GIG file and other streamable sampling libraries.
Be prepared :-)

> When comparing GigaSampler versus SoundFont versus
> DLS2, I don't think there is anything in particular that would make
> GigaSampler more professional than these other formats, except for a few
> key points: streaming of samples and > 16 bit audio.

I would say only streaming and the articulation via MIDI controller that permits
to and espressive playing of these instruments.
Perhaps DLS2 supports >16bit but currently the .GIG format does not, or at least
the gigastudio does not support it.
This is one of the reasons why both sample library producers and users are
looking at the competition (Steinberg Halion and NI Kontakt) because they
support 24bit. Those samplers, AFAIK use a sample format that is easier to
 deal with (especially when editing the single waves): AFAIK it's basically
an XML file that contains the program/patch data and a bunch of .WAV files.
Such a format is certainly easier to handle in swami too because you have
not to diassemble and reassemble those giant monolithic files.
At a later stage we will try to add support for those sample formats too in
LS. While not being yet fully modular, LS is modular enough to allow
one single engine deal with multiple formats thanks to C++ which permits
you to derive subclasses, eg Voice:: be Voice::gig or Voice::akai.
When loading foreign sample formats we do not "convert" them to a new, 
one-size-fits-all format but load and play them using native loading and
playback routines. This ensures faithful playback of those formats.


> There is no reason
> why streaming of samples couldn't be implemented with these other
> formats, though. 

Indeed SF2 could be streamed too, but keep in mind that some weird
 stuff like backwards looping etc make this task very hard or unviable.
The loader decide whether streaming or not the sample on a case to case basis
(eg if no problematic SF2 stuff like backwards looping etc is used then stream,
 otherwise keep it in RAM).

I've heard that fluidsynth has a good SF2 engine so if you folks want
future SF2 support in LS then try to persuade Peter Hanappe to port
the SF2 engine to LS (I would say it would be too early now since the
basic architecture of LS has not stabilized yet, perhaps in a few months).


> In the case of DLS2, its a really flexible format
> (heck, GigaSampler used it, or rather trashed it in my opinion, would
> have been nice if they had some sort of signature in the header). I
> think DLS2/SF2 has more flexibility in some areas than GigaSampler
> (particularly in the area of modulation, and extent of control values,
> GigaSampler has rather restricted parameter ranges, at least from what I
> have seen).

yes the giga did not want to complicate their lives too much so they
left out many stuff from originally contained in DLS2.
But even with this limitations GIG libraries sound great thanks to
the streaming that allows very large sample capacity and expressive playing
 through midi controller articulation.

> DLS2 could theoretically contain any audio format that WAV
> files can store, since the audio is stored as embedded WAV files. Its
> just that the spec says that only 8bit or 16bit audio is defined as
> being part of the standard.

Yes, but I think the future lies in formats like Halion and Kontakt use:
XML for patch/program data plus a bunch of WAV files.
Monolithic files are a mess to deal with while single WAV files allow
for much more finegrained editing.
Ok .... for relatively small files like soundfonts a single file makes sense
but not for multi GByte sample libraries.
From a performance point of view if you stream from a single file or a bunch
of WAV files it makes virtually no difference (even if you open and close
the file at each triggering of the sample, it's very fast I did some benchmarks
and my conclusion is that the performance is exactly the same).

> 
> Thinking of converting SoundFont or DLS2 files to GigaSampler gives me
> the creeps. Doing it for your own purposes might make sense, but
> distributing those GigaSampler files, means that less people can now use
> that instrument patch, since its not an open standard.

Fully agree but being able to read GIG files is very important if you
want that your sampler can make use of a vast pool of professional, 
high quality sample libraries.
GIG is only one among many formats that LS will support.
We can use our own format (probably XML + WAV files) if we want an open,
extensible sample library format. 
But for LS, being able to read GIG files is as important as for OpenOffice 
reading .DOC files.
The keyword is interoperability.
In that sense Christian's libgig is really well done and once he 
gets his articulation stuff in place GIG playback will be excellent.

> Maybe this will
> change in the future, but I haven't quite come to like the GigaSampler
> format yet. Maybe I just haven't worked with it enough. It would be nice
> to see LinuxSampler built in a way that makes it modular enough to use
> other formats easily.

It already is.
Ok, it is still monolithic (the recompiler stuff will come later,
 for now let's focus on good playback of existing sample formats)
but we will have no problems to accomodate
new loaders and engines because the Voice:: classes can be subclassed
to implement the characteristics of the engine associated to a certain
sample format.

> 
> I still envision my own project libInstPatch being usable for supporting
> other formats for GigaSampler. It supports DLS2 and SF2 at this point
> and GigaSampler to some extent and has a Python binding which I just
> added. I've been working a lot lately though, so I haven't had a lot of
> time to put toward these projects. But I hope that changes in the near
> future. It would be nice to collaborate more on some of this stuff. The
> C/C++ issue is probably going to come up again I'm sure, I'll look into
> how hard it would be to add a C++ wrapper to libInstPatch, if that would
> make it more appealing.

Well certainly you and Christian should collaborate more in order to avoid
wheel reinvention etc. Christian's libgig is made for loading GIG files and
exports methods (functions) for both reading patch/program data, articulation
layers etc plus it has functions to cache and read data from disk into
 memory buffers.
The question is, if Christian has already done this excellent lib wouldn't it
be beneficial to use that lib in swami too ?
Yes I know there are the C/C++ issues but I'm more and more convinced
 that C++ is the ideal language for handling sample related data because
samples are made up of many objects and subobjects.

Josh you could probably argue that LS should use libInstPatch.
Well I haven't looked to your stuff you I cannot judge what can be done,
what would be beneficial etc.
But what's for sure is that libgig is 100% optimized for playback it uses
no mutexing and all routines that are called from within the audio thread
are carefully optimized and have guaranteed execution times and being
the lib shipped directly with LS it will ease the dependency problem too.
(at least during the beginning phase, perhaps later it will be better to
make separate libs for each sample format).
I'm noth the author of libgig so I cannot say anything about 
which kind of collaboration could be beneficial between swami and LS.
But even if you Josh make a totally separate GIG editor in swami it would
still be very useful since you can edit GIGs and then load them into LS
for playing. Since only the sample heads are loaded, the loading is 
pretty fast even for very large sample libs.

> 
> Nice to see some activity on this list. Cheers.

I'm looking forward for the day that swami will go hand in hand with
LS and will be able to edit many sample formats that can be played using LS.

cheers,
Benno
http://www.linuxsampler.org


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