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

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

On Wed, 2003-10-29 at 03:19, be...@ga... wrote:
> 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 :-)
> 

Yeah, I'm hoping for the best, but things always take longer than I plan
and I've only got ten fingers to push those buttons and my mind is kind
of slow :) One of these days I'll unveil Swami 1.0, that will be the
day, since it consists of over a years worth of un-praised work. It
would be nice to feel like I'm back in the Linux Audio loop again.

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

I often wonder if DLS2/SF2 is more flexible in that area. Since both of
them use the idea of a connection blocks which can have 2 sources with a
polarity and mapping function, these inputs can be either MIDI
controllers or even things like envelopes in the case of DLS2. There is
a bit of discrepancy between whats "supported" for the DLS2 spec, and
whats allowed to be put in a DLS2 file, though.

> Perhaps DLS2 supports >16bit but currently the .GIG format does not, or at least
> the gigastudio does not support it.

The file format itself is capable, but it is not part of the spec.

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

Those formats sound really cool. I'd like to look into them. Using an
XML like format would make them much easier to decipher too. That does
sound like the way of future patches.

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

Right, OO programming :) C does that as well (with the help of GObject),
but its not nearly as clean as C++. Someday I may regret not just using
C++, but I still like the thought of using lowest common denominator
code, and the possibility of becoming part of the GStreamer project at
some point (its based on the same archaic technology :)

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

No backwards looping in SF2. Only loop and "loop till release then play
rest of sample".

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

It is a nice SoundFont engine and I use it regularly for my small amount
of music experiments. Its still lacking a few polishing touches, and
unfortunately all of the developers are rather busy right now.

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


Yeah, I wasn't saying you shouldn't support them :)


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

The more I think about it, the more I realize I would just like an
interface to LinuxSampler. I don't really want to try and force anything
on anyone else, and I have gotten very little feedback on my stuff as it
is. I would much rather just write my own voice handling for
LinuxSampler (maybe something along the lines of the API that FluidSynth
provides, creating voice instances, etc). I've already got GigaSampler
support, but I just need to get a better understanding of the math
behind the parameters, for doing conversions and the like. I'm sure much
of that could be had from the work Christian and others are doing.

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

Nahh.. I don't think it should rely on libInstPatch. You guys seem
pretty hard core C++ and while I may end up putting together a C++
binding for libInstPatch, I don't want to pretend I have the time for
such things at this point.

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

The way I see it there are trade offs. You either have fast lock free
access to patch information or full multi-thread enabled editing of
patch objects. I kind of feel both are necessary for a professional soft
synth editor environment. libInstPatch is becoming analogous to a
multi-thread capable instrument patch database. I see the synth process
as having its own set of parameters that are synchronized to the patch
database on noteon or patch selection. Real time control is then routed
directly to the synth, with perhaps a cue for updating the patch
database (when doing real time editing).

When thinking about an interface to LinuxSampler that would provide a
way to use arbitrary formats, I see an API for instantiating voices.
Most patch formats I have seen can be collapsed into a simple list of
voices with synthesis parameters. I'm currently working on creating a
voice cache system, that takes patch formats in Swami and converts them
to a list of voices with SoundFont oriented parameters (for the sake of
using FluidSynth to play other formats). This is actually already in
place but needs to be overhauled for greater performance. The caching
would occur at program selection or when a program is edited. A similar
system could probably be extended to LinuxSampler, but perhaps with more
generic parameters and not so patch specific as SoundFont units
(although they are fairly generic).

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

I agree, there are lots of ways for LinuxSampler and Swami to interface.

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

That goes for me too :)

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

Sorry for the big email! This list has really been getting a work out
lately.
	Josh