linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

[Linuxsampler-devel] [PATCH] libgig version 0.7.2

[Rui N. C. <rn...@rn...>]

Hi Chris, everyone,

(I'm re-posting this as I didn't got anything back from linuxsampler-devel
list to date; just lag or has it gone the drain of some spam blackhole?
sorry for th einconvenience)


While integrating libgig support into QSampler I've detected a minor quirk
in the "gig.h" header file, that has been solved by simply inserting a
oneliner: a forward declaration of gig::Region class.

Apparentely, a compiler error was just exposed if you include "gig.h"
under a Qt C++ project (as is qsampler), and was all about "Region" being
an already typedef'd symbol.

This all comes to the attached patch, which also applies for correcting
some other minor documentation install problems (man pages and doxygen
docs).

If nothing or no one goes against this, I'll be ready to commit into CVS
soon.

Oh, this patch also applies for bumping up the libgig package version to
0.7.2. Please check it out carefully, and tell me if you agree.

Hope so.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] [PATCH] libgig version 0.7.2 (?)

[Rui N. C. <rn...@rn...>]

Hi Chris,

While integrating libgig support into QSampler I've detected a minor quirk
in the "gig.h" header file, that has been solved by simply inserting a
oneliner: a forward declaration of gig::Region class.

Apparentely, a compiler error was just exposed if you include "gig.h"
under a Qt C++ project (as is qsampler), and was all about "Region" being
an already typedef'd symbol.

This all comes to the attached patch, which also applies for correcting
some other minor documentation install problems (man pages and doxygen
docs).

If nothing or no one goes against this, I'll be ready to commit into CVS
soon.

Oh, this patch also applies for bumping up the libgig package version to
0.7.2. Please check it out carefully, and tell me if you agree.

Hope so.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] [PATCH] fine tuning of the velocity curves

[Mark K. <mar...@gm...>]

Andreas,
   Welcome! Great work!


On Sun, 21 Nov 2004 11:57:57 +0100, Andreas Persson
<and...@lk...> wrote:
<SNIP>
> 
> Yes, I did a lot of measurements of GS 2.5. Input was a minimal gig with
> a sawtooth sample and a MIDI sequence of the same note repeated with all
> 127 different velocities. Output was a wav, which I run through a small
> program to get data for a velocity x volume graph. I did this for all 15
> curves with scaling set to 20, and for some curves I also varied the
> scaling parameter.

Good stuff.
<SNIP>
> 
> Uh-oh, It seems as somebody else than me has spent a lot of time and
> effort on this, I didn't mean to step on any toes... 

No! No! No! Not stepping on my toes at all! I got involved early on
and did what I could to help out. I'm not a programmer, just a
composer/recordist that uses GSt 2.5 and would like to help with LS.
That said, we all add value, both you and I. I think you've gone
further than I did which is great, but even if what your work did was
duplicate and verify what I did earlier, that is helpful in making
sure we really understand how GSt works.

I truly welcome your contribution.

> 
> > Has somebody already tested Andreas' patch? Do the new curves feel more
> > accurate? Mark perhaps?

I have not used LS in quite awhile now. I moved in May and for months
much of the studio was in boxes. It's now getting set up again so
maybe I can find some time. I am retiring my GSt box in favor of
combining GSt onto a much more powerful machine that runs most all of
my Windows-based synths - Acid Pro, Battery, Reaktor Session, and
today (hopefully) GSt. If I have no major issues with GSt loading up
and working along side these other tools then I'll take the Gig
library disk out of the old GSt machine and install it in the new one.
At that point I'll likely be in a better position to do some
comparisons.

With the holiday this week I'll be traveling and won't work on this
until the 1st of December. On the other hand I has (happily and
blessedly) laid off last week and am now jobless. I've decided to not
look for wok until next year so hopefully December can be productive
both the writing music and, if there is some new life here, in the
development and testing of LS.

It's a bit weird to be out of work after 25 years in Silicon Valley. I
have a smile on my face. We'll have to see how long that lasts... ;-)

> 
> Well, I have :). Apart from some artificial tests, the piano feels
> better with the patch. Other than that I have not tested the feel that much.
> 

I'm probably not musical enough to test too much for feel, but I can
do a lot of MIDI based work recording audio from both into Ardour and
seeing what I uncover.

I have recently been considering the purchase of the GS3 upgrade. Has
anyone had a chance to really play with it? I'm really only interested
in the unlimited voice count version.

Cheers,
Mark

Re: [Linuxsampler-devel] [PATCH] fine tuning of the velocity curves

[Andreas P. <and...@lk...>]

Christian Schoenebeck skrev:
> Looks very good! If you have plots of the other two functions as well, please 
> let me know. Just in case you already have, that doesn't mean you have to 
> create them. But it would be nice for the docs to have comparison graphs 
> between our curves and the original ones.

Lots of plots: http://hem.spray.se/andreas56/curves

/Andreas

