Menu
▾
▴
linuxsampler-devel
|
From: Matt F. <fl...@Ma...> - 2004-11-06 04:39:33
|
Hello, As I mentioned before, I am going to support this project by including it in the Debian distribution. I would like to ask whats with the many different libraries and interface which are all packaged independently ... I understand that qsampler is a front end for linuxsampler, but then what is 'liblscp' ? Also how then does this all tie in with libgig ? thanks Matt -- http://www.flatmax.org WSOLA TimeScale Audio Mod : http://mffmtimescale.sourceforge.net/ FFTw C++ : http://mffmfftwrapper.sourceforge.net/ Vector Bass : http://mffmvectorbass.sourceforge.net/ Multimedia Time Code : http://mffmtimecode.sourceforge.net/ |
|
From: Christian S. <sch...@so...> - 2004-11-06 12:39:37
|
Es geschah am Samstag 06 November 2004 05:39 als Matt Flax schrieb: > Hello, Hi Matt! > As I mentioned before, I am going to support this project by including > it in the Debian distribution. > > I would like to ask whats with the many different libraries and > interface which are all packaged independently ... > I understand that qsampler is a front end for linuxsampler, but then > what is 'liblscp' ? liblscp is a pure C library which wraps the LinuxSampler Control Protocol (http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html). At the beginning liblscp was designed for client as well as for server side, but actually it's now only used for the client side, thus LinuxSampler doesn't has a dependency to liblscp. qsampler is a graphical frontend to LinuxSampler (based on the Qt library) which uses liblscp to communicate with LinuxSampler, so liblscp already needs to be installed in order to compile or use qsampler. libgig is a C++ file loader for Gigasampler files. LinuxSampler of course uses libgig to load .gig files, but at the moment, libgig is statically included into LinuxSampler, but I planned to remove libgig from LS's sources and instead link libgig dynamically into LS. So LS will have a dependency to libgig soon. But as I told you, LinuxSampler is not yet ready for a serious release. We have to fix a disk streaming bug and fix an efficiency issue in the core synthesis algorithm, otherwise LS will not be capable to render a sufficient amount of voices. Let me know if you have further questions! CU Christian |
|
From: Matt F. <fl...@Ma...> - 2004-11-07 10:09:25
|
Hi again, OK - that information should round it up for me ! In my opinion, it doesn't matter whether it is betaware ... it is more important to let people know of the existance of this project and try to snow ball momentum ... with more hands on deck, the more support you will receive. Regarding the synthesis engine efficiency, perhaps I can help ? Can you pinpoint some documentation or the source code which encapsulates the slow algorithm ? Regarding the disk streaming bug, I guess you don't know exactly where this bug is or you would have solved the problem ... any written description of what that bug is ? Matt On Sat, Nov 06, 2004 at 01:42:11PM +0100, Christian Schoenebeck wrote: > Es geschah am Samstag 06 November 2004 05:39 als Matt Flax schrieb: > > Hello, > > Hi Matt! > > > As I mentioned before, I am going to support this project by including > > it in the Debian distribution. > > > > I would like to ask whats with the many different libraries and > > interface which are all packaged independently ... > > I understand that qsampler is a front end for linuxsampler, but then > > what is 'liblscp' ? > > liblscp is a pure C library which wraps the LinuxSampler Control Protocol > (http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html). At the > beginning liblscp was designed for client as well as for server side, but > actually it's now only used for the client side, thus LinuxSampler doesn't > has a dependency to liblscp. > > qsampler is a graphical frontend to LinuxSampler (based on the Qt library) > which uses liblscp to communicate with LinuxSampler, so liblscp already needs > to be installed in order to compile or use qsampler. > > libgig is a C++ file loader for Gigasampler files. LinuxSampler of course uses > libgig to load .gig files, but at the moment, libgig is statically included > into LinuxSampler, but I planned to remove libgig from LS's sources and > instead link libgig dynamically into LS. So LS will have a dependency to > libgig soon. > > But as I told you, LinuxSampler is not yet ready for a serious release. We > have to fix a disk streaming bug and fix an efficiency issue in the core > synthesis algorithm, otherwise LS will not be capable to render a sufficient > amount of voices. > > Let me know if you have further questions! > > CU > Christian -- http://www.flatmax.org WSOLA TimeScale Audio Mod : http://mffmtimescale.sourceforge.net/ FFTw C++ : http://mffmfftwrapper.sourceforge.net/ Vector Bass : http://mffmvectorbass.sourceforge.net/ Multimedia Time Code : http://mffmtimecode.sourceforge.net/ |
|
From: Christian S. <sch...@so...> - 2004-11-07 14:05:43
|
Es geschah am Sonntag 07 November 2004 11:09 als Matt Flax schrieb: > Hi again, Hi! > OK - that information should round it up for me ! > > In my opinion, it doesn't matter whether it is betaware ... it is more > important to let people know of the existance of this project and try to > snow ball momentum ... with more hands on deck, the more support you > will receive. I just want to avoid prejudices. Again, it won't take long til we have fixed those two issues, so I think it's worth waiting for it. > Regarding the synthesis engine efficiency, perhaps I can help ? > Can you pinpoint some documentation or the source code which > encapsulates the slow algorithm ? You'll see the problem in the Voice class, where the core synthesis is performed. I'm already on it. I wrote together with Vladimir MMX+SSE(1) Assembly Optimizations (the capability for MMX, SSE is detected at runtime), I also improved efficiency in looping and I'll fix other obvious efficiency issues like using the filter only if it's really needed and using the resampling algorithm only it's really needed. Hope to have this done in the next days for commiting. > Regarding the disk streaming bug, I guess you don't know exactly where > this bug is or you would have solved the problem ... any written > description of what that bug is ? Yeah, as we're currently more working on the efficiency, we have not yet looked deeply for the disk streaming bug. You'll face it when you have a big amount of voices which will lead to unavailable disk streams. But maybe this is linked with the bad efficiency, so that's why I decided to do these improvements first. Maybe if you have time to investigate, let us know if you find the reason for the disk streaming bug! CU Christian |
Thanks for helping keep SourceForge clean.
X