[Linuxsampler-devel] Patch file library

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

Went on a trip for a few days and come back to find my email box full of
discussions about a patch loading library. What follows are details
concerning my libInstPatch library and its design goals.

If you haven't had a look at my API for libInstPatch
(http://swami.sourceforge.net) here is my current plans for it. I am
very curious how well this project could fit in with the LinuxSampler
project (actually I'm also wondering if Swami could become a GUI for it,
since I'm planning on fully objectifying the GUI as well, it is pretty
much already, just not the interface).

- Using GObject, a C based object system (GStreamer uses this). This
gives us an object system with C the lowest common denominator
programming language. GObject also has an easy python binding code
generator that is part of the pygtk package.

- Not attempt to make a unified patch format (sounds like others agree)

- Take advantage of GObject's typed property system for setting
parameters on patches, this provides for a bit of unified API between
patch formats, example of setting parameters on a SoundFont preset in C:

g_object_set (preset,
              "name", "Preset Foo",
              "bank", 0,
              "psetnum", 4,
              NULL);

- Patch formats are broken out into individual GObjects (IPatchSFont,
IPatchSFPreset, IPatchSFInst, IPatchSFZone and IPatchSFSample for
SoundFont banks for example) and organized in a parent/child tree
structure where appropriate.

- Multi-threaded patch objects

- A sample store object that provides for pluggable methods of storing
sample data (RAM, swap file, etc)




I believe this design will provide for a rather flexible patch file
library and other formats can be easily added to it.


Some things to think about:

- My new libInstPatch actually needs a bit of testing and debugging as I
just recently completed the API and have not brought the new development
version of Swami up to date to actually use it.

- Loading/saving API is not flexible enough (hasn't been re-written yet
for libInstPatch which is now no longer SoundFont centric)

- How well would the object system libInstPatch uses fit with a real
time synthesizer? What kind of system could be used to associate
synthesizer time critical data with patch objects?

- Multi-threaded objects: while it makes server/multiple client
architectures possible it also adds excess locking requirements etc. For
example: all object lists must be locked before iterating over them in
libInstPatch, if not using the user iterator routines which make a copy
of object lists.

- I decided not to deal with the converting of audio data with
libInstPatch although I'm sure this will be necessary as more formats
are added. Perhaps a sample library like libsndfile could be used for
such things, I know the author is interested in this stuff.

My library has pretty much been designed around the idea of the most
flexibility in the patch file realm and act like a patch server that can
have multiple clients editing the same patches (think distributed patch
editing sessions, between programs or computers). I have not really
thought about the real time realm required by soft synths. It may be
that my design cannot incorporate whats required by LinuxSampler, but I
would really like it to. This project sounds really exciting. I'm just
hoping I can keep up with the massive amount of email these discussions
involve (and actually get some programming done at the same time :)

Cheers.
	Josh Green