Re: [Linuxsampler-devel] [PATCH] fine tuning of the velocity curves

[Christian S. <sch...@so...>]

Es geschah am Sonntag 21 November 2004 11:57 als Andreas Persson schrieb:
> > So you actually measured Gigasampler's original velocity curves?
>
> Yes, I did a lot of measurements of GS 2.5. Input was a minimal gig with
> a sawtooth sample and a MIDI sequence of the same note repeated with all
> 127 different velocities. Output was a wav, which I run through a small
> program to get data for a velocity x volume graph. I did this for all 15
> curves with scaling set to 20, and for some curves I also varied the
> scaling parameter.

Very good!

> > Do you think it might be worth to approximate a polynomial function
> > instead of using linear segments? Btw here
>
> When looking at the graphs for the measured nonlinear curves, it seems
> as GS also uses linear segments. For the special curves  I'm not so
> sure, perhaps some of them or some segments of them could be replaced
> with polynomials or perhaps exponential functions, but I doubt it would
> be worth it.

Ok, then we forget about that.

> Uh-oh, It seems as somebody else than me has spent a lot of time and
> effort on this, I didn't mean to step on any toes... I started doing
> this tuning when I noticed that my favorite piano gig was not feeling
> right, It was not audible at all when playing soft. It uses curve type
> nonlinear, range 1 and scaling 0.

Np :), at least for me it wasn't much work, even though you might get that 
impression, but I just fed Maxima with the data from Mark and the curve 
fitting was done in few minutes that way. Fortunately Mark already did those 
time consuming measurements.

> Here's a plot of a measured nonlinear-1-20 curve together with my
> line-segment-approx and the original linuxsampler function:
>
> http://hem.spray.se/andreas56/plotfile.png

Looks very good! If you have plots of the other two functions as well, please 
let me know. Just in case you already have, that doesn't mean you have to 
create them. But it would be nice for the docs to have comparison graphs 
between our curves and the original ones.

> > Has somebody already tested Andreas' patch? Do the new curves feel more
> > accurate? Mark perhaps?
>
> Well, I have :). Apart from some artificial tests, the piano feels
> better with the patch. Other than that I have not tested the feel that
> much.

Ok, I'll apply it today.

Thanks!
Christian

Re: [Linuxsampler-devel] [PATCH] fine tuning of the velocity curves

[Andreas P. <and...@lk...>]

Christian Schoenebeck skrev:
> Es geschah am Samstag 20 November 2004 18:01 als Andreas Persson schrieb:
> 
>>Hello,
> 
> 
> Hi Andreas!
> 
> 
>>This is my first post to this list, and my first attempt to contribute
>>to this impressive project. What I have done is some rather
>>overambitious measuring and fine tuning of the velocity curves.
> 
> 
> So you actually measured Gigasampler's original velocity curves?
> 

Yes, I did a lot of measurements of GS 2.5. Input was a minimal gig with
a sawtooth sample and a MIDI sequence of the same note repeated with all
127 different velocities. Output was a wav, which I run through a small
program to get data for a velocity x volume graph. I did this for all 15
curves with scaling set to 20, and for some curves I also varied the
scaling parameter.

>>The three functions for linear, nonlinear and special are replaced with
>>15 separate curves, approximated with line segments. The scaling
>>parameter is also handled a bit different than before.
> 
> 
> Do you think it might be worth to approximate a polynomial function instead of 
> using linear segments? Btw here

When looking at the graphs for the measured nonlinear curves, it seems
as GS also uses linear segments. For the special curves  I'm not so
sure, perhaps some of them or some segments of them could be replaced
with polynomials or perhaps exponential functions, but I doubt it would
be worth it.

I did try to find functions, I found this site for function fitting to
be great: http://zunzun.com, but I did not found any functions that
could approximate whole curves well in a consistent way.

>  http://www.linuxsampler.org/doc/engines/gig/velocitycurves.pdf
> 
> is a graphical comparison betwenn the original measurement curves made by Mark 
> Knecht and the calculated functions currently in use in LS/libgig - just in 
> case somebody's interested in a graphical comparison of the curves.

Uh-oh, It seems as somebody else than me has spent a lot of time and
effort on this, I didn't mean to step on any toes... I started doing
this tuning when I noticed that my favorite piano gig was not feeling
right, It was not audible at all when playing soft. It uses curve type
nonlinear, range 1 and scaling 0.

Here's a plot of a measured nonlinear-1-20 curve together with my
line-segment-approx and the original linuxsampler function:

http://hem.spray.se/andreas56/plotfile.png

> Has somebody already tested Andreas' patch? Do the new curves feel more 
> accurate? Mark perhaps?

Well, I have :). Apart from some artificial tests, the piano feels
better with the patch. Other than that I have not tested the feel that much.

> CU
> Christian

/Andreas

Re: [Linuxsampler-devel] [PATCH] fine tuning of the velocity curves

[Christian S. <sch...@so...>]

