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

Re: [Linuxsampler-devel] little problem to compile linuxsampler with the last GCC15

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

On Wednesday, 12 November 2025 19:27:41 CET Philippe DIDIER wrote:
> Le 12/11/2025 à 13:14, Christian Schoenebeck a écrit :
> > On Tuesday, November 11, 2025 12:15:22 AM CET Philippe DIDIER wrote:
> > [...]
> > 
> >> But I failed to build LinuxSampler for the next coming version of my
> >> distribution using GCC15.2 :
> >> my system was not supposed to be UNIX98 compatible
> >> But indeed it is
> >> 
> >> I simply have had to add this patch to add one line in configure.ac and
> >> it's OK now :
> >> 
> >> --- /configure.ac    2025-11-07 14:35:24.000000000 +0100
> >> +++ /configure.ac    2025-11-09 19:12:47.608538979 +0100
> >> @@ -131,6 +131,7 @@
> >> 
> >>    #define _GNU_SOURCE 1
> >>    #endif
> >>    #include <features.h>
> >> 
> >> +#include <stdlib.h>
> >> 
> >>    void main(void) {
> >>    #if _XOPEN_SOURCE >= 500
> >>    exit(0); /* UNIX98 compatible */
> > 
[...]
> I am using a Linux distribution (Mageia)
> The actual version of Mageia is Mageia9
> No problem to build LinuxSampler 2.4.1 with GCC 12.3
> 
> But we are preparing the next MAgeia10 inside Mageia Caludron
> and Mageia10 will be built upon GCC15.2
> That's where the problem appeared (GCC15.x is more strict)
> The workaround was to modify configure.ac with a patch
> adding only :
> #include <stdlib.h> after line 133 That's enough

I was able to reproduce this with GCC 14 as well. Apparently not a compiler 
version issue. Root cause was the exit() function not been declared. 
Apparently stdlib.h was previously included by features.h.

I fixed this now by replacing the exit function calls by a simple return 
statement, and also addressed other configure checks that were prone to this 
issue as well:

https://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4413

Thanks!

/Christian

[Linuxsampler-devel] Full Suite of RPMs for Fedora 41/42

[Jim H. <la...@gm...>]

Is there any interest in hosting a full suite of RPMs for Fedora 41/42? 
I have been building them since LinuxSampler 2.4.0.

There was one caveat to building linuxsampler. There is a conflict with 
Fedora package nilfs-utils which also contains a /usr/bin/lscp so I 
renamed the LS one to linuxsampler-lscp along with its man document.

The following RPMs are currently available:

gigedit-1.2.3-1.fc41.x86_64.rpm
libgig-4.5.1-1.fc41.x86_64.rpm
libgig-devel-4.5.1-1.fc41.x86_64.rpm
liblscp-1.0.1-1.fc41.x86_64.rpm
liblscp-devel-1.0.1-1.fc41.x86_64.rpm
linuxsampler-2.4.1-1.fc41.x86_64.rpm
linuxsampler-devel-2.4.1-1.fc41.x86_64.rpm
qsampler-1.0.1.7git.279c08-2.fc41.x86_64.rpm

They may be downloaded from my google drive:
https://drive.google.com/drive/folders/1mpZ-bcxL5bdrSKIiOOR71OMvV5t2I0B6?usp=drive_link

Jim

Re: [Linuxsampler-devel] Extract Samples from a Gig file

[Jim H. <la...@gm...>]

On 11/22/25 10:30 AM, Christian Schoenebeck wrote:
> On Friday, 21 November 2025 17:11:04 CET Jim Hines wrote:
>> Is it possible to export the samples from a .gig file to .wav format
>> using GigEdit?
> Not with Gigedit ATM (only import/update), but you can use libgig's gigextract
> command line tool (see 'man gigextract').
>
> /Christian
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Yes, thank you. I figured this out about an hour after posting to the 
list. It works well!

Jim

Re: [Linuxsampler-devel] Extract Samples from a Gig file

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

On Friday, 21 November 2025 17:11:04 CET Jim Hines wrote:
> Is it possible to export the samples from a .gig file to .wav format
> using GigEdit?

Not with Gigedit ATM (only import/update), but you can use libgig's gigextract 
command line tool (see 'man gigextract').

/Christian

[Linuxsampler-devel] Extract Samples from a Gig file

[Jim H. <la...@gm...>]

Is it possible to export the samples from a .gig file to .wav format 
using GigEdit?

Jim

Re: [Linuxsampler-devel] Possible bug or by design [LV2]

[Jim H. <la...@gm...>]

Thank you for you detailed explanation.

On 11/13/25 8:11 AM, Christian Schoenebeck wrote:
> On Wednesday, November 12, 2025 7:49:44 PM CET Jim Hines wrote:
> [...]
>> quite impressive having not used LS in a few years. However there is
>> something that just doesn't seem right with the LV2 plugin. If QSampler
>> is already running (and hosting linuxsampler 2.4.1) loading the LV2
>> plugin freezes both Ardour and Mixbus until Qsampler is exited therefore
>> also exiting linuxsampler, then Ardour/Mixbus will unfreeze and load the
>> LinuxSampler LV2 plugin. I can then load QSampler and everything is
>> fine.
> This is the status quo: no matter if LV2, DSSI, VST or AU plugin, Linux,
> Windows or Mac, the basic behaviour and usage procedure for LinuxSampler
> plugins is the same, simply because they all share the same common plugin base
> class (src/drivers/Plugin plus subdirs).
>
> The plugin type specific code (under src/hostplugins) OTOH is very little and
> just provides the glue code to the respective plugin specific API.
>
> Current usage: First you load the LinuxSampler plugin instance(s) into the
> host application of you choice. The first plugin instance automatically spawns
> the sampler's backend (e.g. central C++ API control class "Sampler", sampler
> engines, effects, editor plugins, drivers) *within* the plugin's process! The
> first plugin instance also launches the LSCP server which binds to local TCP
> port 8888.
>
>  From this point on you can use your sampler frontend of your choice (e.g.
> QSampler GUI, Fantasia GUI, LSCP shell CLI) to setup the LinuxSampler plugin
> instances for your current DAW session. The sampler frontends all communicate
> via LSCP protocol on TCP port 8888 with the sampler backend.
>
> The overall LinuxSampler plugin setup is automatically stored and restored
> with your DAW's project. So you don't have to grab a frontend again just to
> continue with a song. You just load the song in your DAW application next time
> and that's it. You only need a frontend again if you need to make changes
> obviously.
>
Maybe all we need is a LUA script within Ardour to be able to send lscp 
scripts directly to the LV2/DAW instance of LinuxSampler. This could 
potentially open up an entire world of possibilities including making 
use of the instrument.db. But, with the current sandboxing of LUA within 
Ardour, it may still not be possible. sigh.

