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

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

[Linuxsampler-devel] loongarch64 support

[Ilya S. <k0...@al...>]

Hi,

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;
     #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.

Waiting for feedback!

--
Ilya Sorochan

[Linuxsampler-devel] Windows 2.4.0 build will not launch

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

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.

Please let me know if there is any other information that would be
helpful, I will be happy to provide.

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

[Linuxsampler-devel] Warnings when compiling linuxsampler with GCC 15.1.0

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

Hi

We are compiling Linuxsampler with GCC 15.1.0

It compiles well but we get several warnings about :

[-Wdeprecated-declarations]

[-Winconsistent-missing-override]

[-Wimplicit-const-int-float-conversion]

[-Wnull-dereference]

[-Wunused-result]

[-Wnan-infinity-disabled]

[-Wtautological-constant-out-of-range-compare]


And in the end some tags for Doxyfile have become obsolete


As said before that doesn't prevent to compile but that will need 
corrections in the future

I attach an extract of the build.log to locate the parts of code to modify

Hoping this will help

Best Regards (and many thanks for your work)

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

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

Le 18/06/2025 à 12:25, Christian Schoenebeck a écrit :
> On Tuesday, June 17, 2025 2:16:19 AM CEST Philippe DIDIER wrote:
>> Hi
> Hi Philippe,
>
>> We use to create rpms of gig linuxsampler gigedit and qsampler for i686
>> , x86_64 , aarch64  and  armv7hl...
>>
>> There's something wrong when we try to build linuxsampler 2.4.0 for
>> armv7hl :
>>
>> This concerns RTMath.cpp ... We get a build failure with this message :
>>
>> RTMath.cpp:79:19: error: invalid operand for instruction
>>       79 |     asm volatile ("mrs %0, cntvct_el0" : "=r"(t));
>>
>>
>> This is linked to the instructions from line 77 to 80 #elif
>> defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7S__) uint32_t t; asm
>> volatile ("mrs %0, cntvct_el0" : "=r"(t)); return t;
>>
>> Maybe we should use for ARM_ARCH_75
> Yeah, looks like that's an ARMv8 (a.k.a. ARM64) feature.
>
>> the same instruction as for ARMv6 ... that is :
>>       uint32_t t;
>>       asm volatile ("mrc p15, 0, %0, c15, c12, 1" : "=r" (t));
>>       return t;
> 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."
>
> Would be good to know not only if it compiles, but whether it works at
> runtime. Because as you can see from the warning, special privileges or
> preceding system configuration steps might be required for this to work at
> all.
>
> If not, it's getting pretty ugly for the user. Since the sampler would first
> start without complaint and eventually after loading a sound the app would die
> with illegal instruction exception.
>
> /Christian
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel


Hi Christian

We have tested 2 patches (the first from me the second from an other 
packager) :


--- src/common/RTMath.cpp
+++ src/common/RTMath.cpp
@@ -75,9 +75,9 @@
      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;
+    uint32_t t;
+    asm volatile ("mrc p15, 0, %0, c15, c12, 1" : "=r" (t));
+    return t;
      #elif defined(__APPLE__)
      return (time_stamp_t) mach_absolute_time();
      #elif defined(__arm__) /* ARMv6 and older */



--- src/common/RTMath.cpp
+++ src/common/RTMath.cpp
@@ -75,9 +75,9 @@
      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;
+    uint32_t hi, lo;
+    asm volatile ("mrrc p15, 1, %0, %1, c14" : "=r"(lo), "=r" (hi));
+    return lo;
      #elif defined(__APPLE__)
      return (time_stamp_t) mach_absolute_time();
      #elif defined(__arm__) /* ARMv6 and older */


Both of them allow to compile for armv7hl on our BuildSystem
Nevertheless I choosed to apply the first one with
return t   and not      return lo
for coherency with the other arches


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)

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

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

On Tuesday, June 17, 2025 2:16:19 AM CEST Philippe DIDIER wrote:
> Hi

Hi Philippe,

