Menu
▾
▴
linuxsampler-devel
|
From: Emiliano . <emi...@ho...> - 2004-07-28 19:38:00
|
Hi, im Emiliano, from argentina, i am new in linux, but i saw that you need help with the GUI. I am a web designer, if you need anything just let me know. (sorry for my inglish) Emiliano From Argentina. _________________________________________________________________ MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/ |
|
From: Mark K. <mk...@co...> - 2004-07-28 19:58:35
|
Emiliano . wrote: > Hi, im Emiliano, from argentina, i am new in linux, but i saw that you > need help with the GUI. I am a web designer, if you need anything just > let me know. > > (sorry for my inglish) > > Emiliano > >> From Argentina. > Welcome! Please never be sorry for your English around here! You've already shown more ability than I can in any other language. It would be fun to list the native languages of all the participants. I don't know what the list looks like, but I'm pretty sure the 3 main developers are German, Italian and Portugese. I have wondered what Vladimir's native language was, but only because of his name. (You there Vladimir? Senkov is Russian or somethign else?) Cheers, Mark |
|
From: Pieter P. <pi...@jo...> - 2004-08-08 09:15:48
|
Hi all, I've started writing an engine for linuxsampler for more 'sampler-oriented' work, a sampler in this sense being a device that plays back (recorded) samples. The base for it is (of course) the gig engine, but I need some features that aren't provided in the gig format (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... 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. 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. Greets, Pieter |
|
From: Christian S. <sch...@so...> - 2004-08-14 09:14:18
|
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 |
|
From: Vladimir S. <ha...@so...> - 2004-08-16 14:39:50
|
Christian Schoenebeck wrote: >Hi and sorry for the late response, I just came back from holidays while >Vladimir is still enjoying it it seems. > > > No, i'm actually back for a few days now. I'm just keeping quiet for the time being :) Regards, Vladimir. |
|
From: Pieter P. <pi...@jo...> - 2004-08-18 08:29:42
|
Christian Schoenebeck wrote: >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. > > 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 presume). 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: > >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. >> > 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 >C++ IMO. > 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 less blurry... 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. Greets, Pieter -- *---------------------------------------------------------------------* | 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 : Pie...@es... | | Web : http://www.esat.kuleuven.ac.be/micas/People/Pieter_Palmers | *---------------------------------------------------------------------* |
|
From: Christian S. <sch...@so...> - 2004-08-18 09:54:11
|
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 |
Thanks for helping keep SourceForge clean.
X