>> This seems odd. Why
>> does the plugin not just connect to a running linuxsampler process if
>> found and leaves it running upon exiting? Also, why can't the LV2 plugin
>> connect to a remote instance of LS? This seems to defeat the purpose of
>> having a dedicated remote LinuxSampler server(s) which would be super
>> useful.
> Because the plugins (or rather their shared plugin base class) are currently
> requiring the sampler backend to be within the same process. The plugin just
> calls the sampler's native C++ API to request it render audio and return that
> audio buffer to the plugin.
>
> Of course this could be changed by implementing IPC for transferring the audio
> in real-time from a separate sampler backend process. But apparently nobody
> cared enough to sit down and write that audio IPC transfer code. Plus it would
> also bring certain disadvantages: e.g. the minimum latency possible is much
> smaller if host, plugin and backend are within the same process.
>
> The problematic would become worse of course if the sampler backend would even
> run on another machine of course.
>
> Everything is possible, but someone has to do it. ;-)
>
> /Christian
>
Yes, I can see there could be some serious latency issues introduced by 
something like this.

Jim

Re: [Linuxsampler-devel] Possible bug or by design [LV2]

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

On Wednesday, November 12, 2025 7:49:44 PM CET Jim Hines wrote:
[...]
> quite impressive having not used LS in a few years. However there is
> something that just doesn't seem right with the LV2 plugin. If QSampler
> is already running (and hosting linuxsampler 2.4.1) loading the LV2
> plugin freezes both Ardour and Mixbus until Qsampler is exited therefore
> also exiting linuxsampler, then Ardour/Mixbus will unfreeze and load the
> LinuxSampler LV2 plugin. I can then load QSampler and everything is
> fine.

This is the status quo: no matter if LV2, DSSI, VST or AU plugin, Linux, 
Windows or Mac, the basic behaviour and usage procedure for LinuxSampler 
plugins is the same, simply because they all share the same common plugin base 
class (src/drivers/Plugin plus subdirs).

The plugin type specific code (under src/hostplugins) OTOH is very little and 
just provides the glue code to the respective plugin specific API.

Current usage: First you load the LinuxSampler plugin instance(s) into the 
host application of you choice. The first plugin instance automatically spawns 
the sampler's backend (e.g. central C++ API control class "Sampler", sampler 
engines, effects, editor plugins, drivers) *within* the plugin's process! The 
first plugin instance also launches the LSCP server which binds to local TCP 
port 8888.