Es geschah am Samstag 20 November 2004 18:01 als Andreas Persson schrieb:
> Hello,

Hi Andreas!

> This is my first post to this list, and my first attempt to contribute
> to this impressive project. What I have done is some rather
> overambitious measuring and fine tuning of the velocity curves.

So you actually measured Gigasampler's original velocity curves?

> The three functions for linear, nonlinear and special are replaced with
> 15 separate curves, approximated with line segments. The scaling
> parameter is also handled a bit different than before.

Do you think it might be worth to approximate a polynomial function instead of 
using linear segments? Btw here

 http://www.linuxsampler.org/doc/engines/gig/velocitycurves.pdf

is a graphical comparison betwenn the original measurement curves made by Mark 
Knecht and the calculated functions currently in use in LS/libgig - just in 
case somebody's interested in a graphical comparison of the curves.

Has somebody already tested Andreas' patch? Do the new curves feel more 
accurate? Mark perhaps?

CU
Christian

[Linuxsampler-devel] [PATCH] fine tuning of the velocity curves

[Andreas P. <and...@lk...>]

Hello,

This is my first post to this list, and my first attempt to contribute 
to this impressive project. What I have done is some rather 
overambitious measuring and fine tuning of the velocity curves.

The three functions for linear, nonlinear and special are replaced with 
15 separate curves, approximated with line segments. The scaling 
parameter is also handled a bit different than before.

/Andreas

[Linuxsampler-devel] QSampler 0.0.4 released!

[Rui N. C. <rn...@rn...>]

Hi,

It's been a long time since last alpha-release. But now it comes the
moment for a fresh and fourth QSampler new one:

    QSampler 0.0.4 is out!

This is the 4th alpha-release of this Qt GUI front-end for LinuxSampler.

There's no new big features thought, only assorted fixes and some internal
structure redesigning. Worthy of notice it's the initial integration with
libgig, as for reading actual instrument names from GigaSampler (.gig)
local files.

Check it out from:

    http://qsampler.sourceforge.net

You may find the standard tarball and some RPMs also under the following
sites:

- Sourceforge.net project page:
    http://sourceforge.net/projects/qsampler/

- My own place, where you'll find all related archives, past and present:
    http://www.rncbc.org/ls/

RPMs are made available for SUSE 9.2, Mandrake 10.1 and Fedora core 1 (all
x86 only). These are the distros I run ready at home, so don't ask for
anything else 'coz it won't make it ;)

VERY IMPORTANT: liblscp-0.2.4 pre-installation is now mandatory, and
libgig-0.7.1 is optional but strongly recommended thought (you'll need it
anyway, if you take the RPM route).

Enjoy.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Debian packaging

[Christian S. <sch...@so...>]

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

Re: [Linuxsampler-devel] Debian packaging

[Matt F. <fl...@Ma...>]

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/

Re: [Linuxsampler-devel] Debian packaging

[Christian S. <sch...@so...>]

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

[Linuxsampler-devel] Debian packaging

[Matt F. <fl...@Ma...>]

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/

Re: [Linuxsampler-devel] No Registered MIDI or audio drivers

[Christian S. <sch...@so...>]

Es geschah am Dienstag 12 Oktober 2004 22:34 als James Klicman schrieb:
> On Tue, Oct 12, 2004 at 08:46:04PM +0200, Christian Schoenebeck wrote:
> > but for backward compatibility we currently allow beside "ALSA" also
> > "Alsa" and beside "JACK" also "Jack" (see src/network/lscpserver.cpp,
> > line 1158).
>
> You might want to double check the compatibility code as 'Alsa' is not
> being recognized:
> GET AVAILABLE_AUDIO_OUTPUT_DRIVERS
> ALSA,JACK
>
> CREATE AUDIO_OUTPUT_DEVICE Alsa CARD='0,0' SAMPLERATE=48000
> ERR:0:There is no audio output driver 'Alsa'.

Right, but we did not need backward compatibility for the CREATE command, 
because this command is quite new anyway. The Qt frontend is still using the 
old, deprecated 'SET CHANNEL MIDI_INPUT_TYPE' and 'SET CHANNEL 
AUDIO_OUTPUT_TYPE' commands instead.

> > Really strange that Alsa and Jack is detected by the configure script but
> > the devices won't register. Unfortunately I can't tell you a sane reason
[snip]
>
> I found the problem. The drivers were not being linked and I really can't
> blame GCC. The only references to the actual drivers are contained within
> the drivers themselves. I patched linuxsampler.cpp to directly reference
> the drivers and things started working as planned.

Usually, the fact that the driver references don't occur outside their own 
files, should not be a problem. There are other applications which do it the 
same way. Btw, which distribution and version are you using?