> We use to create rpms of gig linuxsampler gigedit and qsampler for i686
> , x86_64 , aarch64  and  armv7hl...
> 
> There's something wrong when we try to build linuxsampler 2.4.0 for
> armv7hl :
> 
> This concerns RTMath.cpp ... We get a build failure with this message :
> 
> RTMath.cpp:79:19: error: invalid operand for instruction
>      79 |     asm volatile ("mrs %0, cntvct_el0" : "=r"(t));
> 
> 
> This is linked to the instructions from line 77 to 80 #elif
> defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7S__) uint32_t t; asm
> volatile ("mrs %0, cntvct_el0" : "=r"(t)); return t;
> 
> Maybe we should use for ARM_ARCH_75

Yeah, looks like that's an ARMv8 (a.k.a. ARM64) feature.

> the same instruction as for ARMv6 ... that is :
>      uint32_t t;
>      asm volatile ("mrc p15, 0, %0, c15, c12, 1" : "=r" (t));
>      return t;

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."

Would be good to know not only if it compiles, but whether it works at 
runtime. Because as you can see from the warning, special privileges or 
preceding system configuration steps might be required for this to work at 
all.

If not, it's getting pretty ugly for the user. Since the sampler would first 
start without complaint and eventually after loading a sound the app would die 
with illegal instruction exception.

/Christian

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

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

Hi

We use to create rpms of gig linuxsampler gigedit and qsampler for i686 
, x86_64 , aarch64  and  armv7hl...

There's something wrong when we try to build linuxsampler 2.4.0 for 
armv7hl :

This concerns RTMath.cpp ... We get a build failure with this message :

RTMath.cpp:79:19: error: invalid operand for instruction
     79 |     asm volatile ("mrs %0, cntvct_el0" : "=r"(t));


This is linked to the instructions from line 77 to 80 #elif 
defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7S__) uint32_t t; asm 
volatile ("mrs %0, cntvct_el0" : "=r"(t)); return t;

Maybe we should use for ARM_ARCH_75
the same instruction as for ARMv6 ... that is :
     uint32_t t;
     asm volatile ("mrc p15, 0, %0, c15, c12, 1" : "=r" (t));
     return t;

Thanks for your work
and for your help

Philippe

Re: [Linuxsampler-devel] 2.4.0 and 2.3.1 Releases not working on MacOS

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

On Tuesday, June 10, 2025 11:52:32 PM CEST Rui Nuno Capela via Linuxsampler-
devel wrote:
> On 6/10/25 22:11, Christian Schoenebeck wrote:
[...]
> > I saw that you also added an optional installation of Qt onto the system.
> > While that probably makes sense for Windows, on a Mac the common way is to
> > just include the required Qt libraries (as "frameworks") with qsampler's
> > app bundle (i.e. inside that "qsampler.app" directory).
> 
> so you think that's superfluous?
> 
> just say yes and I'll remove that as unnecessary...

Hmm, after reading the Qt documentation on this, I realized the purpose of 
windeployqt / macdeployqt is something else. I thought it was a Qt installer. 
It is not. It is run against a compiled Qt application binary (e.g. 
qsampler.exe) and it would modify the executable (replacing absolute DLL paths 
by relative ones) and adds all required Qt libraries to the directory of the 
executable so that the Qt executable would run *without* installing Qt.

I am not sure where you got that CMake block from, apparently this block is 
just run if CONFIG_INSTALL_QT was explicitly set by the user from the command 
line?

I would leave it there for now. It might be useful in future when we change 
the entire installation packages to work with pure app bundles (i.e. to allow 
installing without admin permissions in future and avoiding DLL version 
conflicts).

/Christian

Re: [Linuxsampler-devel] 2.4.0 and 2.3.1 Releases not working on MacOS

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

