|
From: Benno S. <be...@ga...> - 2003-07-20 16:29:15
|
Hello, sorry for being that quiet during the last weeks, work overload you know .. Anyway during the last days a few of us (me, Marek, Juan L. and others) discussed about the possible roadmaps for linuxsampler. While we haven't produced useful code lately, some of us came up with nice ideas. Some say linuxsampler will never happen, or that some do "voice" too much, but hey I think passionate discussion sparks interest and creativity. Plus good things take time to develops and unfortunately we are not in the fortunate situation like Paul D. where we can work full time on our favorite OSS project. That said, personally I'm still convinced that it should become a "modular sampler" because I do not like hardcoded engines that much since they limit the creativity of the user. Obviously should allow importing multiple sampleformats but in this regard there is a opinion split: some (like me) say we should write separate sample loading modules for each format (gig, akai etc) that store the samples in datastructures using the native representation, while others say that it would be better to create some powerful (and if possible extensible) internal format that can accomodate most common formats in order to simplify things. I'm not sure about that and if we really write a modular sampler (where you can assemble the various engines using a GUI editor along the lines of NI Reaktor) if in case of using "native sampleformat loaders" the code duplication would really be that high as some state (Marek). Of course it would be cool to use the GIG engine to play AKAI samples and viceversa. But when using native loaders you could alway write a GIG to AKAI converter module that reads the GIG metadata that the GIG loader put into mem and converts them to the AKAI datastuctures. Of course the "universal internal format" has the advantage that you can convert form any input format to any output format by writing a converter module that can convert from/to the universal to/from the specific format. That way if you have N formats you only need to write N converter modules instead of N*(N-1) if you are using only native formats. I back the native format loader solution since you can tune the engine exactly to work hand in hand with that format instead of going through the intermediate universal format. This mean you can tune the GIG engine to work exactly with GIG specific enveloping data, filters, looping etc. Same applies to all other formats. Of course one would want to use the GIG engine to play AKAI samples but we can write a converter module (that is probably quite simple since AKAI's sample engine is simpler than GIG's one). But I think the N*(N-1) n. of converter modules equation does not apply here since I think it is unlikely to want to play GIGs using the limited AKAI engine. Since we include both engines it makes sense to use the native one. So probably the number of format converter modules is more likely determined by (N of simple formats) *( N of complex formats). Since the N of complex formats (like GIG) is not that high I guess the number of converter modules would still stay quite low but with the benefits of having native loaders and native engines that go hand in hand. Marek would object here but I think using an internal universal format make it hard to avoid conversion losses that makes it hard to achieve faithful playback. Of course many sampleformats share many properties like keymaps, envelopes, filters, looping information etc, but unfortunately often each format uses its own representation where a bijective A<->B converter function does not exist. For example when speaking about envelopes: some formats use simple ADSR models while others allow arbitrary linear or exponential enveloping segments. How to avoid the code duplication in the loaders and engines ? Use the modular approach ! Since the final engines will be compiled using the following approach: module editor -> C source code -> compiled .so file that gets loaded by the sampler the speed will be OK even if we assemble the engines using a Reaktor-like GUI (and it will be very userfriendly and handy to add new custom engines). So basically when we have implemented enough basic building blocks (filters, envelope generators, etc) designing new engines becomes a breeze. Not sure about the loaders (if we could use a GUI editor to compose loaders too). Most sampling formats are based on the RIFF format (GIG, DLS, SF2, WAV etc) so a RIFF parser is needed anyway but the individual modules that interpret the data contained in various RIFF chunks still need be written by hand. But to achieve maximum flexibility instead of writing a monolithic format importer we could write let's say a general RIFF parser and then specialized modules that interpret the various RIFF chunks. That way if we happen to support formats that share some characterisics (eg GIG is nothing more than DLS with some proprietary additions) can can fully reuse the modules. I think using the approaches described above the "code duplication" can be kept really low while the flexibility increases quite. Regarding the GUIs: As you know I support the idea of totally decoupling the engine from the GUI. It improves code quality because you do not mix GUI stuff with engine stuff. Plus if you use a TCP socket you can even run the GUI on a remote machine that can run even another OS than Linux. (eg. assume a Mac OS X frontend box networked with a headless linuxsampler box). As for the module composer form the discussion we had on IRC we seem to agree that the best thing to do would be making a "stupid" GUI which only forward commands to the engine. That way when you wire togheter the basic building blocks in the GUI editor apart from displaying them wired together it does nothing than issuing a connect(module1.out,module2.in) command to the engine which does the appropriate stuff. That way you can even use scripts, commandlines or textual interfaces that can manage and construct audio rendering engines. Regarding the sample importing modules: I think it would be wise to use a bottom up approach thus IMHO it would be better to not use and extend complex monolithic applications that can read/edit samples. Josh is writing LibInstPatch and I think it is a nice lib but I'm unsure if it is the right way to go. I think the only way we can solve the problems that linuxsampler poses is a divide et impera approach. So write many "micro modules" and "wire" them toghether using a GUI. That way you can, as Steve Harris said some time ago, make a good "sampler construction kit". Regarding the code and what to implement first. I admit we haven't done much lately but meanwhile the ideas kept flowing and I think it helps to avoid design errors. Thanks to Sebastien and Christian we now have libakai running on Linux. (libakai is a small lib that reads an parses AKAI sample images). I think this is the right kind of lib for linuxsampler since it is lean, very low level, does not contain a GUI and can easily be embedded into linuxsampler importing modules. So basically we need to figure out which kind of modules we should start implementing. It is not easy to choose where to start since design errors in one module can later affect the design of other modules. So I think it would probably be the best to start with the GUI. A module editor similar to Reaktor where you can assemble basic building blocks. The real DSP network building process will occur within the sampler engine so the GUI will remain quite simple and stupid. I think once the GUI runs we can start to implement the necessary backend. The logic that manages DSP modules networks and then at a later stage the code that turns the DSP network in a C file that can be compiled into a .so file that runs the actual DSP stuff. I'm using Qt and will post a few screenshots for commenting in a few weeks. At least we will have some code and stuff to play with. The Qt Designer has the nice capability to allow the integration of custom made Widgets which can be used to build more complex ones. That way you can for example make audio in, audio out, midi in,midi out, CV in, CV out widget which you can use to make new basic building blocks. Some of the developers (Marek ? ;-) ) do not like Qt that much (because it is C++ based or because it Qt si GPL and not LGPL like gtk) but that is not a problem. GUIs can be implemented by using any toolkit (even curses etc) since the engine it totally decoupled from the GUI. Personally I like Qt very much because I think GUIs can be implemented easier in an object oriented language rather than in C plus Qt classes are IMHO much cleaner (and easier to use) than Gtk/gtkmm ones. It is just a personal taste so if at a later stage someone wants to implement a gtk based GUI feel free to do so. The engine just does not care what kind of GUI drives it. Returning to the sample importer modules: as said before it would be nice to support the AKAI (via libakai) and GIG formats. GIG is a bit more tricky since we need to decode the GIG specific chunks. Ruben Van Royen has done some good stuff some ago (Paul K. and Marek do have Rubens header files) but it is still not complete. So one task that it open to some of you developers (the ones that do have gigasampler) is to continue that stuff (contact Paul K. or Marek for more infos). So it would be cool if you could produce a small and lean libgig that does something like libakai does: parse and read GIG files, decode the various chunks (envelope data, filters, looping data, MIDI keymaps) etc. While it is not a really hard task, it is not very easy either. You need a running gigasampler, some sample libraries. Decode data, change parameters, see what changes in the data chunks on the GIG file etc. Not to mention that you need a copy of the DLS2 specs (since GIG is based on DLS2) which are not publicy available on the net. (but some on the list like Paul K seem to have a copy so just ask him how to obtain one). While I would technically able to do such stuff I'd rather prefer to focus on building an efficient low level engine so it would be handy if some of you could implement the GIG importing lib. Any volounteers ? Such a lib would not only benefit linuxsampler but other OSS projects too. (sample editors, softsamplers etc). Ok shutting up now ;-) I'd like you guys to comment on the various issues (if my reasoning is flawed, what you would do in different ways etc). cheers, Benno http://linuxsampler.sourceforge.net ------------------------------------------------- This mail sent through http://www.gardena.net |