>From this point on you can use your sampler frontend of your choice (e.g. 
QSampler GUI, Fantasia GUI, LSCP shell CLI) to setup the LinuxSampler plugin 
instances for your current DAW session. The sampler frontends all communicate 
via LSCP protocol on TCP port 8888 with the sampler backend.

The overall LinuxSampler plugin setup is automatically stored and restored 
with your DAW's project. So you don't have to grab a frontend again just to 
continue with a song. You just load the song in your DAW application next time 
and that's it. You only need a frontend again if you need to make changes 
obviously.

> However, once I exit Ardour/Mixbus, it kills the linuxsampler
> process with it and leaves Qsampler hanging with a "broken pipe".

Correct, which you can just ignore. When you reload the session in your DAW, 
QSampler should automatically reconnect to the sampler backend running 
*within* your DAW's process. But that's configurable in QSampler.

> Loading the LV2 plugin on it's own does not load a linuxsampler
> background process. Yet it kills it upon exiting.

Because the sampler backend is not running in its own process, like described 
above. So if the DAW application stops the process where the plugins are 
running in, it also stops the sampler backend as it runs within the same 
process.

> This seems odd. Why
> does the plugin not just connect to a running linuxsampler process if
> found and leaves it running upon exiting? Also, why can't the LV2 plugin
> connect to a remote instance of LS? This seems to defeat the purpose of
> having a dedicated remote LinuxSampler server(s) which would be super
> useful.

Because the plugins (or rather their shared plugin base class) are currently 
requiring the sampler backend to be within the same process. The plugin just 
calls the sampler's native C++ API to request it render audio and return that 
audio buffer to the plugin.

Of course this could be changed by implementing IPC for transferring the audio 
in real-time from a separate sampler backend process. But apparently nobody 
cared enough to sit down and write that audio IPC transfer code. Plus it would 
also bring certain disadvantages: e.g. the minimum latency possible is much 
smaller if host, plugin and backend are within the same process.

The problematic would become worse of course if the sampler backend would even 
run on another machine of course.

Everything is possible, but someone has to do it. ;-)

/Christian

[Linuxsampler-devel] Possible bug or by design [LV2]

[Jim H. <la...@gm...>]

Hi all,
This is my first post to this mailing list. I recently built the full 
latest version of the LinuxSampler suite for Fedora 41 (RPMs) and it's 
quite impressive having not used LS in a few years. However there is 
something that just doesn't seem right with the LV2 plugin. If QSampler 
is already running (and hosting linuxsampler 2.4.1) loading the LV2 
plugin freezes both Ardour and Mixbus until Qsampler is exited therefore 
also exiting linuxsampler, then Ardour/Mixbus will unfreeze and load the 
LinuxSampler LV2 plugin. I can then load QSampler and everything is 
fine. However, once I exit Ardour/Mixbus, it kills the linuxsampler 
process with it and leaves Qsampler hanging with a "broken pipe".

Loading the LV2 plugin on it's own does not load a linuxsampler 
background process. Yet it kills it upon exiting. This seems odd. Why 
does the plugin not just connect to a running linuxsampler process if 
found and leaves it running upon exiting? Also, why can't the LV2 plugin 
connect to a remote instance of LS? This seems to defeat the purpose of 
having a dedicated remote LinuxSampler server(s) which would be super 
useful.

Thanks,
Jim Hines

Re: [Linuxsampler-devel] little problem to compile linuxsampler with the last GCC15

[Philippe D. <phi...@la...>]