On 6/10/25 22:11, Christian Schoenebeck wrote:
> On Tuesday, June 10, 2025 9:38:26 PM CEST Rui Nuno Capela via Linuxsampler-devel wrote:
>> On 6/6/25 17:34, Rui Nuno Capela via Linuxsampler-devel wrote:
>>> On 6/6/25 10:52, Christian Schoenebeck wrote:
>>>> The problem rather is *what* cmake installs. For the QSampler Mac
>>>> build cmake
>>>> does not install any file at all:
>>>>
>>>>     + cmake --install build --prefix /home/persson/mac64/ --verbose
>>>>     -- Install configuration: "Release"
>>>>
>>>> For the QSampler Windows build cmake only installs the translation
>>>> files, but
>>>> not the most relevant file qsampler.exe:
>>>>
>>>>     + cmake --install build --verbose
>>>>     -- Install configuration: "Release"
>>>>     -- Up-to-date: /home/persson/win32/share/qsampler/translations/
>>>> qsampler_cs.qm
>>>>     -- Up-to-date: /home/persson/win32/share/qsampler/translations/
>>>> qsampler_fr.qm
>>>>     -- Up-to-date: /home/persson/win32/share/qsampler/translations/
>>>> qsampler_ru.qm
>>>>
>>>> Like described in my previous email, cmake --install looks into the file
>>>> ./build/install_manifest.txt to determine what to install. In case of the
>>>> Windows build that file only contains those 3 translation files, and
>>>> in case
>>>> of the Mac build that file is completely empty.
>>>
>>> oh, no, now I recall that the qsampler's src/CMakeLists,txt rules for
>>> install is severely incomplete (or missing the ".exe" suffix) on windows
>>> and completely absent for macos...
>>>
>>> sorry
>>
>> but there's something now... :)
>>
>> however these have been "blindly" pasted from elsewhere and there are no
>> guarantee whatsoever that it will ever work on windows or macos resp.
> 
> Yeah, I think it's OK. Thanks Rui!
> 

great!

> 
> I saw that you also added an optional installation of Qt onto the system.
> While that probably makes sense for Windows, on a Mac the common way is to
> just include the required Qt libraries (as "frameworks") with qsampler's app
> bundle (i.e. inside that "qsampler.app" directory).
> 

so you think that's superfluous?

just say yes and I'll remove that as unnecessary...

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

Re: [Linuxsampler-devel] 2.4.0 and 2.3.1 Releases not working on MacOS

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

On Tuesday, June 10, 2025 9:38:26 PM CEST Rui Nuno Capela via Linuxsampler-devel wrote:
> On 6/6/25 17:34, Rui Nuno Capela via Linuxsampler-devel wrote:
> > On 6/6/25 10:52, Christian Schoenebeck wrote:
> >> The problem rather is *what* cmake installs. For the QSampler Mac
> >> build cmake
> >> does not install any file at all:
> >> 
> >>    + cmake --install build --prefix /home/persson/mac64/ --verbose
> >>    -- Install configuration: "Release"
> >> 
> >> For the QSampler Windows build cmake only installs the translation
> >> files, but
> >> not the most relevant file qsampler.exe:
> >> 
> >>    + cmake --install build --verbose
> >>    -- Install configuration: "Release"
> >>    -- Up-to-date: /home/persson/win32/share/qsampler/translations/
> >> qsampler_cs.qm
> >>    -- Up-to-date: /home/persson/win32/share/qsampler/translations/
> >> qsampler_fr.qm
> >>    -- Up-to-date: /home/persson/win32/share/qsampler/translations/
> >> qsampler_ru.qm
> >> 
> >> Like described in my previous email, cmake --install looks into the file
> >> ./build/install_manifest.txt to determine what to install. In case of the
> >> Windows build that file only contains those 3 translation files, and
> >> in case
> >> of the Mac build that file is completely empty.
> > 
> > oh, no, now I recall that the qsampler's src/CMakeLists,txt rules for
> > install is severely incomplete (or missing the ".exe" suffix) on windows
> > and completely absent for macos...
> > 
> > sorry
> 
> but there's something now... :)
> 
> however these have been "blindly" pasted from elsewhere and there are no
> guarantee whatsoever that it will ever work on windows or macos resp.

Yeah, I think it's OK. Thanks Rui!

For the Windows target cmake now correctly installs qsampler.exe:

  + cmake --install build --verbose
  -- Install configuration: "Release"
  -- Installing: /home/persson/win32/bin/qsampler.exe
  -- Up-to-date: /home/persson/win32/share/qsampler/translations/qsampler_cs.qm
  -- Up-to-date: /home/persson/win32/share/qsampler/translations/qsampler_fr.qm
  -- Up-to-date: /home/persson/win32/share/qsampler/translations/qsampler_ru.qm