> --- linuxsampler-cvs20041010/src/linuxsampler.cpp     Fri Oct  8 13:51:39
> 2004 +++ src/linuxsampler.cpp        Tue Oct 12 13:05:18 2004
> @@ -25,7 +25,10 @@
>
>  #include "Sampler.h"
>  #include "drivers/midi/MidiInputDeviceFactory.h"
> +#include "drivers/midi/MidiInputDeviceAlsa.h"
>  #include "drivers/audio/AudioOutputDeviceFactory.h"
> +#include "drivers/audio/AudioOutputDeviceAlsa.h"
> +#include "drivers/audio/AudioOutputDeviceJack.h"
>  #include "network/lscpserver.h"
>  #include "common/stacktrace.h"
>
> @@ -73,6 +76,9 @@
>      pSampler = new Sampler;
>      dmsg(1,("OK\n"));
>
> +    printf("ensure audio linking: %s, %s\n",
> AudioOutputDeviceAlsa::Name().c_str(),
> AudioOutputDeviceJack::Name().c_str()); +    printf("ensure midi linking:
> %s\n", MidiInputDeviceAlsa::Name().c_str()); +
>      dmsg(1,("Registered MIDI input drivers: %s\n",
> MidiInputDeviceFactory::AvailableDriversAsString().c_str()));
> dmsg(1,("Registered audio output drivers: %s\n",
> AudioOutputDeviceFactory::AvailableDriversAsString().c_str()));

I will apply that a bit modified. This workaround should somewhere hided in 
the facrory classes itself. After the first release we will replace that 
driver mechanism by dynamically loading the drivers as .so files directly 
from a given directory. So we won't have to deal with such things in future.

> The Mutex tests all passed, though there was a segfault on the first run.
>
> src/testcases/linuxsamplertest #1:
> Running Pool Tests: ....................
> Running Thread Tests: .....
> Running Mutex Tests: .....
> Running Condition Tests: ....
> Running LSCP Tests: ..LSCPServer: Client connection established on
> socket:7. .LSCPServer: Client connection terminated on socket:7.
> LSCPServer: Client connection established on socket:7.
> ...F.Segmentation fault
>
>
> src/testcases/linuxsamplertest #2:
> Running Pool Tests: ....................
> Running Thread Tests: .....
> Running Mutex Tests: .....
> Running Condition Tests: ....
> Running LSCP Tests: ..LSCPServer: Client connection established on
> socket:7. .LSCPServer: Client connection terminated on socket:7.
> LSCPServer: Client connection established on socket:7.
> ...F..LSCPServer: Client connection terminated on socket:7.
>
> !!!FAILURES!!!
> Test Results:
> Run:  47   Failures: 1   Errors: 0
>
> 1) test: LSCPTest::test_GET_AUDIO_OUTPUT_CHANNEL_PARAMETER_INFO (F) line:
> 352 LSCPTest.cpp assertion failed
> - Expression: drivers.size()

For segfaults, let us know how the stacktrace looks like.

For the one reported failure in the LSCP tests; this is caused by your driver 
registration problem of course.

CU
Christian

Re: [Linuxsampler-devel] No Registered MIDI or audio drivers

[James K. <ja...@kl...>]

I now have LinuxSampler working and I'm extremely excited about the
future of this project. Things are off to a great start.

Thanks Christian for your reply. My response follows.

-James

On Tue, Oct 12, 2004 at 08:46:04PM +0200, Christian Schoenebeck wrote:

> but for backward compatibility we currently allow beside "ALSA" also "Alsa" 
> and beside "JACK" also "Jack" (see src/network/lscpserver.cpp, line 1158).

You might want to double check the compatibility code as 'Alsa' is not being
recognized:
GET AVAILABLE_AUDIO_OUTPUT_DRIVERS
ALSA,JACK

CREATE AUDIO_OUTPUT_DEVICE Alsa CARD='0,0' SAMPLERATE=48000
ERR:0:There is no audio output driver 'Alsa'.
 
> Really strange that Alsa and Jack is detected by the configure script but the 
> devices won't register. Unfortunately I can't tell you a sane reason for this 
> ATM. Are the files AudioOutputDeviceAlsa.cpp, AudioOutputDeviceJack.cpp and 
> MidiInputDeviceAlsa.cpp actually compiled _AND_ linked into the final 
> library? Can you check that please? Driver registration is BTW done by two 
> macros named REGISTER_AUDIO_OUTPUT_DRIVER() and REGISTER_MIDI_INPUT_DRIVER() 
> (defined in AudioOutputDeviceFactor.h and MidiInputDeviceFactory.h 
> respectively). You'll see that on top of every LS driver cpp file like 
> src/drivers/midi/MidiInputDeviceAlsa.cpp or 
> src/drivers/audio/AudioOutputDeviceAlsa.cpp for example.
> Maybe place some printf()s in the two factory classes to see if they're really 
> executed, but my assumption is no.

I found the problem. The drivers were not being linked and I really can't
blame GCC. The only references to the actual drivers are contained within
the drivers themselves. I patched linuxsampler.cpp to directly reference
the drivers and things started working as planned.

