Swami as a LinuxSampler patch editor front end (was Re: [Linuxsampler-devel] RAM sampler module proposal)

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

On Thu, 2002-11-07 at 16:42, Benno Senoner wrote:
> On Fri, 2002-11-08 at 01:14, Josh Green wrote:
> 
> Hi Josh,
> I do agree on all your points.
> Indeed Fluid could provide a solid base for SoundFont playback and it
> would be cool if we could collaborate with the Fluid developers to 
> produce something that becomes really good and powerful.
> 
> Regarding an instrument editor, we strongly need such a beast and you
> are probably the most expert in that field. 
> I'm grateful that you collaborate on the project since without
> a good editor it will be hard to create new patches without resorting
> to windows software.
> I hope that swami becomes really flexible and that in near future it
> will let you build and edit  DLS2 , GIG and other instrument types.
> 
> Of course swami needs a powerful playback engine in order to provide
>  what you hear is what you get feel.
> This means that ideally the instrument's editor and playback engine
>  should go hand in hand so that the editor can match the engine's 
> capabilities and viceversa.
> 

I have been designing Swami with exactly this type of modularity in
mind. I'm looking forward to working with the LinuxSampler project :) 

If both were based on the same patch manipulation library (such as
libInstPatch) this might be easily accomplished. I think the issue of
flexible multi-threaded patch objects versus real time access of
parameters is going to need some thought. Perhaps a parameter cache
could be used that the synth engine can access directly and gets
synchronized to the patch object system. There would most likely be a
lot of internal data that the synth itself needs for primitive synth
constructs (like envelops, LFOs, etc) which are really only needed for
active voices and could be allocated from a memory pool (no malloc).

Do you think it would be okay for LinuxSampler to depend on
libInstPatch? This would introduce the following dependencies:

libInstPatch
GObject 2.0/glib 2.0

Jack depends on glib (although I don't think it requires 2.0).
glib/gobject are required by GTK+ and are available on win32 platforms
as well as OS-X. glib has a lot of other neat features that would
probably benefit the development of LinuxSampler (threading; data types
like linked lists, trees, hashes; memory pool functions, etc).

The alternative route is to do something like what FluidSynth does.
It is currently loaded into Swami as a plugin and there is an SFLoader
API in Fluid that allows me to load patch information and data on demand
as well as update various generator parameters in real time. This would
seem to complicate matters though in the case of multiple patch formats,
etc. I think using the same patch library would make the most sense.

> cheers,
> Benno
> 

Cheers.
	Josh Green

P.S. If anyone is interested in helping out with Swami
(http://swami.sourceforge.net) directly, I could really use more
developers. The code base is C using GObject and the GUI uses GTK+, the
API docs for both those libraries can be found at http://www.gtk.org.