linuxsampler-devel

[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

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

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

[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

[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

[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

[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

[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

[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/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 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