Re: [Linuxsampler-devel] Dynamic Engine Loader

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

Es geschah am Sonntag, 8. August 2004 11:30 als Pieter Palmers schrieb:
> Hi all,

Hi and sorry for the late response, I just came back from holidays while 
Vladimir is still enjoying it it seems.

> I've started writing an engine for linuxsampler for more

Great!

> (like multiple loop points). The gig engine is also more instrument
> oriented, while this engine should be more oriented towards the drumloop
> type of sampling. And there is currently no gig format file editor for
> linux that I know of, so...

Right, we discussed adding the possibility to edit or create .gig files, but 
we ended that an own format would be a better idea.

> Anyway, I was wondering if there are plans for supporting the dynamic
> loading of the engines (i.e. like with ladspa plugins). I inserted my
> engine into the linuxsampler code tree, and I have the impression that
> this feature is intended.

Yes, dynamic engine loading is planned of course. This should be done via the 
"LOAD ENGINE" LSCP command:

http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#rfc.section.5.4.2

But at the moment, as we only have one engine yet, we only simply check if the 
engine name is either "gig" or "GigEngine" when the "LOAD ENGINE" command was 
issued (see src/network/lscpserver.cpp line 448 et seqq.).

> I would like to implement a dynamic engine loader, but I was wondering
> if there are already some thoughts on how this should be done.

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.
Anyway... implementing dynamic loading of engines can be almost identically 
done the same as it's already done for the audio and MIDI drivers. There's 
only one issue: for loading the drivers we also introduced a some how complex 
system of dynamic driver parameters. That way the GUI frontends don't have to 
know which drivers are implemented, what parameters these drivers support or 
need, what these parameters do, etc.
For loading sampler engines I think we could simply drop that dynamic 
parameters approach. Or do you think there will be engines in future which 
could require special parameters for loading the engine?

CU
Christian