Le 12/11/2025 à 13:14, Christian Schoenebeck a écrit :
> On Tuesday, November 11, 2025 12:15:22 AM CET Philippe DIDIER wrote:
> [...]
>> But I failed to build LinuxSampler for the next coming version of my
>> distribution using GCC15.2 :
>> my system was not supposed to be UNIX98 compatible
>> But indeed it is
>>
>> I simply have had to add this patch to add one line in configure.ac and
>> it's OK now :
>>
>> --- /configure.ac    2025-11-07 14:35:24.000000000 +0100
>> +++ /configure.ac    2025-11-09 19:12:47.608538979 +0100
>> @@ -131,6 +131,7 @@
>>    #define _GNU_SOURCE 1
>>    #endif
>>    #include <features.h>
>> +#include <stdlib.h>
>>    void main(void) {
>>    #if _XOPEN_SOURCE >= 500
>>    exit(0); /* UNIX98 compatible */
> Thanks for letting us know!
>
> Could you provide more details? I assume you are building on Windows, right?
> What are the exact compile errors you get?
>
> That Unix98 check is fairly old. So the question is whether we should change
> the check here, or something in our sources. Because on Windows you get more
> and more POSIX APIs. Back then we simply considered its either UNIX(98) or
> Windows.
>
> For instance, chances are that stdlib.h is simply doing #undef _GNU_SOURCE
> there, in that case this #include would just fight the symptom.
>
> /Christian
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Hi Christian

I am using a Linux distribution (Mageia)
The actual version of Mageia is Mageia9
No problem to build LinuxSampler 2.4.1 with GCC 12.3

But we are preparing the next MAgeia10 inside Mageia Caludron
and Mageia10 will be built upon GCC15.2
That's where the problem appeared (GCC15.x is more strict)
The workaround was to modify configure.ac with a patch
adding only :
#include <stdlib.h> after line 133 That's enough

Re: [Linuxsampler-devel] little problem to compile linuxsampler with the last GCC15

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

On Tuesday, November 11, 2025 12:15:22 AM CET Philippe DIDIER wrote:
[...]
> But I failed to build LinuxSampler for the next coming version of my
> distribution using GCC15.2 :
> my system was not supposed to be UNIX98 compatible
> But indeed it is
> 
> I simply have had to add this patch to add one line in configure.ac and
> it's OK now :
> 
> --- /configure.ac    2025-11-07 14:35:24.000000000 +0100
> +++ /configure.ac    2025-11-09 19:12:47.608538979 +0100
> @@ -131,6 +131,7 @@
>   #define _GNU_SOURCE 1
>   #endif
>   #include <features.h>
> +#include <stdlib.h>
>   void main(void) {
>   #if _XOPEN_SOURCE >= 500
>   exit(0); /* UNIX98 compatible */

Thanks for letting us know!

Could you provide more details? I assume you are building on Windows, right? 
What are the exact compile errors you get?

That Unix98 check is fairly old. So the question is whether we should change 
the check here, or something in our sources. Because on Windows you get more 
and more POSIX APIs. Back then we simply considered its either UNIX(98) or 
Windows.

For instance, chances are that stdlib.h is simply doing #undef _GNU_SOURCE 
there, in that case this #include would just fight the symptom.

/Christian

Re: [Linuxsampler-devel] Problem Getting LinuxSampler Started

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

On Monday, November 10, 2025 10:58:45 PM CET cli...@sy... wrote:
> Hello:
> 
> I am brand new to LinuxSampler.
> I am running Windows 10 on an HP laptop (vintage 2021).
> I downloaded and successfully installed both
> 
> jre-8u471-windows-x64.exe
> 
> and
> 
> linuxsampler_2_4_0_setup.exe
[...]
> linuxsampler.exe - Entry Point Not Found
> 
> ---------------------------
> 
> The procedure entry point
> _ZNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEC1Ev could not be
> located in the dynamic link library C:\Program
> Files\LinuxSampler\64\libgig-12.dll.

Please try the Windows installer of the latest LinuxSampler release (2.4.1)
that got released few days ago.

Andreas addressed an issue with libstdc++ with the Windows binary build that
should fix this issue for you as well I guess.

/Christian

[Linuxsampler-devel] little problem to compile linuxsampler with the last GCC15

[Philippe D. <phi...@la...>]

Hi

Actually I have no problem to build the last version of LinuxSampler 
(2.4.1) for the existing version of my distribution
using GCC 12.3

But I failed to build LinuxSampler for the next coming version of my 
distribution using GCC15.2 :
my system was not supposed to be UNIX98 compatible
But indeed it is

I simply have had to add this patch to add one line in configure.ac and 
it's OK now :

--- /configure.ac    2025-11-07 14:35:24.000000000 +0100
+++ /configure.ac    2025-11-09 19:12:47.608538979 +0100
@@ -131,6 +131,7 @@
  #define _GNU_SOURCE 1
  #endif
  #include <features.h>
+#include <stdlib.h>
  void main(void) {
  #if _XOPEN_SOURCE >= 500
  exit(0); /* UNIX98 compatible */


Maybe it is useful to add this line  #include <stdlib.h>
inside your source to be compliant with the next GCC15

Best Regards

[Linuxsampler-devel] Problem Getting LinuxSampler Started

[<cli...@sy...>]

Hello:

 

I am brand new to LinuxSampler.

I am running Windows 10 on an HP laptop (vintage 2021).

I downloaded and successfully installed both

 

jre-8u471-windows-x64.exe

 

and

 

linuxsampler_2_4_0_setup.exe

 

When I went to [Start] and ran

 

linuxsampler 2.4.0 (stand alone backend)

 

I got the following dialog:

 

---------------------------

linuxsampler.exe - Entry Point Not Found

---------------------------

The procedure entry point
_ZNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEC1Ev could not be
located in the dynamic link library C:\Program
Files\LinuxSampler\64\libgig-12.dll. 

---------------------------

                                                OK   

---------------------------

 

When I pressed OK the application closed.

 

I never got far enough to run 

 

[start] jsampler fantasia 0.9 (frontend)

 

Where can I find a corrected version of the dynamic link library
"libgig-12.dll"?

 

Thank you in advance. I will appreciate any help with this problem

 

Clinton

 

 

[Linuxsampler-devel] LinuxSampler 2.4.1 released

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

Hi everyone,

a new release had been rolled out today:

        o LinuxSampler 2.4.1
        o Gigedit 1.2.3
        o libgig 4.5.1

This is just a maintenance release with several fixes. Refer to the ChangeLog 
file for details of the individual fixes.

/Christian

Re: [Linuxsampler-devel] problem to build linuxsampler 2.4.0 for armv7hl

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

On Monday, September 29, 2025 3:39:58 PM CEST Christian Schoenebeck wrote:
> On Thursday, June 19, 2025 8:35:53 AM CEST Philippe DIDIER wrote:
> > Le 18/06/2025 à 12:25, Christian Schoenebeck a écrit :
> [...]
> 
> > > I think that also needs some correction. Can you test the following
> > > patch?
> > > 
> > > Index: src/common/RTMath.cpp
> > > ===================================================================
> > > --- src/common/RTMath.cpp       (revision 4334)
> > > +++ src/common/RTMath.cpp       (working copy)
> > > @@ -74,16 +74,12 @@
> > > 
> > >       uint64_t t;
> > >       asm volatile ("mrs %0, cntvct_el0" : "=r"(t));
> > >       return (time_stamp_t) t;
> > > 
> > > -    #elif defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7S__)
> > > -    uint32_t t;
> > > -    asm volatile ("mrs %0, cntvct_el0" : "=r"(t));
> > > -    return t;
> > > 
> > >       #elif defined(__APPLE__)
> > >       return (time_stamp_t) mach_absolute_time();
> > >       #elif defined(__arm__) /* ARMv6 and older */
> > >       # warning ARM 'mrc' instruction requires special runtime
> > >       privileges!
> > >       uint32_t t;
> > > 
> > > -    asm volatile ("mrc p15, 0, %0, c15, c12, 1" : "=r" (t));
> > > +    asm volatile ("mrc p15, 0, %0, c9, c13, 0" : "=r" (t));
> > > 
> > >       return t;
> > >       #else // we don't want to use a slow generic solution
> > >       #  error "Sorry, LinuxSampler lacks time stamp code for your
> > >       system."
> 
> [...]
> 
> > I'm gonna test to compile with
> > 
> > asm volatile ("mrc p15, 0, %0, c9, c13, 0" : "=r" (t));
> > 
> > 
> > Unfortunately we can't test the use on a real armv7hl system (using a
> > virtual system is not enough)
> 
> It's been a while. Did you have a chance to test whether my suggested patch
> compiles for you?

I committed my suggested two ARM Assembly fixes:

https://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4396

https://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4397

The first one is obvious.

For the second one: I chose the Cycle Count register as officially specified
by the ARM specs (c9 0 c13 0):

https://developer.arm.com/documentation/ddi0344/k/system-control-coprocessor/system-control-coprocessor-registers/register-allocation

https://developer.arm.com/documentation/ddi0344/k/system-control-coprocessor/system-control-coprocessor-registers/c9--cycle-count-register

The old one apparently was an undocumented, ARM ISA implementer specific
register (which hence may only work on specific manufacturer dependent ARM
CPUs).

/Christian

Re: [Linuxsampler-devel] problem to build linuxsampler 2.4.0 for armv7hl

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

On Thursday, June 19, 2025 8:35:53 AM CEST Philippe DIDIER wrote:
> Le 18/06/2025 à 12:25, Christian Schoenebeck a écrit :
[...]
> > I think that also needs some correction. Can you test the following patch?
> > 
> > Index: src/common/RTMath.cpp
> > ===================================================================
> > --- src/common/RTMath.cpp       (revision 4334)
> > +++ src/common/RTMath.cpp       (working copy)
> > @@ -74,16 +74,12 @@
> > 
> >       uint64_t t;
> >       asm volatile ("mrs %0, cntvct_el0" : "=r"(t));
> >       return (time_stamp_t) t;
> > 
> > -    #elif defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7S__)
> > -    uint32_t t;
> > -    asm volatile ("mrs %0, cntvct_el0" : "=r"(t));
> > -    return t;
> > 
> >       #elif defined(__APPLE__)
> >       return (time_stamp_t) mach_absolute_time();
> >       #elif defined(__arm__) /* ARMv6 and older */
> >       # warning ARM 'mrc' instruction requires special runtime privileges!
> >       uint32_t t;
> > 
> > -    asm volatile ("mrc p15, 0, %0, c15, c12, 1" : "=r" (t));
> > +    asm volatile ("mrc p15, 0, %0, c9, c13, 0" : "=r" (t));
> > 
> >       return t;
> >       #else // we don't want to use a slow generic solution
> >       #  error "Sorry, LinuxSampler lacks time stamp code for your
> >       system."
> > 
[...]
> I'm gonna test to compile with
> 
> asm volatile ("mrc p15, 0, %0, c9, c13, 0" : "=r" (t));
> 
> 
> Unfortunately we can't test the use on a real armv7hl system (using a
> virtual system is not enough)

It's been a while. Did you have a chance to test whether my suggested patch 
compiles for you?

/Christian

Re: [Linuxsampler-devel] gigaedit saving issues

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

On Wednesday, September 17, 2025 11:49:17 AM CEST David Schornsheim via 
Linuxsampler-devel wrote:
>  > Considered fixed in Gigedit 1.2.2.svn2.
> 
> Thanks a lot for fixing this so quickly!
> 
> I tried the latest snapshot (2.4.0.svn1_20250914) and noticed two things
> with gigaedit when saving a giga studio file:
> 1. Saving any file under a new name brings up a warning dialog saying
> something along the lines of "Could not import the following sample(s):
> libgig error: could no (re)open the file "C:\path\to\newly saved
> file.gig" in read-write mode

Is that a Windows specific issue? I just made a quick test here and couldn't 
reproduce it, not on Windows though.

> 2. Opening this ~70MB file (original gig file from the SI Symphonic
> Brass Collection) and just saving it under a new name produces a huge
> 10GB gig file: https://owncloud.gwdg.de/index.php/s/KbngKGggApKN8Zt

To bring that specific issue forward, I fear you would need to debug it or 
find somebody to debug it for you.

> Let me know if this mailing list is still the appropriate channel for
> reporting bugs.

Right now it is.

Keep in mind though that currently it's basically two and a half people 
working on this stuff at all. So the more actively people are participating to 
investigate and resolve their encountered issues, the higher the chance they 
get fixed, and vice versa.

/Christian

Re: [Linuxsampler-devel] gigaedit saving issues

[David S. <dav...@gm...>]

 > Considered fixed in Gigedit 1.2.2.svn2.

Thanks a lot for fixing this so quickly!

I tried the latest snapshot (2.4.0.svn1_20250914) and noticed two things 
with gigaedit when saving a giga studio file:
1. Saving any file under a new name brings up a warning dialog saying 
something along the lines of "Could not import the following sample(s): 
libgig error: could no (re)open the file "C:\path\to\newly saved 
file.gig" in read-write mode
2. Opening this ~70MB file (original gig file from the SI Symphonic 
Brass Collection) and just saving it under a new name produces a huge 
10GB gig file: https://owncloud.gwdg.de/index.php/s/KbngKGggApKN8Zt

Let me know if this mailing list is still the appropriate channel for 
reporting bugs.

Best,
David

Am 09.09.2025 um 18:04 schrieb Christian Schoenebeck:
> On Monday, September 8, 2025 11:32:13 PM CEST David Schornsheim via
> Linuxsampler-devel wrote:
>> Hello,
>>
>> there's an issue with the current version of gigaedit (tested on Windows
>> 10 and on Linux) with version 2.4.0.svn1_20250906.
> [...]
>> For Andreas Persson, even the latest version still crashes when saving:
>>> * Start gigedit,
>>> * add a region,
>>> * add a sample (24 bit, 48kHz),
>>> * assign the sample to the region,
>>> * save the gig file (with a new file name)
>>> => crash
>>>
>>> Interestingly, this happens on Linux too, so it's not Windows specific.
>>>
>>> It crashes because RIFF::Chunk::Write throws this exception: "Cannot
>>> write data to chunk, file has to be opened in read+write mode first". I
>>> don't know why. There were many changes in this area of the code in
>>> February 2025. We should let Christian know about it.
> 
> Right, this was completely system agnostic.
> 
> I just committed two fixes for this:
> 
> https://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4366
> https://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4367
> 
> On the long term it makes sense to move the sample import into the file saver
> thread, then all the gig file save code would run on the same background
> thread, but for now that fix is trivial enough.
> 
> Considered fixed in Gigedit 1.2.2.svn2.
> 
> Thanks!
> 
> /Christian
> 
> 
> 
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] gigaedit saving issues

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