--- linuxsampler-cvs20041010/src/linuxsampler.cpp     Fri Oct  8 13:51:39 2004
+++ src/linuxsampler.cpp        Tue Oct 12 13:05:18 2004
@@ -25,7 +25,10 @@

 #include "Sampler.h"
 #include "drivers/midi/MidiInputDeviceFactory.h"
+#include "drivers/midi/MidiInputDeviceAlsa.h"
 #include "drivers/audio/AudioOutputDeviceFactory.h"
+#include "drivers/audio/AudioOutputDeviceAlsa.h"
+#include "drivers/audio/AudioOutputDeviceJack.h"
 #include "network/lscpserver.h"
 #include "common/stacktrace.h"

@@ -73,6 +76,9 @@
     pSampler = new Sampler;
     dmsg(1,("OK\n"));

+    printf("ensure audio linking: %s, %s\n", AudioOutputDeviceAlsa::Name().c_str(), AudioOutputDeviceJack::Name().c_str());
+    printf("ensure midi linking: %s\n", MidiInputDeviceAlsa::Name().c_str());
+
     dmsg(1,("Registered MIDI input drivers: %s\n", MidiInputDeviceFactory::AvailableDriversAsString().c_str()));
     dmsg(1,("Registered audio output drivers: %s\n", AudioOutputDeviceFactory::AvailableDriversAsString().c_str()));

 
> > +#define _XOPEN_SOURCE 500 /* to define PTHREAD_MUTEX_ERRORCHECK */
> 
> That was one of the issues I was not sure about last weekend. Just defining 
> that macro may not be sufficient, even though it compiles fine. Please try if 
> the testcases run successfully. To do so do
> 
>  make tests && src/testcases/linuxsamplertest
> 
> This will compile and run unit tests against LinuxSampler. Please let me know 
> if all tests were successfully. My assumption is that some of the Mutex tests 
> will fail on your system.

The Mutex tests all passed, though there was a segfault on the first run.

src/testcases/linuxsamplertest #1:
Running Pool Tests: .................... 
Running Thread Tests: ..... 
Running Mutex Tests: ..... 
Running Condition Tests: .... 
Running LSCP Tests: ..LSCPServer: Client connection established on socket:7.
.LSCPServer: Client connection terminated on socket:7.
LSCPServer: Client connection established on socket:7.
...F.Segmentation fault

 
src/testcases/linuxsamplertest #2:
Running Pool Tests: .................... 
Running Thread Tests: ..... 
Running Mutex Tests: ..... 
Running Condition Tests: .... 
Running LSCP Tests: ..LSCPServer: Client connection established on socket:7.
.LSCPServer: Client connection terminated on socket:7.
LSCPServer: Client connection established on socket:7.
...F..LSCPServer: Client connection terminated on socket:7.

!!!FAILURES!!!
Test Results:
Run:  47   Failures: 1   Errors: 0

1) test: LSCPTest::test_GET_AUDIO_OUTPUT_CHANNEL_PARAMETER_INFO (F) line: 352 LSCPTest.cpp
assertion failed
- Expression: drivers.size()

Re: [Linuxsampler-devel] No Registered MIDI or audio drivers

[Christian S. <sch...@so...>]

Es geschah am Montag 11 Oktober 2004 22:09 als ja...@kl... schrieb:
> I compiled linuxsampler from the latest CVS 2004-10-10 and after a small
> patch, got it running.
>
> When it starts up, the output is:
> LinuxSampler 0.2
> Copyright (C) 2003, 2004 by Benno Senoner and Christian Schoenebeck
> Creating Sampler...OK
> Registered MIDI input drivers:
> Registered audio output drivers:

There's the first problem. It should show you the available audio and MIDI 
drivers here. So it should look like:

 Registered MIDI input drivers: ALSA
 Registered audio output drivers: ALSA, JACK

Or whatever is available on your system.

> I don't know if the driver name is case-sensitive. I've tried using both
> Alsa and ALSA. Obviously, if the drivers aren't registered it won't
> matter how I spell it.

Exactly, but btw like almost all in the network protocol, it's case sensitive. 
but for backward compatibility we currently allow beside "ALSA" also "Alsa" 
and beside "JACK" also "Jack" (see src/network/lscpserver.cpp, line 1158).

> Here is the output of commands to determine available devices/drivers.
[snip]
> GET AVAILABLE_MIDI_INPUT_DRIVERS
>
> GET AVAILABLE_AUDIO_OUTPUT_DRIVERS
>

Seems for some reasons the audio and midi devices won't register themselves on 
your machine.

> I have the Alsa driver/lib/utils 1.0.6, and Jack 0.99.0 installed and
> they are both detected by configure. The compiler is gcc-2.96.
> ...
> checking alsa/asoundlib.h usability... yes
> checking alsa/asoundlib.h presence... yes
> checking for alsa/asoundlib.h... yes
> checking for main in -lasound... yes
> checking Alsa version... 1.0.6
> checking for pkg-config... /usr/bin/pkg-config
> checking for jack... yes
> checking JACK_CFLAGS...  -I/var/tmp/sampler/include
> checking JACK_LIBS...  -L/var/tmp/sampler/lib -ljack
> ...

