Re: [Linuxsampler-devel] Dynamic Engine Loader

[Christian S. <sch...@so...>]

Es geschah am Mittwoch, 18. August 2004 10:45 als Pieter Palmers schrieb:
> Any ideas on this 'own' file format? I've been thinking about it and
> probably the nicest I've seen is the approach of Hydrogen: simply tar-gz
> the (wav) samples and include an XML file to describe the 'soundbank'.

XML: vote++
tar-gz: not sure about that, I would probably prefer FLAC compression for 
lossless audio formats (.wav, .aiff, etc.) and for already compressed audio 
file formats you don't need compression anyway (e.g. mp3).

> Any ideas on what the engine should support? (i.e. wish list)
> I'm starting with a simple WAV player that supports multiple loop
> points, and then I'll add some filters (copy-paste from the GIG engine I
> presume).

Don't aim too high. Having the gig engine features in our own engine is a good 
start. If that works we replace the synthesis parts one by one by more up to 
date features.

> It might be a good idea to generalise some of the 'helper' classes that
> are used by the GIG engine. The DiskThread for instance: I also need
> disk streaming if the sample is too big. Since the current diskstreamer
> is in the gig namespace, I have to copy it into my own namespace. Well,
> actually I don't really need to do that, but not doing so would
> introduce a depency to the gig engine.

Yeah, many parts of the gig engine should be extracted and generalized to base 
classes. We haven't done it yet, because for the first upcoming release, 
solely the gig engine is planned to be included.

> It might be better to have some helper classes (filters, ADSR,
> DiskThread, ...) separate from the engines. This way the engine mainly
> handles the file format and engine specifics. It would surely make it
> easier to implement new engines.

Actually the filters are already generalized (see 
src/engines/common/BiquadFilter.h). For the gig Engine we just compose some 
of these filters with custom parameters, so it (hopefully) sounds like the 
original Gigasampler filters.

Btw, all generalized engine classes (means all classes which are used to 
compose an engine but are not specific to one particular engine) should be 
placed into src/engines/common. E.g. the LFO class is already there as well.

> I was more thinking of engines as .lo libraries kind of dynamic loading.
> If I'm not mistaking, the approach you propose compiles all
> drivers/engines into the executable.

Not sure if you know it already; we planned dynamic engine recompilation, so 
the user can customize his own engines and compile it on the fly via LSCP 
(using a convenient GUI for example), so for that stage we need what you 
propose. But for the time being I think it's sufficient when we start to 
statically compile all engines into our library.

> >We already load audio output drivers and MIDI input drivers dynamically
> > (see src/network/lscpserver.cpp line 358 / 374 et seqq.). We use factory
> > classes for this (src/drivers/audio/AudioOutputDeviceFactory.cpp and
> >src/drivers/midi/MidiInputDeviceFactory.cpp) which resolve the given
> > strings and create an instance of the desired class. Unfortunately this
> > can't be solved as elegant in C++ as it can be in other languages like
> > Java (Java reflections API) so we're forced to use preprocessor macros in
> > the driver classes, so the driver classes actually register themselves
> > the factory. This is definitely one big feature that should be added in a
> > future standard of C++ IMO.
>
> I don't quite get what you're saying, but I'll look into the code and
> probably understand this better.

That code just does this:

	AudioOutputDevice* pDevice;
	...
	if (desired_driver == "Alsa") pDevice =
	    new AudioOutputDeviceAlsa(driver_parameters);
	else if (desired_driver == ...
	...

Just in a more elegant way and a bit more complex, because the driver 
parameters (e.g. to create a device) are dynamically as well.

> What I'm missing in the LSCP draft is a way to send generalized
> configuration to the sampler engine. What I mean with 'generalized' is a
> send/receive mechanism that allows a (G)UI to configure some engine
> specific parameters. This probably is not nescessary for the GIG engine,
> but I think it should be available. It could be solved by using MIDI
> sysex stuff, but I dislike that. In my opinion the MIDI communication
> should be strictly limited to the real-time events, whilst the LSCP
> communication serves all non-realtime UI to the sampler (and engine). In
> an analogy with a hardware sampler, I see LSCP as the "front-panel" to
> "sampler backend" communciation mechanism, which should be separate from
> the MIDI communication. From a practical point of view: the MIDI stuff
> is real-time, and the LSCP stuff is non-realtime. Those shouldn't be mixed.

Exactly, that's how it was planned; LSCP is not meant for realtime operation. 
What engine parameters exactly do you have in mind?

CU
Christian