On Monday, September 8, 2025 11:32:13 PM CEST David Schornsheim via 
Linuxsampler-devel wrote:
> Hello,
> 
> there's an issue with the current version of gigaedit (tested on Windows
> 10 and on Linux) with version 2.4.0.svn1_20250906.
[...]
> For Andreas Persson, even the latest version still crashes when saving:
> > * Start gigedit,
> > * add a region,
> > * add a sample (24 bit, 48kHz),
> > * assign the sample to the region,
> > * save the gig file (with a new file name)
> > => crash
> > 
> > Interestingly, this happens on Linux too, so it's not Windows specific.
> > 
> > It crashes because RIFF::Chunk::Write throws this exception: "Cannot
> > write data to chunk, file has to be opened in read+write mode first". I
> > don't know why. There were many changes in this area of the code in
> > February 2025. We should let Christian know about it.

Right, this was completely system agnostic.

I just committed two fixes for this:

https://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4366
https://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4367

On the long term it makes sense to move the sample import into the file saver 
thread, then all the gig file save code would run on the same background 
thread, but for now that fix is trivial enough.

Considered fixed in Gigedit 1.2.2.svn2.

Thanks!

/Christian

[Linuxsampler-devel] gigaedit saving issues

[David S. <dav...@gm...>]

Hello,