Really strange that Alsa and Jack is detected by the configure script but the 
devices won't register. Unfortunately I can't tell you a sane reason for this 
ATM. Are the files AudioOutputDeviceAlsa.cpp, AudioOutputDeviceJack.cpp and 
MidiInputDeviceAlsa.cpp actually compiled _AND_ linked into the final 
library? Can you check that please? Driver registration is BTW done by two 
macros named REGISTER_AUDIO_OUTPUT_DRIVER() and REGISTER_MIDI_INPUT_DRIVER() 
(defined in AudioOutputDeviceFactor.h and MidiInputDeviceFactory.h 
respectively). You'll see that on top of every LS driver cpp file like 
src/drivers/midi/MidiInputDeviceAlsa.cpp or 
src/drivers/audio/AudioOutputDeviceAlsa.cpp for example.
Maybe place some printf()s in the two factory classes to see if they're really 
executed, but my assumption is no.

> P.S. The small patch required was:
>
> --- src/common/Mutex.cpp        9 Oct 2004 15:40:35 -0000       1.5
> +++ src/common/Mutex.cpp        11 Oct 2004 20:03:44 -0000
> @@ -20,11 +20,14 @@
>   *   MA  02111-1307  USA
>   *   *
>  
> ***************************************************************************
>/
>
> -#include <iostream>
> +#define _XOPEN_SOURCE 500 /* to define PTHREAD_MUTEX_ERRORCHECK */

That was one of the issues I was not sure about last weekend. Just defining 
that macro may not be sufficient, even though it compiles fine. Please try if 
the testcases run successfully. To do so do

 make tests && src/testcases/linuxsamplertest

This will compile and run unit tests against LinuxSampler. Please let me know 
if all tests were successfully. My assumption is that some of the Mutex tests 
will fail on your system.

> +#include <iostream>
>  #include <errno.h>
> +#include <stdlib.h> /* for exit(int) */

I'll add that to CVS

Please let me know if you came any further with your problem or not!

CU
Christian

[Linuxsampler-devel] No Registered MIDI or audio drivers

[<ja...@kl...>]

I compiled linuxsampler from the latest CVS 2004-10-10 and after a small
patch, got it running.

When it starts up, the output is:
LinuxSampler 0.2
Copyright (C) 2003, 2004 by Benno Senoner and Christian Schoenebeck
Creating Sampler...OK
Registered MIDI input drivers: 
Registered audio output drivers: 
Starting LSCP network server (on TCP port 8888)...OK
LinuxSampler initialization completed.
LSCPServer: Client connection established on socket:6.
There is no audio output driver 'Alsa'.
There is no midi input driver 'Alsa'.
...


Here are some of the commands I used for configuration:
CREATE AUDIO_OUTPUT_DEVICE Alsa CARD="1,0"
ERR:0:There is no audio output driver 'Alsa'.
CREATE MIDI_INPUT_DEVICE Alsa
ERR:0:There is no midi input driver 'Alsa'.

I don't know if the driver name is case-sensitive. I've tried using both
Alsa and ALSA. Obviously, if the drivers aren't registered it won't
matter how I spell it.

Here is the output of commands to determine available devices/drivers.

GET AVAILABLE_ENGINES
GigEngine
GET AVAILABLE_MIDI_INPUT_DRIVERS

GET AVAILABLE_AUDIO_OUTPUT_DRIVERS

GET MIDI_INPUT_DEVICES
0
GET AUDIO_OUTPUT_DEVICES
0
GET CHANNELS
0
LIST AUDIO_OUTPUT_DEVICES


I have the Alsa driver/lib/utils 1.0.6, and Jack 0.99.0 installed and
they are both detected by configure. The compiler is gcc-2.96.
...
checking alsa/asoundlib.h usability... yes
checking alsa/asoundlib.h presence... yes
checking for alsa/asoundlib.h... yes
checking for main in -lasound... yes
checking Alsa version... 1.0.6
checking for pkg-config... /usr/bin/pkg-config
checking for jack... yes
checking JACK_CFLAGS...  -I/var/tmp/sampler/include  
checking JACK_LIBS...  -L/var/tmp/sampler/lib -ljack  
...


I'm very interested in the linuxsampler project and would like to get
this running, so any info is appreciated.

Thanks,

-James


P.S. The small patch required was:

--- src/common/Mutex.cpp        9 Oct 2004 15:40:35 -0000       1.5
+++ src/common/Mutex.cpp        11 Oct 2004 20:03:44 -0000
@@ -20,11 +20,14 @@
  *   MA  02111-1307  USA
  *   *
  ***************************************************************************/
 
-#include <iostream>
+#define _XOPEN_SOURCE 500 /* to define PTHREAD_MUTEX_ERRORCHECK */
 