And for the Mac target it installs the qsampler app bundle:

  + cmake --install build --prefix /home/persson/mac64/ --verbose
  -- Install configuration: "Release"
  -- Up-to-date: /home/persson/mac64/bin/qsampler.app
  -- Up-to-date: /home/persson/mac64/bin/qsampler.app/Contents
  -- Up-to-date: /home/persson/mac64/bin/qsampler.app/Contents/Resources
  -- Up-to-date: /home/persson/mac64/bin/qsampler.app/Contents/Resources/qsampler.icns
  -- Up-to-date: /home/persson/mac64/bin/qsampler.app/Contents/Info.plist
  -- Up-to-date: /home/persson/mac64/bin/qsampler.app/Contents/MacOS
  -- Up-to-date: /home/persson/mac64/bin/qsampler.app/Contents/MacOS/qsampler
  -- Installing: /home/persson/mac64/share/qsampler/translations/qsampler_cs.qm
  -- Installing: /home/persson/mac64/share/qsampler/translations/qsampler_fr.qm
  -- Installing: /home/persson/mac64/share/qsampler/translations/qsampler_ru.qm

I saw that you also added an optional installation of Qt onto the system.
While that probably makes sense for Windows, on a Mac the common way is to
just include the required Qt libraries (as "frameworks") with qsampler's app
bundle (i.e. inside that "qsampler.app" directory).

/Christian

Re: [Linuxsampler-devel] 2.4.0 and 2.3.1 Releases not working on MacOS

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

On 6/6/25 17:34, Rui Nuno Capela via Linuxsampler-devel wrote:
> On 6/6/25 10:52, Christian Schoenebeck wrote:
>>
>> The problem rather is *what* cmake installs. For the QSampler Mac 
>> build cmake
>> does not install any file at all:
>>
>>    + cmake --install build --prefix /home/persson/mac64/ --verbose
>>    -- Install configuration: "Release"
>>
>> For the QSampler Windows build cmake only installs the translation 
>> files, but
>> not the most relevant file qsampler.exe:
>>
>>    + cmake --install build --verbose
>>    -- Install configuration: "Release"
>>    -- Up-to-date: /home/persson/win32/share/qsampler/translations/ 
>> qsampler_cs.qm
>>    -- Up-to-date: /home/persson/win32/share/qsampler/translations/ 
>> qsampler_fr.qm
>>    -- Up-to-date: /home/persson/win32/share/qsampler/translations/ 
>> qsampler_ru.qm
>>
>> Like described in my previous email, cmake --install looks into the file
>> ./build/install_manifest.txt to determine what to install. In case of the
>> Windows build that file only contains those 3 translation files, and 
>> in case
>> of the Mac build that file is completely empty.
>>
> 
> oh, no, now I recall that the qsampler's src/CMakeLists,txt rules for 
> install is severely incomplete (or missing the ".exe" suffix) on windows 
> and completely absent for macos...
> 
> sorry

but there's something now... :)

however these have been "blindly" pasted from elsewhere and there are no 
guarantee whatsoever that it will ever work on windows or macos resp.

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

Re: [Linuxsampler-devel] 2.4.0 and 2.3.1 Releases not working on MacOS

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

On 6/6/25 10:52, Christian Schoenebeck wrote:
> On Thursday, June 5, 2025 5:17:13 PM CEST Rui Nuno Capela via Linuxsampler-devel wrote:
>> On 6/5/25 11:34, Christian Schoenebeck wrote:
>>> On Tuesday, June 3, 2025 8:53:36 PM CEST TJ Lindgren via
>>> Linuxsampler-devel wrote:
>>>
>>> The problem I have is, I don't see an obvious way how to output where
>>> cmake is installing to, or how exactly. I tried the only documented way
>>> which is>
>>> 	cmake --install build --verbose
>>>
>>> But that does not output anything more than without --verbose.
>>>
>>> Rui, you don't have a clue either, right?
>>
>> Yes I do, use the following spell:
>>
>> # configure:
>> cmake -DCMAKE_INSTALL_PREFIX=$PREFIX -B build
>>
>> # build:
>> cmake --build build
>>
>> # install: much like for make DESTDIR env var might be handy here: \
>> cmake --install build
> 
> The install prefix controls *where* cmake installs to. We already had the
> prefix set and cmake picks up the requested install prefix correctly (both via
> CMAKE_INSTALL_PREFIX variable, as well as via --prefix option, doesn't
> matter).
> 
> The problem rather is *what* cmake installs. For the QSampler Mac build cmake
> does not install any file at all:
> 
>    + cmake --install build --prefix /home/persson/mac64/ --verbose
>    -- Install configuration: "Release"
> 
> For the QSampler Windows build cmake only installs the translation files, but
> not the most relevant file qsampler.exe:
> 
>    + cmake --install build --verbose
>    -- Install configuration: "Release"
>    -- Up-to-date: /home/persson/win32/share/qsampler/translations/qsampler_cs.qm
>    -- Up-to-date: /home/persson/win32/share/qsampler/translations/qsampler_fr.qm
>    -- Up-to-date: /home/persson/win32/share/qsampler/translations/qsampler_ru.qm
> 
> Like described in my previous email, cmake --install looks into the file
> ./build/install_manifest.txt to determine what to install. In case of the
> Windows build that file only contains those 3 translation files, and in case
> of the Mac build that file is completely empty.
> 

