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

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

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

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

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.

Rui, you don't have a clue either, right?

BTW the auto built binaries look fine. QSampler is correctly linked to latest
libgig etc. So it is really just the cmake --install step on server that's
flawed.

/Christian

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

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

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.



- Even when symlinking to the the old libgig dylib and QSampler opens and the server starts, it does not seem to be able to communicate with the VST plugin at all. The AU plugin does not load on any tested DAW/Host so I cannot test QSampler with the AU. Also, versions previous to 2.4.0 I could at least load an instrument in QSampler even though it could not communicate with the plugin. However, with the latest 2.4.0 version, loading any GIG library crashes QSampler instantly. Obviously, Fantasia would be the better choice but without updated support for newer versions of Java that does not seem possible at the moment.

This is tested on MacOS Sequoia 15.5 on a Mac Mini M4 Pro. I’ve used LinuxSampler quite a bit on both Windows and Linux. I used to use it on Mac pretty extensively in the OSX days before MacOS but not since.

If anyone could take a look it would be much appreciated. Again, this is not an apple silicon compatibility issue. I’m running a few other MacOS intel plugins in Rosetta without issue. Prior to these latest tests, I manually uninstalled all the Linuxsampler package files and then had pgkutil forget the packages before reinstalling the latest version. Please let me know if I can provide any further information.

Much thanks,

TJ Lindgren

[Linuxsampler-devel] LinuxSampler 2.4.0 released

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

Hi everyone,

a new release had been rolled out today:

        o LinuxSampler 2.4.0
        o Gigedit 1.2.2
        o libgig 4.5.0

This is a new feature release. Check the release notes for details:

        http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_4_0/

/Christian

Re: [Linuxsampler-devel] LinuxSampler as a plugin - enabling more than 16 channels

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

On Friday, April 4, 2025 3:15:23 PM CEST Gastón Taylor wrote:
> Hello!

Hi!

> I've been trying to use more than 16 channels in LinuxSampler but I have
> failed once and again. I add a second instance in another REAPER track and
> set a channel both in Qsampler and Jsampler Classic to "Device 1", but it
> doesn't work (I'm mostly using the latest Lv2 version). With the old vst
> version found in KXStudio, it seemed to work at first, but after reloading
> the project everything was messed up - the instrument of the second device
> assigned to the first -. If you have any insight about this, I'll be
> grateful.
> 
> Thanks so much in advance.
> 
> Gastón

Link to previous discussion about this topic:

https://sourceforge.net/p/linuxsampler/mailman/message/37266124/

/Christian

[Linuxsampler-devel] LinuxSampler as a plugin - enabling more than 16 channels

[Gastón T. <tay...@gm...>]

Hello!

I've been trying to use more than 16 channels in LinuxSampler but I have
failed once and again. I add a second instance in another REAPER track and
set a channel both in Qsampler and Jsampler Classic to "Device 1", but it
doesn't work (I'm mostly using the latest Lv2 version). With the old vst
version found in KXStudio, it seemed to work at first, but after reloading
the project everything was messed up - the instrument of the second device
assigned to the first -. If you have any insight about this, I'll be
grateful.

Thanks so much in advance.

Gastón

[Linuxsampler-devel] [ANN] QSampler 1.0.1 - An Early Spring'25 Release

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

Hi all!

   Qsampler 1.0.1 (early-spring'25) is released!

Qsampler [1] is a LinuxSampler [2] GUI front-end application written in 
C++ around the Qt framework using Qt Designer [3].

Change-log:
- Fixed command line parsing (QCommandLineParser/Option) to not exiting 
the application with a segfault when showing help and version information.
- Prepping up next development cycle (Qt >= 6.8)

Website:
   https://qsampler.sourceforge.io
   http://qsampler.sourceforge.net

Project page:
   https://sourceforge.net/projects/qsampler

Downloads:
   https://sourceforge.net/projects/qsampler/files
- source tarballs:
   https://download.sf.net/qsampler/qsampler-1.0.1.tar.gz
   https://download.sf.net/qsampler/liblscp-1.0.1.tar.gz
- source packages:
   https://download.sf.net/qsampler/qsampler-1.0.1-2.1.rncbc.suse.src.rpm
   https://download.sf.net/qsampler/liblscp-1.0.1-2.1.rncbc.suse.src.rpm
- binary packages:
   https://download.sf.net/qsampler/qsampler-1.0.1-2.1.rncbc.suse.x86_64.rpm
   https://download.sf.net/qsampler/liblscp6-1.0.1-2.1.rncbc.suse.x86_64.rpm
  https://download.sf.net/qsampler/liblscp-devel-1.0.1-2.1.rncbc.suse.x86_64.rpm
- AppImage [20] package:
   https://download.sf.net/qsampler/qsampler-1.0.1-2.1.x86_64.AppImage

Git repos:
   https://git.code.sf.net/p/qsampler/code
   https://github.com/rncbc/qsampler.git
   https://gitlab.com/rncbc/qsampler.git
   https://codeberg.com/rncbc/qsampler.git

   https://git.code.sf.net/p/qsampler/liblscp
   https://github.com/rncbc/liblscp.git
   https://gitlab.com/rncbc/liblscp.git
   https://codeberg.com/rncbc/liblscp.git


License:
   Qsampler [1] is free, open-source Linux Audio [4] software, 
distributed under the terms of the GNU General Public License (GPL) 
version 2 or later [5].


References:

  [1] Qsampler - A LinuxSampler Qt GUI Interface
      http://qsampler.sourceforge.net

  [2] LinuxSampler - The Linux Sampler Project
      A modular, streaming capable, realtime audio sampler
      http://www.linuxsampler.org

  [3] Qt framework, C++ class library and tools for
      cross-platform application and UI development
      http://qt.io/

  [4] Linux Audio consortium of libre software for audio-related work
      http://linuxaudio.org

  [5] GPL - GNU General Public License
      http://www.gnu.org/copyleft/gpl.html

  [6] AppImage, Linux apps that run anywhere
      http://appimage.org/


See also:
   https://www.rncbc.org/drupal/node/2748


Enjoy!
- - -
rncbc aka Rui Nuno Capela