+#include <iostream>
 #include <errno.h>
+#include <stdlib.h> /* for exit(int) */
 
 #include "Mutex.h"
 
 Mutex::Mutex() {
     // the following function call only works on UNIX98 compatible
     // systems

Re: [Linuxsampler-devel] Build failure: probable gcc-3.4.1 issue?

[Christian S. <sch...@so...>]

Am Donnerstag, 7. Oktober 2004 18:21 schrieb Rui Nuno Capela:
> stuff, cause I'm still fighting with some problems, so please go ahead and
> commit it.
>
>
> OK. I'll apply it tonight.

I also made the transition to gcc 3.4 tonight. Hope latest version still 
compiles for gccs < 3.4.

> On another subject, I noticed that linuxsampler maps MIDI channels number
> in a off-by-one difference to ALSA sequencer numbering, which equals the
> native low MIDI command address level. I think the following table shows
> this mismatch:
>
> MIDI     MIDI
> channel  channel
> address  number   linuxsampler  alsa-seq
> -------  -------  ------------  --------
> 0        1        All channels  0
> 1        2        1             1
> 2        3        2             2
> ...      ...      ...           ...
> 15       16       15            15

I first tended to say no, this is fine, because the majority of musicians is 
used to the 1..16 indexing of MIDI channels, but then I remembered that 
everyhting else in LS is indexed starting by 0 (sampler channel, audio 
channel, etc.). So to avoid having an exceptional case here, I now changed 
MIDI channel indexing globally to the low level variant 0..15, too.

> Moreover, the "All channels" linuxsampler specification doesn't seem to
> work at all, being just single mapped to MIDI Channel 1 (address 0).

Yep, fixed now in latest CVS:

> be. Additionally, I think this MIDI channel numbering should be
> explicitly, if not, better documented.

I agree this should be mentioned in the documentation. Would you like to add 
it to the LSCP RFC or should I do it? Again, MIDI indexing is now 0..15 and 
16 would be "list to all MIDI channels", but on LSCP level the keyword "ALL" 
should be used instead of 16; I tend towards adding a WRN result, if somebody 
tries to use 16.

CU
Christian

Re: [Linuxsampler-devel] Build failure: probable gcc-3.4.1 issue?

[Rui N. C. <rn...@rn...>]

Hi Christian,
>
> I don't have gcc 3.4 but I'm surprised about some things,
> e.g. why gcc 3.4 insists on some of these "this->" pointers and
> e.g. the #include <errno.h> in rtelmemory.h.
>

Beats me :)

I'm also puzzled with th "this->" issue too. The compiler just kept
complaining that those inherited protected variables weren't being
declared.

The included "errno.h"s were needed, most probably because it isn't being
implicity included anymore by some other header file. gcc-3.4 include file
structure has perhaps changed, but not sure.


> But the patch is ok, of course. I'm not yet sure when I'll commit my
stuff, cause I'm still fighting with some problems, so please go ahead and
commit it.
>

OK. I'll apply it tonight.


On another subject, I noticed that linuxsampler maps MIDI channels number
in a off-by-one difference to ALSA sequencer numbering, which equals the
native low MIDI command address level. I think the following table shows
this mismatch:

MIDI     MIDI
channel  channel
address  number   linuxsampler  alsa-seq
-------  -------  ------------  --------
0        1        All channels  0
1        2        1             1
2        3        2             2
...      ...      ...           ...
15       16       15            15

That is, 0 (zero) means "All channels" to
linuxsampler(MidiInputPort::midi_chan_all), but for ALSA and low-level
MIDI for this matter, it's the valid MIDI channel address 0 (zero), or
MIDI Channel 1 (one).

Moreover, the "All channels" linuxsampler specification doesn't seem to
work at all, being just single mapped to MIDI Channel 1 (address 0).

So I would ask, what's the status for this "All channels" (omni?) mode? It
doesn't seem to be implemented in MidiInputPort, where I think it should
be. Additionally, I think this MIDI channel numbering should be
explicitly, if not, better documented.

For example, the LSCP command SET CHANNEL MIDI_INPUT_CHANNEL assumes MIDI
channels being given in the range 1-16. Or so I think (the RFC document is
not explicit on that). However, the "ALL" channels" mode is clearly
mentioned.

Any comments?
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Build failure: probable gcc-3.4.1 issue?

[Christian S. <sch...@so...>]

Es geschah am Mittwoch 6. Oktober 2004 15:27 als Rui Nuno Capela schrieb:
> > Is 3.4 only more strictly or are there also some known incompatibilities
> > backwards? I just wonder if we should go with 3.4 now or wait until the
> > 1st release.
>
> OK. I think there's no need for such dramatic measures ;)
>
> The attached patch solves all reported compilation problems, at least on
> my gcc-3.4.1 platform (Mdk 10.1c). It builds and runs as usual now.
>
> The major incompabilities came from Bennos's RTELMemoryPool.h, which I had
> to spend some time to change and comply, with minimal impact. IMO the