there's an issue with the current version of gigaedit (tested on Windows 
10 and on Linux) with version 2.4.0.svn1_20250906.

Opening the 71MB giga file "4 Horns Mute Staccato.gig" from Sonic 
Implants Brass works fine in gigaedit, but saving it creates a whopping 
10GB giga file. At v2.3.1, resaving would simply crash.

For Andreas Persson, even the latest version still crashes when saving:
> * Start gigedit,
> * add a region,
> * add a sample (24 bit, 48kHz),
> * assign the sample to the region,
> * save the gig file (with a new file name)
> => crash
> 
> Interestingly, this happens on Linux too, so it's not Windows specific.
> 
> It crashes because RIFF::Chunk::Write throws this exception: "Cannot
> write data to chunk, file has to be opened in read+write mode first". I
> don't know why. There were many changes in this area of the code in
> February 2025. We should let Christian know about it.

Happy to provide any more info if required.

Best,
David

Re: [Linuxsampler-devel] Windows 2.4.0 build will not launch

[Tony L. <to...@to...>]

Andreas, the Sep 6 nightly build installed and runs properly in Windows
11, including jsampler.  Would love to see qsampler fixed as well.

Thank you!

-- 
Tony Ledford
__________________ 
Sent via GNOME Evolution on Manjaro Linux; free and open source
software (FOSS).