oh, no, now I recall that the qsampler's src/CMakeLists,txt rules for 
install is severely incomplete (or missing the ".exe" suffix) on windows 
and completely absent for macos...

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

Re: [Linuxsampler-devel] 2.4.0 and 2.3.1 Releases not working on MacOS

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

On Thursday, June 5, 2025 5:17:13 PM CEST Rui Nuno Capela via Linuxsampler-devel wrote:
> On 6/5/25 11:34, Christian Schoenebeck wrote:
> > On Tuesday, June 3, 2025 8:53:36 PM CEST TJ Lindgren via
> > Linuxsampler-devel wrote:
> > 
> > The problem I have is, I don't see an obvious way how to output where
> > cmake is installing to, or how exactly. I tried the only documented way
> > which is> 
> > 	cmake --install build --verbose
> > 
> > But that does not output anything more than without --verbose.
> > 
> > Rui, you don't have a clue either, right?
> 
> Yes I do, use the following spell:
> 
> # configure:
> cmake -DCMAKE_INSTALL_PREFIX=$PREFIX -B build
> 
> # build:
> cmake --build build
> 
> # install: much like for make DESTDIR env var might be handy here: \
> cmake --install build

The install prefix controls *where* cmake installs to. We already had the
prefix set and cmake picks up the requested install prefix correctly (both via
CMAKE_INSTALL_PREFIX variable, as well as via --prefix option, doesn't
matter).

The problem rather is *what* cmake installs. For the QSampler Mac build cmake
does not install any file at all:

  + cmake --install build --prefix /home/persson/mac64/ --verbose
  -- Install configuration: "Release"

For the QSampler Windows build cmake only installs the translation files, but
not the most relevant file qsampler.exe:

  + cmake --install build --verbose
  -- Install configuration: "Release"
  -- Up-to-date: /home/persson/win32/share/qsampler/translations/qsampler_cs.qm
  -- Up-to-date: /home/persson/win32/share/qsampler/translations/qsampler_fr.qm
  -- Up-to-date: /home/persson/win32/share/qsampler/translations/qsampler_ru.qm

Like described in my previous email, cmake --install looks into the file
./build/install_manifest.txt to determine what to install. In case of the
Windows build that file only contains those 3 translation files, and in case
of the Mac build that file is completely empty.

/Christian

Re: [Linuxsampler-devel] 2.4.0 and 2.3.1 Releases not working on MacOS

[TJ L. <tjl...@ma...>]

Thanks, I just grabbed this and replaced the previous version of Fantasia. Unfortunately, it doesn’t open. Not sure if this is a MacOS signing issue or not.




TJL



> On Jun 5, 2025, at 8:09 AM, Grigor Iliev <gr....@gm...> wrote:
> 
> > - When loading the VST plugin, it is trying to open Fantasia as it does on Windows. However, Fantasia is using a very old version of Java that cannot run in MacOS so Fantasia cannot open. There used to be a workaround to use an older version of JavaApplicationStub, however the version used for Fantasia seems to be deprecated on recent versions of MacOS.
> 
> You can try with latest Fantasia version. It doesn't require installed Java (JRE):
> 
> https://github.com/grigoriliev/jsampler-fantasia/releases/tag/jsampler-fantasia-0.9.7