Mmm... sorry to say, but in my current dev version RTELMemoryPool.h is already
dropped. I replaced it by complete new Pool classes. So...

> Please, I'll beg you all review the changes and check if there's any issue
> lurking around. If nothing gets wrong in between I may commit to CVS ASAP.

I don't have gcc 3.4 but I'm surprised about some things, e.g. why gcc 3.4
insists on some of these "this->" pointers and e.g. the #include <errno.h>
in rtelmemory.h.

But the patch is ok, of course. I'm not yet sure when I'll commit my stuff,
cause I'm still fighting with some problems, so please go ahead and commit it.

CU
Christian

Re: [Linuxsampler-devel] Build failure: probable gcc-3.4.1 issue?

[Rui N. C. <rn...@rn...>]

Hi,

Christian Schoenebeck wrote:
> Steve Harris wrote:
>> Rui Nuno Capela wrote:
>> > Strange enough, I get plenty of compiler errors, something that I
>> > suspect is due to gcc 3.4.1, which I'm dealing for the first time.
>>
>> Yes, 3.4 follows the C++ (and C for that matter) rules much more
>> strictly this causes some programs to fail building.
>
> Is 3.4 only more strictly or are there also some known incompatibilities
> backwards? I just wonder if we should go with 3.4 now or wait until the
> 1st release.
>

OK. I think there's no need for such dramatic measures ;)

The attached patch solves all reported compilation problems, at least on
my gcc-3.4.1 platform (Mdk 10.1c). It builds and runs as usual now.

The major incompabilities came from Bennos's RTELMemoryPool.h, which I had
to spend some time to change and comply, with minimal impact. IMO the
incompabilities exposed by the original doesn't make any sense at all, as
it looked like quite legal C++ code, as in fact was before gcc-3.4 coming
to town.

Please, I'll beg you all review the changes and check if there's any issue
lurking around. If nothing gets wrong in between I may commit to CVS ASAP.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Build failure: probable gcc-3.4.1 issue?

[Christian S. <sch...@so...>]

Es geschah am Samstag 02 Oktober 2004 12:26 als Steve Harris schrieb:
> On Sat, Oct 02, 2004 at 10:48:01AM +0100, Rui Nuno Capela wrote:
> > Strange enough, I get plenty of compiler errors, something that I suspect
> > is due to gcc 3.4.1, which I'm dealing for the first time.
>
> Yes, 3.4 follows the C++ (and C for that matter) rules much more strictly
> this causes some programs to fail building.

Is 3.4 only more strictly or are there also some known incompatibilities 
backwards? I just wonder if we should go with 3.4 now or wait until the 1st 
release.

CU
Christian

Re: [Linuxsampler-devel] Build failure: probable gcc-3.4.1 issue?

[Steve H. <S.W...@ec...>]

On Sat, Oct 02, 2004 at 10:48:01AM +0100, Rui Nuno Capela wrote:
> Strange enough, I get plenty of compiler errors, something that I suspect
> is due to gcc 3.4.1, which I'm dealing for the first time.

Yes, 3.4 follows the C++ (and C for that matter) rules much more strictly
this causes some programs to fail building.

- Steve 

[Linuxsampler-devel] Build failure: probable gcc-3.4.1 issue?

[Rui N. C. <rn...@rn...>]

Hi,

I just deciced to upgrade my laptop to Mandrake 10.1 (coming from 10.0)
and when all the dust settled down (or so I thought) I headed to build
linuxsampler from CVS HEAD.

Strange enough, I get plenty of compiler errors, something that I suspect
is due to gcc 3.4.1, which I'm dealing for the first time.

The outputs of ./configure && make are sent on attachment (configure.out
and make.out, respectively).

This seems to be slightly related to some C++ template issue, as
linuxsampler makes massive use of those. I didn't investigated any
further. Probably is something about this distro being still very shaky.

However, notice that all my Qt  projects, which are old-school C++ as you
might know, build perfectly fine under this gcc 3.4.1 environment.

So I thought someone had already com accross into this or any similiar,
and suggest some silver-bullet solution?

Has anyone the kindness here?

Thanks,
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] [qsampler, liblscp] Latest CVS commit

[Rui N. C. <rn...@rn...>]

Hi,

Long time, eh?


qsampler 0.0.3.2:

* Sampler reset command action added to menu and toolbar.

* MIDI channel selection is now a dropdown list, allowing
  the explicit selection for "All" channels input per sampler
  channel (omni).

* Channel strip display glass effect has changed background
  color to black (was green).

* Minor configure fixes.


liblscp 0.2.3:


* Fixed lscp_set_channel_midi_channel() where MIDI channels
  should be given in the range 1-16, and omni mode with new
  LSCP_MIDI_CHANNEL_ALL symbol (0).

* Rearrangement on main command requester executive.


Bye.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...