On Sat, 2025-09-06 at 15:20 +0200, Andreas Persson wrote:
> Tony Ledford wrote:
> > Hello.  I suppose this is the way to report bugs, I couldn't find
> > any
> > other way, at least.  If I need to report this issue by another
> > method,
> > please let me know.
> > 
> > I've been using linuxsampler on linux for over ten years, two or
> > three
> > different distros to get some use of aging gigastudio libraries
> > that are
> > still very useful.  I decided a few days ago to try the Windows
> > version
> > as well.
> > 
> > I've downloaded and installed 2.4.0 on two machines, one running
> > Windows
> > 11 Home and one running Windows 11 Pro, each fully updated.  In
> > both
> > cases, everything installs successfully, but upon attempting to
> > launch
> > qsampler, nothing appears except the error dialog in attachment
> > qsampler_error.png.  Fantasia will run, but it is non-functional
> > becase
> > linuxsampler will not run, attempting to start it from the Windows
> > Start
> > menu results in the error dialog attachment linuxsamper_error.png.
> >  And
> > trying to open gigaedit from Fantasia yields the error message in
> > libgig_error.png.
> 
> Hello,
> 
> Please try the snapshot build from today to see if anything works
> better. I did a quick fix in the installer that might fix the
> linuxsampler and libgig error (but not the qsampler one).
> 
> /Andreas
> 
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Windows 2.4.0 build will not launch

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

Tony Ledford wrote:
> Hello.  I suppose this is the way to report bugs, I couldn't find any
> other way, at least.  If I need to report this issue by another method,
> please let me know.
> 
> I've been using linuxsampler on linux for over ten years, two or three
> different distros to get some use of aging gigastudio libraries that are
> still very useful.  I decided a few days ago to try the Windows version
> as well.
> 
> I've downloaded and installed 2.4.0 on two machines, one running Windows
> 11 Home and one running Windows 11 Pro, each fully updated.  In both
> cases, everything installs successfully, but upon attempting to launch
> qsampler, nothing appears except the error dialog in attachment
> qsampler_error.png.  Fantasia will run, but it is non-functional becase
> linuxsampler will not run, attempting to start it from the Windows Start
> menu results in the error dialog attachment linuxsamper_error.png.  And
> trying to open gigaedit from Fantasia yields the error message in
> libgig_error.png.

