Christian Schoenebeck wrote:
>Es geschah am Sonntag, 8. August 2004 11:30 als Pieter Palmers schrieb:
>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
>>(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.
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'.
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
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.
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.
>>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:
>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.
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.
>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
I don't quite get what you're saying, but I'll look into the code and
probably understand this better.
>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?
I don't have a clue. Maybe when my idea of the new engine gets a little
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.
| Ir. Pieter Palmers |
| ESAT-MICAS Research Assistant |
| Departement Elektrotechniek, ESAT-MICAS |
| Faculteit toegepaste wetenschappen, K.U. Leuven |
| Kasteelpark Arenberg 10 |
| B-3001 Leuven-Heverlee, Belgium |
| Tel. : (32) 16 32.10.70 |
| Fax : (32) 16 32.19.75 |
| E-mail : Pieter.Palmers@... |
| Web : http://www.esat.kuleuven.ac.be/micas/People/Pieter_Palmers |