|
From: Benno S. <be...@ga...> - 2003-03-24 20:41:24
|
Hello LinuxSampler guys :-) sorry for being that quiet but was a bit overloaded again during the last two few months. I've read all pending mails and I will try to summarize my thoughts about the project and its future and the current status and how we can collaborate in order to maximize parallelism. As far as I can see it, the sampler consists of several sub-projects which are related: 1) instrument loading library 2) sample playback engine for each kind of sample library format which permits real time / sequenced playback and real time modulation of parameters (LFO, filters, ecc) 3) a graphical editor that permits loading (through 1) ),creation and manipulation of instrument libraries. Personally I will focus on 2) since it involves real time stuff, optimized data flow mechanisms, streaming etc. I think swami could solve 1) and 3) as long as it is flexible in providing support for various sample formats. Regarding the engine: some said they do not like C++ and want do to everything in C etc: My take on this is that we should find some good compromise between performance and modularity and flexibility of the engine. My old evo code is written in C++ and IMHO it offered various advantages over a C implementation without any performance degradation. I'm not a heavy-duty C++ programmer thus usually I use only basic C++ features like classes and methods. In the case of a sample player C++ helps you to bind data structures to certain objects (eg voices) without messing around with tons of structures and passing around pointers of structures between various functions. Ringbuffer C++ templates (lock-free FIFOs) proved to work very well in terms of speed (the resulting assembly code is almost optimal) while helping to keep the code clean. When speaking of code cleaness I do not mean only that it is beauty to read but with clean I mean that object oriented design reduces chances that the object itself accesses data that is not meant to be accessed by that object possibly resulting in a program crash or glitch. Some say they cannot program in C++ so they only contribute if the core is written in C. I see this as a bit lame excuse since it is really not that hard to learn what a class and a method is in C++. If as a coder, you are able to write good C apps then I do not see why one should back away from a sample engine written in lightweight C++. As said, I have nothing in contrary to go plain C, but commonsense says me that C++ is the better choice because the sampler project will probably grow over time and OO design helps you to keep the design of the project/engine cleaner. Regarding the audio rendering: My idea was to make sort of modular sampler where you assemble the basic building blocks with the most important module being the sampleplayback module (a RAM and a disk-streaming version). The idea was to assemble modules at source code level so that the compiler can create a very efficient engine which is almost as fast as a handcoded one but provides the flexibility of permitting the creation of instruments in a modular fashion though a GUI, similar as Native Instruments Reaktor and others do. Some on this list say this is overkill for a sampler and that we should start with a hardcoded engine and later switch to a moduler one (just-in-time compiled). I think rather than duplicating the effort it is better to write a very simple modular engine and at a later time enhance its capabilities. My idea was to start with a RAM sampleplayback module that can do only very simple stuff: - it has a pointer to the sample to be played - it knows how much samples to play and possibily can access to a simple looping list - pitch can be modulated - volume can be modulated In order to create a very simple MIDI-playable instrument along with the ram sampleplayer, an instrument loading library is needed. (loads samples and patches in RAM and exports pointers to samples and parameters) another basic module we need to implement is a MIDI input module that maps incoming MIDI data (MIDI ins or alsa sequencer) to instruments which in turn point to samples in memory and modulation data that can be used to drive the RAM sampleplayback module along with some modulators (volume modulator for creating envelopes and pitch modulator for creating vibratos etc). I think this would costitute a nice starting point for building a full fledged sampler which accepts multiple formats and engines. I'm not 100% but in my opinion it would be wise to associate a playback engine o each samplelibrary format. Eg the GIG engine plays GIG files, the AKAI engine plays AKAI samples. I do not believe that the "one size fits all" model always work. As Peter Hanappe pointed out it is better Fluid tries to specialize on playing SoundFont samples as good as possible rather than trying to become the allround sampler that can play everything. I think the best way to make LinuxSampler a sampler that can reproduce various formats is to make it modular as described above. Once a handful of basic modules are implemented, I think it will be quite easy to add new engines since the goal is basically of being able to assemble new engines using a graphical editor where you wire toghether basic building blocks. If a new engine needs features that are not covered by the available modules, fire up your editor, code the module, and then get back to the GUI and complete the building of the instrument engine you had in mind. Do you agree of going down that road or should we take other paths ? I'm currently writing a multichannel sample playback engine (not instruments but sounds and music) for doing ambient music and noise in a museum room. I use a Linux PC with two Delta cards (8+8 outs) under ALSA. This is not a big project but LinuxSampler will profit from this since I will get familiar with multichannel audio hardware which should be supported by professional apps. (as LinuxSampler should be) Josh: I added you to the project admins (full access to everything) on the project page of LinuxSampler since I assume you will be the main contributor to the sample library handling for linux sampler. Regarding the GIG format docs (I assume Paul Kellett sent you Ruben's header files), how about posting them on the LinuxSampler site (you can now upload stuff yourself) so that others can see the structure of the chunks too ? In the next days I will explain my ideas about volume and pitch modulators and how to build modulation networks. To eliminate some confusion: there are currently two codebases for linuxsampler: one is evo which is basically a proof-of-concept code of a very rudimentary disk based sampler and the other is the code on CVS uploaded by Juan L. which is based on the legasynth codebase. I regard both apps only as proof of concept applications and I suppose the real linuxsampler codebase will probably be built from scratch especially if we go the modular-recompiler way. As said the project lacks a bit of organization right now since our goals are not well defined yet but I think over time things will get better. Anyway I'd like to discuss with you guys which route to go for building the sampler's engine. I know some are getting impatient while other may think this will become another dead project, but I think there are just too many talented folks on this list to let such a cool project die off. Yes, we all have daytime jobs so sometimes the project's advance will slow down a bit but hey, that's life in the open source domain. As long as there will be interested and enthusiastic people partecipating I do not fear that the project will die. Linux and powerful GNU software was not built in a day and I'm confident too that through collaborative work and discussion linuxsampler will some day deliver the funcionality we dreamed of for long time. (argh too much rethoric, back to code :-) ) PS: Welcome to the ML to the Kurzweil guy too :-) waiting for your feedback guys. cheers, Benno http://linuxsampler.sourceforge.net ------------------------------------------------- This mail sent through http://www.gardena.net |