Hello,

Please try the snapshot build from today to see if anything works
better. I did a quick fix in the installer that might fix the
linuxsampler and libgig error (but not the qsampler one).

/Andreas

Re: [Linuxsampler-devel] libgig version macro

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

On Wednesday, August 27, 2025 9:05:50 PM CEST Dalton Messmer wrote:
[...]
> If instead, macros like these were added to gig.h...
> 
> #define LIBGIG_VERSION_MAJOR 4
> #define LIBGIG_VERSION_MINOR 5
> #define LIBGIG_VERSION_REVISION 1
> 
> ...the problem would be solved from the next libgig version onward.
> 
> Thanks,
> Dalton

Sure!

The problem is, the release version is set by configure.ac, so wherever those 
macros were generated to a public API header file to (e.g. a dedicated new 
libgig_version.h file), it is supposed to work both with automake builds and 
CMake builds.

Would you have a patch to address this?

/Christian

[Linuxsampler-devel] libgig version macro

[Dalton M. <mes...@gm...>]

Hello,

It seems that there is no way to determine the libgig library version at
preprocessing time in order to conditionally use newer methods and avoid
deprecated methods.

This is an important missing feature for a library, and its absence forces
developers to use hacky build system workarounds like this one that uses
CMake to compile a small program that prints `gig::libraryVersion()`,
parses the output, and creates a config header based on the results:

https://github.com/LMMS/lmms/blob/dfa32440dc47d1758101092d6022316b0a85df7c/cmake/modules/FindGig.cmake#L16:L25
https://github.com/LMMS/lmms/blob/dfa32440dc47d1758101092d6022316b0a85df7c/plugins/GigPlayer/CMakeLists.txt#L6-L17

But even then, this workaround is broken on MSVC apparently.

If instead, macros like these were added to gig.h...

#define LIBGIG_VERSION_MAJOR 4
#define LIBGIG_VERSION_MINOR 5
#define LIBGIG_VERSION_REVISION 1

...the problem would be solved from the next libgig version onward.

Thanks,
Dalton

Re: [Linuxsampler-devel] loongarch64 support

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

On Monday, August 11, 2025 5:22:08 PM CEST Ilya Sorochan wrote:
> Hi,

Hi Ilya,

> I was able to build linuxsampler on loongarch64 with some minor tweaks and
> would like to share them and possibly merge into linuxsampler.
> I also successfully ran `make check` with those changes.
> All patches applied against 2.4.0
> 
> 1. Add CreateTimeStamp() implementation for loongarch64
> 
> --- a/src/common/RTMath.cpp
> +++ b/src/common/RTMath.cpp
> @@ -85,6 +85,10 @@ RTMathBase::time_stamp_t RTMathBase::CreateTimeStamp() {
>      uint32_t t;
>      asm volatile ("mrc p15, 0, %0, c15, c12, 1" : "=r" (t));
>      return t;
> +    #elif defined(__loongarch__) && __loongarch_grlen == 64
> +    uint64_t t;
> +    asm volatile ("rdtime.d %0, $zero" : "=r" (t));
> +    return t;

Could easily be extended for 32-bit, but probably nobody cares for 32-bit
anymore. So that hunk looks fine.

>      #else // we don't want to use a slow generic solution
>      #  error "Sorry, LinuxSampler lacks time stamp code for your system."
>      #  error "Please report this error and the CPU you are using to the
> LinuxSampler developers mailing list!"
> 
> 
> 2. Add generic atomic_sub implementation
> 
> --- a/src/common/atomic.h
> +++ b/src/common/atomic.h
> @@ -1473,6 +1473,11 @@ static __inline__ void atomic_dec(atomic_t *v)
>  	v->counter--;
>  }
> 
> +static __inline__ void atomic_sub(int i, atomic_t *v)
> +{
> +	v->counter -= i;
> +}
> +
>  static __inline__ int atomic_dec_and_test(atomic_t *v)
>  {
>  	int res;
> 
> 
> For the second patch I don't know if generic implementation should have
> atomic_sub but it does not compile without it. Also I guess that it is
> better to have loongarch64 specific atomic but I'm not sure if I'll be able
> to work it out on my own.

Well, yes, I mean it would compile that way, but it wouldn't really be doing
what it should, because all these operations would not be atomic at all.

It's probably not worth bothering writing atomic asm code for loongarch. This
header file is pretty old. What about replacing this fallback section (which
was intended for architectures where we didn't had atomic asm implementations)
by using nowadays compilers' builtin <stdatomic.h> stuff?

/Christian