Re: [Linuxsampler-devel] 2.4.0 and 2.3.1 Releases not working on MacOS

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

On 6/5/25 11:34, Christian Schoenebeck wrote:
> On Tuesday, June 3, 2025 8:53:36 PM CEST TJ Lindgren via Linuxsampler-devel wrote:
> 
> The problem I have is, I don't see an obvious way how to output where cmake is
> installing to, or how exactly. I tried the only documented way which is
> 
> 	cmake --install build --verbose
> 
> But that does not output anything more than without --verbose.
> 
> Rui, you don't have a clue either, right?
> 

Yes I do, use the following spell:

# configure:
cmake -DCMAKE_INSTALL_PREFIX=$PREFIX -B build

# build:
cmake --build build

# install: much like for make DESTDIR env var might be handy here: \
cmake --install build


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

Re: [Linuxsampler-devel] 2.4.0 and 2.3.1 Releases not working on MacOS

[Grigor I. <gr....@gm...>]

> - When loading the VST plugin, it is trying to open Fantasia as it does
on Windows. However, Fantasia is using a very old version of Java that
cannot run in MacOS so Fantasia cannot open. There used to be a workaround
to use an older version of JavaApplicationStub, however the version used
for Fantasia seems to be deprecated on recent versions of MacOS.

You can try with latest Fantasia version. It doesn't require installed Java
(JRE):

https://github.com/grigoriliev/jsampler-fantasia/releases/tag/jsampler-fantasia-0.9.7

Re: [Linuxsampler-devel] 2.4.0 and 2.3.1 Releases not working on MacOS

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

On Thursday, June 5, 2025 12:34:40 PM CEST Christian Schoenebeck wrote:
> On Tuesday, June 3, 2025 8:53:36 PM CEST TJ Lindgren via Linuxsampler-devel wrote:
> > Has anyone tested Linuxsampler with a recent version of MacOS? I cannot
> > get
> > LinuxSampler working at all. Obviously, it’s not apple silicon but there
> > are several issues preventing LinuxSampler from working it seems.
> > 
> > - When loading the VST plugin, it is trying to open Fantasia as it does on
> > Windows. However, Fantasia is using a very old version of Java that cannot
> > run in MacOS so Fantasia cannot open. There used to be a workaround to use
> > an older version of JavaApplicationStub, however the version used for
> > Fantasia seems to be deprecated on recent versions of MacOS.
> > 
> > 
> > 
> > - The AU plugin does not load at all. This includes versions previous to
> > 2.4.0 as well as the most recent 2.4.0 release.
> > 
> > 
> > 
> > - Both the VST and AU plugins do not scan correctly in several hosts. For
> > example, the VST scans correctly in Reaper but not the AU. In Plogue
> > Bidule, neither the VST or AU scan. In MainStage/Logic (AU support only)
> > the AU does not scan.
> > 
> > - QSampler requires libgig.10.dylib even though libgig.11.dylib was
> > installed for previous versions (2.3.1)  and libgig.12.dylib for the most
> > recent version (2.4.0). So in order to open QSampler, you have to symlink
> > the libgig file and rename it to libgig.10.dylib.
> 
> Mja, confirmed. The Mac installer actually ships an ancient version of
> QSampler and liblscp. This issue exists since the transition of liblscp/
> QSampler from autoconf to CMake.
> 
> I guess the same applies to the Windows installer.
> 
> The thing is, the binaries are automatically built on our server. Once they
> are (re)built, they have to be installed into a specific directory on our
> server for the Mac/Win installer scripts to grab them up.
> 
> The problem I have is, I don't see an obvious way how to output where cmake
> is installing to, or how exactly. I tried the only documented way which is
> 
> 	cmake --install build --verbose
> 
> But that does not output anything more than without --verbose.

OK, I checked with strace what cmake --install actually does: it does not
install anything. It looks into a file ./build/install_manifest.txt, which is
completely empty, then it stops.

No idea why cmake generates an empty install_manifest.txt file. I just
manually wrote some install shell commands for QSampler instead.

I replaced the stable Mac installer link with the corrected Mac installer on
the website.

If I find some time I'll probably send a patch for cmake. Because honestly,
now matter why that file is empty, IMO cmake should error out when a user
tries "cmake --install" and cmake not installing anything.

/Christian