I took the liberty to move this over to pd-dev
On Fri, 2021-01-08 at 03:48 -0300, Alexandre Torres Porres wrote:
Em qui., 7 de jan. de 2021 às 20:07, Roman Haefeli < reduzent@gmail.com> escreveu:
On Thu, 2021-01-07 at 00:14 -0300, Alexandre Torres Porres wrote:
we still need to sort this for linux,
Since you seem you got it sorted (and I figured out how to compile fluidsynth with no additional deps)
how did that go?
I just updated pd-fluidsynth repo to get your and Lucas' most recent changes. I didn't have to modify anything for the build process to work.
~~~sh cd pd-fluidsynth make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32 make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32 install cd $HOME/pd-src/workspace/Linux-arm7-32/fluid~ sh linuxdep32.sh rm linuxdep32 ~~~
However, the crucial part is that the included libfluidsynth.so should not be "tainted" with support for all kinds of things. This means, you can't take the one shipped by the distro.
Can you describe the steps and put it in our readme (with a PR)?
You mean what steps were necessary to compile fluidsynth? I didn't have to do anything suprising or special. I just had to figure out how to disable everything by reading the docs about building. This is what I came up with (I hope it is correct and complete):
~~~sh git clone https://github.com/FluidSynth/fluidsynth/ cd fluidsynth mkdir build cd build cmake -Denable-libsndfile=off -Denable-jack=off -Denable-alsa=off -Denable-oss=off -Denable-pulseaudio=off -Denable-ladspa=off -Denable-aufile=off -Denable-network=off -Denable-ipv6=off -Denable-getopt=off -Denable-sdl2=off .. make sudo make install ~~~
After this, I compiled fluid~ with steps from above.
Regarding the makefile of pd-fluidsynth, I don't understand the purpose of this section:
--- define forLinux
ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686) datafiles += scripts/linuxdep32.sh else datafiles += scripts/linuxdep64.sh endif
endef ---
Depending on which arch is detected, it'll add one or the other script in the build result. I think what this is meant to do is to _execute_ the arch specific script, so that libraries get included. I'm not yet familiar with makefiles to tell you just right away how this is done, but according to the snippet, I'd suppose something like this:
--- define forLinux
ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686) $(shell /bin/sh scripts/linuxdep32.sh) else $(shell /bin/sh scripts/linuxdep32.sh) endif
endef ---
In order to include the additional dynamic libraries, you'd add 'libfluidsynth.so*' to 'datafiles'.
However, the above detection fails for arm7 and it'll wrongly executes scripts/linuxdep64.sh. I think instead of an if-else, it could detect the arch and execute the appropriate script with arch in the name. If the scripts for several archs turn out to be the same, they could be symlinked. Just an idea.
Another thing about scripts/linuxdep*.sh script. I think they should call cp with the -d flag. Without it, it creates three full copies of the same .so file. With -d symlinks are preserved.
I realize it's a lot of suggestions. Sorry for that. So maybe a PR would be easier for you to digest. Thing is I don't feel yet sufficiently confident with these matters, but am happy to learn.
Roman
sh linuxdep32.sh rm linuxdep32
However, the crucial part is that the included libfluidsynth.so should not be "tainted" with support for all kinds of things. This means, you can't take the one shipped by the distro.
Why not?
but according to the snippet, I'd suppose something like this:
define forLinux
ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686) $(shell /bin/sh scripts/linuxdep32.sh) else $(shell /bin/sh scripts/linuxdep32.sh) endif
endef
But then how do you know *where* to copy the .so files. I mean the output dir for fluid~.
I still don't know if its possible to do the "for files .." from inside the makefile. That will be cool : "for filename in foo cp $filename $installdir"
Now that i write this there might it sounds possible pass an argument to the script:
$(shell /bin/sh scripts/linuxdep32.sh $installdir)
had to check if this script runs after fluid~ was built.
However, the above detection fails for arm7 and it'll wrongly executes scripts/linuxdep64.sh. I think instead of an if-else, it could detect the arch and execute the appropriate script with arch in the name.
Can you check what gives info you an arm7 ik you do:
make allvars
Another thing about scripts/linuxdep*.sh script. I think they should call cp with the -d flag. Without it, it creates three full copies of the same .so file. With -d symlinks are preserved.
We can test that but the symlinks are in the original folder. May be they are needed as is.
Thing is I don't feel yet sufficiently confident with these matters, but am happy to learn.
Me to. :)
There is something i'm worried: I think this linux aproach does not loads sf3. as far from what i read (never used sound fonts or fluidsynth) the sf3 can have compressed audio files with FLAC/Vorvis/etc. These dependencies are there on the win and mac versions.
more:
My first shoot to compile on debian buster was
apt-cache search fluidsynth
I got that and a -dev pkg which i installed.
then the [fluid~] object didn't load saying:
fluid~.pd_linux: undefined symbol: fluid_synth_key_pressure
So then I compiled the latest fluidsynth and it worked.
Now I didn't get fluidsynth*2* whith apt-cache. Why you get the fluidsynth*2* pkg?
--
Mensaje telepatico asistido por maquinas.
On 1/8/2021 6:16 AM, Roman Haefeli wrote:
I took the liberty to move this over to pd-dev
On Fri, 2021-01-08 at 03:48 -0300, Alexandre Torres Porres wrote:
Em qui., 7 de jan. de 2021 às 20:07, Roman Haefeli < reduzent@gmail.com> escreveu:
On Thu, 2021-01-07 at 00:14 -0300, Alexandre Torres Porres wrote:
we still need to sort this for linux,
Since you seem you got it sorted (and I figured out how to compile fluidsynth with no additional deps)
how did that go?
I just updated pd-fluidsynth repo to get your and Lucas' most recent changes. I didn't have to modify anything for the build process to work.
cd pd-fluidsynth make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32 make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32 install cd $HOME/pd-src/workspace/Linux-arm7-32/fluid~ sh linuxdep32.sh rm linuxdep32However, the crucial part is that the included libfluidsynth.so should not be "tainted" with support for all kinds of things. This means, you can't take the one shipped by the distro.
Can you describe the steps and put it in our readme (with a PR)?
You mean what steps were necessary to compile fluidsynth? I didn't have to do anything suprising or special. I just had to figure out how to disable everything by reading the docs about building. This is what I came up with (I hope it is correct and complete):
git clone https://github.com/FluidSynth/fluidsynth/ cd fluidsynth mkdir build cd build cmake -Denable-libsndfile=off -Denable-jack=off -Denable-alsa=off -Denable-oss=off -Denable-pulseaudio=off -Denable-ladspa=off -Denable-aufile=off -Denable-network=off -Denable-ipv6=off -Denable-getopt=off -Denable-sdl2=off .. make sudo make installAfter this, I compiled fluid~ with steps from above.
Regarding the makefile of pd-fluidsynth, I don't understand the purpose of this section:
define forLinux
ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686) datafiles += scripts/linuxdep32.sh else datafiles += scripts/linuxdep64.sh endif
endef
Depending on which arch is detected, it'll add one or the other script in the build result. I think what this is meant to do is to _execute_ the arch specific script, so that libraries get included. I'm not yet familiar with makefiles to tell you just right away how this is done, but according to the snippet, I'd suppose something like this:
define forLinux
ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686) $(shell /bin/sh scripts/linuxdep32.sh) else $(shell /bin/sh scripts/linuxdep32.sh) endif
endef
In order to include the additional dynamic libraries, you'd add 'libfluidsynth.so*' to 'datafiles'.
However, the above detection fails for arm7 and it'll wrongly executes scripts/linuxdep64.sh. I think instead of an if-else, it could detect the arch and execute the appropriate script with arch in the name. If the scripts for several archs turn out to be the same, they could be symlinked. Just an idea.
Another thing about scripts/linuxdep*.sh script. I think they should call cp with the -d flag. Without it, it creates three full copies of the same .so file. With -d symlinks are preserved.
I realize it's a lot of suggestions. Sorry for that. So maybe a PR would be easier for you to digest. Thing is I don't feel yet sufficiently confident with these matters, but am happy to learn.
Roman
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Fri, 2021-01-08 at 07:13 -0300, Lucas Cordiviola wrote:
sh linuxdep32.sh rm linuxdep32
However, the crucial part is that the included libfluidsynth.so should not be "tainted" with support for all kinds of things. This means, you can't take the one shipped by the distro.Why not?
Because:
ldd /usr/lib/x86_64-linux-gnu/libfluidsynth.so.2 linux-vdso.so.1 (0x00007ffca270b000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f4536a8b000) libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f4536a85000) libjack.so.0 => /lib/x86_64-linux-gnu/libjack.so.0 (0x00007f4536a39000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4536a16000) libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007f453691b000) libpulse-simple.so.0 => /lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f4536914000) libsndfile.so.1 => /lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f4536895000) libSDL2-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f4536740000) libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f45366ef000) libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 (0x00007f453669f000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4536550000) libinstpatch-1.0.so.2 => /lib/x86_64-linux-gnu/libinstpatch-1.0.so.2 (0x00007f4536495000) libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f4536433000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4536241000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f45361ce000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f45361c8000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f45361bd000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4535fdc000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4535fbf000) /lib64/ld-linux-x86-64.so.2 (0x00007f4536cae000) libpulse.so.0 => /lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f4535f6a000) libpulsecommon-13.99.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so (0x00007f4535ee8000) libFLAC.so.8 => /lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f4535eaa000) libogg.so.0 => /lib/x86_64-linux-gnu/libogg.so.0 (0x00007f4535e9d000) libvorbis.so.0 => /lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f4535e6d000) libvorbisenc.so.2 => /lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f4535dc2000) libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f4535c85000) libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f4535c70000) libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f4535c63000) libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f4535c5e000) libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007f4535c4a000) libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f4535c3d000) libXss.so.1 => /lib/x86_64-linux-gnu/libXss.so.1 (0x00007f4535c38000) libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f4535c31000) libwayland-egl.so.1 => /lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007f4535c2c000) libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f4535c1b000) libwayland-cursor.so.0 => /lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f4535c0e000) libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f4535bcc000) libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f4535b1d000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f4535aed000) libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007f4535ae1000) libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f4535ab5000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f4535aa9000) libasyncns.so.0 => /lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f45358a3000) libapparmor.so.1 => /lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007f453588e000) libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f4535684000) libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f453567a000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f4535651000) liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f4535630000) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f4535512000) libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f453550c000) libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f4535502000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f45354e5000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f45354c9000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f45354a6000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f453548c000)
but according to the snippet, I'd suppose something like this:
define forLinux
ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686) $(shell /bin/sh scripts/linuxdep32.sh) else $(shell /bin/sh scripts/linuxdep32.sh) endif
endef
But then how do you know *where* to copy the .so files. I mean the output dir for fluid~.
I still don't know if its possible to do the "for files .." from inside the makefile. That will be cool : "for filename in foo cp $filename $installdir"
Now that i write this there might it sounds possible pass an argument to the script:
$(shell /bin/sh scripts/linuxdep32.sh $installdir)
had to check if this script runs after fluid~ was built.
However, the above detection fails for arm7 and it'll wrongly executes scripts/linuxdep64.sh. I think instead of an if-else, it could detect the arch and execute the appropriate script with arch in the name.
Can you check what gives info you an arm7 ik you do:
make allvars
variable (file) target.arch = arm variable (file) target.triplet = arm linux gnueabihf
and gcc -dumpmachine gives me:
arm-linux-gnueabihf
Another thing about scripts/linuxdep*.sh script. I think they should call cp with the -d flag. Without it, it creates three full copies of the same .so file. With -d symlinks are preserved.
We can test that but the symlinks are in the original folder. May be they are needed as is.
My point is exactly to preserve them. They are not technically needed, but I'd like to preserve them just to not bloat the package unnecessarily. Simply using cp turns symlinks into separate copies.
Thing is I don't feel yet sufficiently confident with these matters, but am happy to learn.
Me to. :) There is something i'm worried: I think this linux aproach does not loads sf3. as far from what i read (never used sound fonts or fluidsynth) the sf3 can have compressed audio files with FLAC/Vorvis/etc.
Well spotted. I haven't tried sf3. This means flac and vorbis shouldn't be disabled when building fluidsynth. This also means more libraries need to be shipped.
These dependencies are there on the win and mac versions.
Ok, good to know. Would be good to have same support for all platforms.
more:
My first shoot to compile on debian buster was
apt-cache search fluidsynth
I got that and a -dev pkg which i installed.
then the [fluid~] object didn't load saying:
fluid~.pd_linux: undefined symbol: fluid_synth_key_pressure
So then I compiled the latest fluidsynth and it worked.
Now I didn't get fluidsynth*2* whith apt-cache. Why you get the fluidsynth*2* pkg?
Ah, I see. Ubuntu 20.04 and Debian Buster ship different versions of fluidsynth.
Roman
On 1/8/21 10:16 AM, Roman Haefeli wrote:
I took the liberty to move this over to pd-dev
On Fri, 2021-01-08 at 03:48 -0300, Alexandre Torres Porres wrote:
Em qui., 7 de jan. de 2021 às 20:07, Roman Haefeli < reduzent@gmail.com> escreveu:
On Thu, 2021-01-07 at 00:14 -0300, Alexandre Torres Porres wrote:
we still need to sort this for linux,
Since you seem you got it sorted (and I figured out how to compile fluidsynth with no additional deps)
how did that go?
I just updated pd-fluidsynth repo to get your and Lucas' most recent changes. I didn't have to modify anything for the build process to work.
cd pd-fluidsynth make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32 make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32 install cd $HOME/pd-src/workspace/Linux-arm7-32/fluid~ sh linuxdep32.sh rm linuxdep32However, the crucial part is that the included libfluidsynth.so should not be "tainted" with support for all kinds of things. This means, you can't take the one shipped by the distro.
Can you describe the steps and put it in our readme (with a PR)?
You mean what steps were necessary to compile fluidsynth? I didn't have to do anything suprising or special. I just had to figure out how to disable everything by reading the docs about building. This is what I came up with (I hope it is correct and complete):
git clone https://github.com/FluidSynth/fluidsynth/ cd fluidsynth mkdir build cd build cmake -Denable-libsndfile=off -Denable-jack=off -Denable-alsa=off -Denable-oss=off -Denable-pulseaudio=off -Denable-ladspa=off -Denable-aufile=off -Denable-network=off -Denable-ipv6=off -Denable-getopt=off -Denable-sdl2=off .. make sudo make installAfter this, I compiled fluid~ with steps from above. tot Regarding the makefile of pd-fluidsynth, I don't understand the purpose of this section:
define forLinux
ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686) datafiles += scripts/linuxdep32.sh else datafiles += scripts/linuxdep64.sh endif
endef
Depending on which arch is detected, it'll add one or the other script in the build result.
that seems all wrong: why would you want to install one of these script based on the build architecture?
apart from that: the linuxdep*.sh scripts seem to be quite bogus. you really should evaluate the dependencies of the fluid~.pd_linux file to see where these libraries are to be found. rather than assuming they are installed in /usr/local/lib/ resp /usr/local/lib64/ (the latter directory is only used on fedora based systems), use `ldd`. this will allow you to get libraries from /usr/lib/, /usr/local/lib/i386-linux-gnu/ or wherever your dynamic linker would take the libfluidsynth-library from.
I think what this is meant to do is to _execute_ the arch specific script, so that libraries get included. I'm not yet
if you follow my advise, there is no need to use *arch* specific scripts (you need different scripts for different dynamic linking mechanisms, so that's why my original scripts are for windows (dll), macOS (dylib),...; but there's no need for the scripts to be aware of the CPU-type - as long as you use the system provided tools to resolved dependencies.
familiar with makefiles to tell you just right away how this is done, but according to the snippet, I'd suppose something like this:
define forLinux
ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686) $(shell /bin/sh scripts/linuxdep32.sh) else $(shell /bin/sh scripts/linuxdep32.sh) endif
now there are a couple of things with this: - first you don't need the complicated architecture evaluation, if you do the same thing regardless of the result - then, there is no proper definition *when* the script is run. basically it is run whenever you execute `make`, even if you run e.g. `make clean`. - finally, the collection of dependencies should *never* be part of the ordinary build process (`make`, `make all`, `make install`, `make uninstall`, `make clean`,...). if you think you *must* include the code in the Makefile, then it should be a separate target, that is only called explicitely, e.g. via `make installdependencies`.
most likely, this should be a post-install operation (respecting DESTDIR and similar variables).
for the sake of simplicity, i would do something like:
~~~ install+dependencies: install ./scripts/dependendencies "${installpath}" "${extension}" ~~~
in in ./scripts/dependencies search all files with the ${extension}-suffix in "${installpath}" and run an OS-dependent script on them.
gfmdsar IOhannes
On Fri, 2021-01-08 at 12:29 +0100, IOhannes m zmölnig wrote:
that seems all wrong:
Thanks for chiming in and for your voice of reason. Clearly, I only have a half-baked understanding of what the purpose of those scripts is.
I'll try to wrap what you said up into a PR when I find time. Hopefully, we'll be able to create fluid~ that also supports sf3 files.
Roman
Em sex., 8 de jan. de 2021 às 08:48, Roman Haefeli reduzent@gmail.com escreveu:
Hopefully, we'll be able to create fluid~ that also supports sf3 files.
I thought we already did :) but hey, yeah, can't wee why not to do that...
On Fri, 2021-01-08 at 11:23 -0300, Alexandre Torres Porres wrote:
Em sex., 8 de jan. de 2021 às 08:48, Roman Haefeli < reduzent@gmail.com> escreveu:
Hopefully, we'll be able to create fluid~ that also supports sf3 files.
I thought we already did :) but hey, yeah, can't wee why not to do that...
Apparently, only for Windows and macOS, not yet for Linux. When I load an SF3-file, I get:
--- fluidsynth: warning: Sound font version is 3.0 but fluidsynth was compiled without support for (v3.x) fluidsynth: error: Failed to load SoundFont "hedorgan.sf3" ---
From what I understand, it's only a matter of compiling fluidsynth with libsndfile support. I have libsndfile and development files installed, but cmake of fluidsynth doesn't detect it. Have to figure out why.
Roman
ok, yeah, I just tested here on the mac and could load hedOrgv75.sf3
Em sex., 8 de jan. de 2021 às 12:11, Roman Haefeli reduzent@gmail.com escreveu:
On Fri, 2021-01-08 at 11:23 -0300, Alexandre Torres Porres wrote:
Em sex., 8 de jan. de 2021 às 08:48, Roman Haefeli < reduzent@gmail.com> escreveu:
Hopefully, we'll be able to create fluid~ that also supports sf3 files.
I thought we already did :) but hey, yeah, can't wee why not to do that...
Apparently, only for Windows and macOS, not yet for Linux. When I load an SF3-file, I get:
fluidsynth: warning: Sound font version is 3.0 but fluidsynth was compiled without support for (v3.x) fluidsynth: error: Failed to load SoundFont "hedorgan.sf3"
From what I understand, it's only a matter of compiling fluidsynth with libsndfile support. I have libsndfile and development files installed, but cmake of fluidsynth doesn't detect it. Have to figure out why.
Roman _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Fri, 2021-01-08 at 12:47 +0100, Roman Haefeli wrote:
On Fri, 2021-01-08 at 12:29 +0100, IOhannes m zmölnig wrote:
Hopefully, we'll be able to create fluid~ that also supports sf3 files.
I got fluidsynth compiled with libsndfile support. When loading an SF3 soundfont, there is no error, but I can't get any sound out of [fluid~]. So I am not sure whether I'm doing something wrong or SF3 support is broken still (more likely).
Anyway, it turns out to be an adventure with many more stumbling blocks ahead, for me at least . When I build fluidsynth, it links to the system-wide installed libsndfile. So, I'm not sure how to go about about making everything local. Is this when static linking is used?
Roman
Em sex., 8 de jan. de 2021 às 19:21, Roman Haefeli reduzent@gmail.com escreveu:
On Fri, 2021-01-08 at 12:47 +0100, Roman Haefeli wrote:
On Fri, 2021-01-08 at 12:29 +0100, IOhannes m zmölnig wrote:
Hopefully, we'll be able to create fluid~ that also supports sf3 files.
I got fluidsynth compiled with libsndfile support. When loading an SF3 soundfont, there is no error, but I can't get any sound out of [fluid~]. So I am not sure whether I'm doing something wrong or SF3 support is broken still (more likely).
where would it be broken? have you tested the same soundfont on another system like windows or mac?
On Fri, 2021-01-08 at 20:18 -0300, Alexandre Torres Porres wrote:
Em sex., 8 de jan. de 2021 às 19:21, Roman Haefeli < reduzent@gmail.com> escreveu:
On Fri, 2021-01-08 at 12:47 +0100, Roman Haefeli wrote:
On Fri, 2021-01-08 at 12:29 +0100, IOhannes m zmölnig wrote:
Hopefully, we'll be able to create fluid~ that also supports sf3 files.
I got fluidsynth compiled with libsndfile support. When loading an SF3 soundfont, there is no error, but I can't get any sound out of [fluid~]. So I am not sure whether I'm doing something wrong or SF3 support is broken still (more likely).
where would it be broken?
The fluidsynth command utility loads and plays the example SF3-file I found fine. [fluid~] says it loaded it, but I get only silence when playing notes.
have you tested the same soundfont on another system like windows or mac?
I only have access to a Windows 10 VM. I experience the exact same behaviour with [fluid~], it's seems not specific to my build.
The fact that fluidsynth can deal with a sf3 file that [fluid~] can't makes me assume that the problem is somewhere in [fluid~]. However, dealing with this is way beyond my capabilities. Personally, I'd be happy with a [fluid~] from Deken that works with SF2 files. If that is a goal, I'd be able to provide builds for Linux platforms not covered yet.
This is how I tested:
SF3-file from here: https://www.hedsound.com/2019/11/hedsound-b3-organ-presets.html
MIDI-file from here: https://en.wikipedia.org/wiki/File:MIDI_sample.mid?qsrc=3044
Command: fluidsynth -j HedOrgan-B3-Presets-V84d.sf3 MIDI_sample.mid
Roman
On Sat, 2021-01-09 at 12:28 +0100, Roman Haefeli wrote:
The fluidsynth command utility loads and plays the example SF3-file I found fine. [fluid~] says it loaded it, but I get only silence when playing notes.
[fluid~] works with /usr/share/sounds/sf3/MuseScore_General_Lite.sf3 from the package musescore-general-soundfont-small. So the problems I reported before are apparently not related not SF3 support.
Sorry for the noise.
Roman
So, I tested HedOrgan-B3-Presets-V84d.sf3 and I get silence too, but only in the first program, if I change to program 2 or higher, I get sounds. What abou you?
Em sáb., 9 de jan. de 2021 às 08:28, Roman Haefeli reduzent@gmail.com escreveu:
On Fri, 2021-01-08 at 20:18 -0300, Alexandre Torres Porres wrote:
Em sex., 8 de jan. de 2021 às 19:21, Roman Haefeli < reduzent@gmail.com> escreveu:
On Fri, 2021-01-08 at 12:47 +0100, Roman Haefeli wrote:
On Fri, 2021-01-08 at 12:29 +0100, IOhannes m zmölnig wrote:
Hopefully, we'll be able to create fluid~ that also supports sf3 files.
I got fluidsynth compiled with libsndfile support. When loading an SF3 soundfont, there is no error, but I can't get any sound out of [fluid~]. So I am not sure whether I'm doing something wrong or SF3 support is broken still (more likely).
where would it be broken?
The fluidsynth command utility loads and plays the example SF3-file I found fine. [fluid~] says it loaded it, but I get only silence when playing notes.
have you tested the same soundfont on another system like windows or mac?
I only have access to a Windows 10 VM. I experience the exact same behaviour with [fluid~], it's seems not specific to my build.
The fact that fluidsynth can deal with a sf3 file that [fluid~] can't makes me assume that the problem is somewhere in [fluid~]. However, dealing with this is way beyond my capabilities. Personally, I'd be happy with a [fluid~] from Deken that works with SF2 files. If that is a goal, I'd be able to provide builds for Linux platforms not covered yet.
This is how I tested:
SF3-file from here: https://www.hedsound.com/2019/11/hedsound-b3-organ-presets.html
MIDI-file from here: https://en.wikipedia.org/wiki/File:MIDI_sample.mid?qsrc=3044
Command: fluidsynth -j HedOrgan-B3-Presets-V84d.sf3 MIDI_sample.mid
Roman
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Em sáb., 9 de jan. de 2021 às 12:25, Alexandre Torres Porres < porres@gmail.com> escreveu:
So, I tested HedOrgan-B3-Presets-V84d.sf3 and I get silence too, but only in the first program, if I change to program 2 or higher, I get sounds. What about you?
Hmm, by checking "HedOrgan-B3-Presets-V84d.txt" I see the 1st program doesn't have a sound indeed, see:
+-----+-----+----------------------+----------------------+ |Bank | PC | Name* | Info. | +-----+-----+----------------------+----------------------+ | 000 | 000 | 1 [ Theater Upper ] | No Sound, Title Only |
So, in the end, it all seems to work just fine?
Em sáb., 9 de jan. de 2021 às 12:33, Alexandre Torres Porres < porres@gmail.com> escreveu:
+-----+-----+----------------------+----------------------+ |Bank | PC | Name* | Info. | +-----+-----+----------------------+----------------------+ | 000 | 000 | 1 [ Theater Upper ] | No Sound, Title Only |
What I see now is that program numbers should be indexed from 0, right? As it is, program 1 refers to program 0 on the program list, so it is indexed from 1 instead! That is, the code is subtracting "1", but I checked the original fluid~ code and it doesn't do that, see https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/footils/fl...
On the other hand, I was using the port to Pd's API from Purr Data and that subtraction was introduced in the code then, see https://git.purrdata.net/jwilkes/purr-data/-/blob/master/externals/fluid~/fl...
I considered that a backwards compatibility breakage and also a bug and I don't know what to do now. Purr Data's version also introduced "smmf" mode and I was keeping it all just so an external or a patch from Purr Data that uses fluid~ could run in Pd Vanilla, but I don't feel like keeping this bug/breakage. So I can ask them to fix it over there or just fix the bug and remove "smmf" mode and compatibility to Purr Data.
Ok, for reference, this http://midi.teragonaudio.com/tech/midispec/pgm.htm says that although program change numbers are from 0-127, there's no standard and some devices can index from 1, and I see Pd does index from 1, see: - https://github.com/pure-data/pure-data/blob/master/src/x_midi.c#L307 - https://github.com/pure-data/pure-data/blob/master/src/x_midi.c#L710
I think this should be mentioned in the Pd's help file...
Purr Data's smmf mode wants to be more plugin and play with pd's objects and made it 1-indexed for a new "pgm" message, but also altered the old legacy message, maybe unintentionally. I opened an issue over there.
As for what to do, I don't know. This is a quite old external that has been long lost to oblivion and I don't know how well we need to preserve its original design so it can run patches that used it some 15 years ago. I also don't know how crucial it is to port externals that are compatible to Purr Data compatibility between Vanilla and Purr is compromised to some extent in different levels so that can never be 100% achieved anyway (there are other objects that can only be found in Purr, and some objects like [trigger] have different functionalities and other things). To make it all more complicated, there's a new external from ceammc that has the exact same name (fluid~ ) and a completely different design and different functionalities.
What feels sane for me is creating a new object, with a different name (fluidsynth~) and its own design that is cleaner and doesn't try to fix this compatibility issues, cause it's just a nightmare with no simple solution. I like the idea of making it more compatible to Pd Vanilla and take messages in a more straightforward way from its internals, and I could do that by having that as a default and just removing the "legacy" stuff. That would make it all much cleaner...
Anyway, that's how I'm leaning now... what do you people think?
Em sáb., 9 de jan. de 2021 às 13:14, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sáb., 9 de jan. de 2021 às 12:33, Alexandre Torres Porres < porres@gmail.com> escreveu:
+-----+-----+----------------------+----------------------+ |Bank | PC | Name* | Info. | +-----+-----+----------------------+----------------------+ | 000 | 000 | 1 [ Theater Upper ] | No Sound, Title Only |
What I see now is that program numbers should be indexed from 0, right? As it is, program 1 refers to program 0 on the program list, so it is indexed from 1 instead! That is, the code is subtracting "1", but I checked the original fluid~ code and it doesn't do that, see https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/footils/fl...
On the other hand, I was using the port to Pd's API from Purr Data and that subtraction was introduced in the code then, see https://git.purrdata.net/jwilkes/purr-data/-/blob/master/externals/fluid~/fl...
I considered that a backwards compatibility breakage and also a bug and I don't know what to do now. Purr Data's version also introduced "smmf" mode and I was keeping it all just so an external or a patch from Purr Data that uses fluid~ could run in Pd Vanilla, but I don't feel like keeping this bug/breakage. So I can ask them to fix it over there or just fix the bug and remove "smmf" mode and compatibility to Purr Data.
On 1/9/2021 2:39 PM, Alexandre Torres Porres wrote:
What feels sane for me is creating a new object, with a different name (fluidsynth~) and its own design that is cleaner and doesn't try to fix this compatibility issues, cause it's just a nightmare with no simple solution. I like the idea of making it more compatible to Pd Vanilla and take messages in a more straightforward way from its internals, and I could do that by having that as a default and just removing the "legacy" stuff. That would make it all much cleaner...
+1
Mensaje telepatico asistido por maquinas.
Am 9. Jänner 2021 18:39:30 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
What feels sane for me is creating a new object, with a different name (fluidsynth~) and its own design that is cleaner and doesn't try to fix this compatibility issues, cause it's just a nightmare with no simple solution. I like the idea of making it more compatible to Pd Vanilla and take messages in a more straightforward way from its internals, and I could do that by having that as a default and just removing the "legacy" stuff. That would make it all much cleaner...
Anyway, that's how I'm leaning now... what do you people think?
I think this is a good idea.
probably (if simple enough) you could (also) provide an abstraction that exposes the original API.
as for the ceamcc version: I think this really should have been avoided.
mfg.hft.fsl IOhannes
Em sáb., 9 de jan. de 2021 às 15:15, IOhannes m zmölnig zmoelnig@iem.at escreveu:
probably (if simple enough) you could (also) provide an abstraction that exposes the original API.
Well, as soon as I get rid of the compatibility constraints, I just get ideas. And instead of having messages that match Pd's higher level MIDI input objects ([pgmin], [notein], etc), I could just make this object take the raw MIDI directly from [midiin]! It can't get more plug & play than that! And I could keep the original API I guess, I'll see...
Well, I just renamed the repository, it's at https://github.com/porres/pd-fluid and I'll leave it at that... (as it's all basically done anyway). It's up for grabs or we can get back to it, I dunno...
I will just start working on my own take of this thing right now, to be named fluidsynth~ and reside (for now) at https://github.com/porres/pd-fluidsynth. As I preannounced at one point earlier, and to the surprise of nobody, I have plans on integrating this into ELSE, where I can also have a somewhat decent keyboard GUI [else/keyboard] and an object that plays MIDI files [else/midi] - so it's all nicely integrated into the package. But of course, you can download the whole package and just rip off just any single object from this library if you don't want all of the almost 400 objects in it...
cheers
On 1/9/2021 7:38 PM, Alexandre Torres Porres wrote:
As I preannounced at one point earlier, and to the surprise of nobody, I have plans on integrating this into ELSE
Are you sure you want ELSE to be so difficult to build just for a single [fluidsynth~] object?
Mensaje telepatico asistido por maquinas.
I don't feel like debating this rather personal matter on the Pd list, and it's kind of a digression, but yeah, I hear you, it's a pain in the ass, but I have thought about it and the answer is: yes! :)
we can keep talking about this here if you like
cheers
Em sáb., 9 de jan. de 2021 às 19:45, Lucas Cordiviola lucarda27@hotmail.com escreveu:
On 1/9/2021 7:38 PM, Alexandre Torres Porres wrote:
As I preannounced at one point earlier, and to the surprise of nobody, I have plans on integrating this into ELSE
Are you sure you want ELSE to be so difficult to build just for a single [fluidsynth~] object?
Mensaje telepatico asistido por maquinas.
haha, I really screwed this one and deleted the wrong email 😂
sorry!
Em sáb., 9 de jan. de 2021 às 19:50, Alexandre Torres Porres < porres@gmail.com> escreveu:
I don't feel like debating this rather personal matter on the Pd list, and it's kind of a digression, but yeah, I hear you, it's a pain in the ass, but I have thought about it and the answer is: yes! :)
we can keep talking about this here if you like
cheers
Em sáb., 9 de jan. de 2021 às 19:45, Lucas Cordiviola < lucarda27@hotmail.com> escreveu:
On 1/9/2021 7:38 PM, Alexandre Torres Porres wrote:
As I preannounced at one point earlier, and to the surprise of nobody, I have plans on integrating this into ELSE
Are you sure you want ELSE to be so difficult to build just for a single [fluidsynth~] object?
Mensaje telepatico asistido por maquinas.
On Sat, 2021-01-09 at 14:39 -0300, Alexandre Torres Porres wrote:
What feels sane for me is creating a new object, with a different name (fluidsynth~) and its own design that is cleaner and doesn't try to fix this compatibility issues, cause it's just a nightmare with no simple solution. I like the idea of making it more compatible to Pd Vanilla and take messages in a more straightforward way from its internals, and I could do that by having that as a default and just removing the "legacy" stuff. That would make it all much cleaner...
Anyway, that's how I'm leaning now... what do you people think?
Sounds good to me. Just to be sure, to old [fluid~] goes to:
https://github.com/porres/pd-fluid
and the new [fluidsynth~] to:
https://github.com/porres/pd-fluidsynth
Right?
Roman
Em dom., 10 de jan. de 2021 às 12:48, Roman Haefeli reduzent@gmail.com escreveu:
Just to be sure, to old [fluid~] goes to: https://github.com/porres/pd-fluid and the new [fluidsynth~] to: https://github.com/porres/pd-fluidsynth
yes
On Fri, 2021-01-08 at 23:13 +0100, Roman Haefeli wrote:
On Fri, 2021-01-08 at 12:47 +0100, Roman Haefeli wrote:
On Fri, 2021-01-08 at 12:29 +0100, IOhannes m zmölnig wrote: Hopefully, we'll be able to create fluid~ that also supports sf3 files.
I got fluidsynth compiled with libsndfile support. When loading an SF3 soundfont, there is no error, but I can't get any sound out of [fluid~]. So I am not sure whether I'm doing something wrong or SF3 support is broken still (more likely).
As Alexndre already pointed out, my testing was bogus and playing SF3 works fine when choosing a non-silent program (and using a SF3-file that actually works).
Anyway, it turns out to be an adventure with many more stumbling blocks ahead, for me at least . When I build fluidsynth, it links to the system-wide installed libsndfile. So, I'm not sure how to go about about making everything local. Is this when static linking is used?
Ok, I got around re-compiling everything and learning the idiosyncracies of unfamilier build sytems by patching the binaries.
I sitll compiled fluidsynth so that it has the exact support I want, not more, not less. Basically, I only want libsndfile support (for loading SF3-files) and everything else disabled. I copied all dependencies to the folder of fluid~·pd_linux and used the patchelf command line utility to set RUNPATH to $ORIGIN.
The result can be found here: https://netpd.org/~roman/tmp/fluid~/fluid~%5bvtest-2~sf3-support%5d(Linux-am...
Read more about $ORIGIN and RUNPATH: https://nehckl0.medium.com/creating-relocatable-linux-executables-by-setting...
That is a process I think is less work and for me easier to grab than re-compiling the whole dependency chain. I might be able to turn this into a linuxdep.sh script. Since I'm still learning a lot, I wonder if this is the way to go or if it's considered hacky to fix things after the fact? I'd like to hear some expert opinion.
What I'm still wondering is how to distinguish dependencies required to be included into a Deken package from those that we assume are already installed on the system. Is there a proper way for making that distinction? Without that distintion, I'll probably have to hard-code all those libs that shouldn't be included in the final package.
Roman
On Sun, 2021-01-10 at 17:14 +0100, Roman Haefeli wrote:
Since I'm still learning a lot, I wonder if this is the way to go or if it's considered hacky to fix things after the fact? I'd like to hear some expert opinion.
Only now, I understand what the localdeps.*.sh scripts do: a similar thing. The one for Windows even uses sed to patch the dlls, so that's even hackier, but seems to work fine.
Roman
Em dom., 10 de jan. de 2021 às 13:40, Roman Haefeli reduzent@gmail.com escreveu:
I sitll compiled fluidsynth so that it has the exact support I want, not more, not less. Basically, I only want libsndfile support (for loading SF3-files) and everything else disabled.
what's everything else? what are you missing? I'm curious to know what these dependencies are, what they do and what they're needed for.
What I'm still wondering is how to distinguish dependencies required to be included into a Deken package from those that we assume are already installed on the system. Is there a proper way for making that distinction? Without that distintion, I'll probably have to hard-code all those libs that shouldn't be included in the final package.
yeah, for linux, I also wanna know :)
by the way, does anyone know of good soundfonts that use "aftertouch"? What about with different banks? I'm running tests, all the rest is working. I got the raw MIDI input working in the new fluidsynth~ and it looks great :)
Em dom., 10 de jan. de 2021 às 16:40, Alexandre Torres Porres < porres@gmail.com> escreveu:
does anyone know of good soundfonts that use "aftertouch"? What about with different banks?
I was able to test channel aftertouch and it works fine. I thought key/polyphonic aftertouch would be automatically supported in this case, but apparently not and that makes sense... it must be really rare to find a sound font with polyphonic aftertouch then. As for banks, I seem to have soundfonts with different banks and I don't seem to have it working... which doesn't make sense...
On Sun, 2021-01-10 at 16:40 -0300, Alexandre Torres Porres wrote:
Em dom., 10 de jan. de 2021 às 13:40, Roman Haefeli < reduzent@gmail.com> escreveu:
I sitll compiled fluidsynth so that it has the exact support I want, not more, not less. Basically, I only want libsndfile support (for loading SF3-files) and everything else disabled.
what's everything else? what are you missing?
Nothing (I hope). That's the point.
I'm curious to know what these dependencies are, what they do and what they're needed for.
fluidsynth comes with a library and command line utility, so that you can use it as a standalone tool. It supports writing to soundfiles, many audio backends from many platforms and other stuff (check CMakeLists.txt for a full list). From what I understand, the [fluidsynth~] external doesn't make use of this stuff, so there is no point in bloating the library and the number of dependencies unnecessarily.
I know you're still working on it, but for testing (especially the build part) I made builds for three Linux archs:
https://netpd.org/~roman/tmp/fluidsynth~/
Roman
On 1/10/2021 6:06 PM, Roman Haefeli wrote:
From what I understand, the [fluidsynth~] external doesn't make use of this stuff, so there is no point in bloating the library and the number of dependencies unnecessarily.
We have and older Windows build system (which is more straight forward and can also be cross-compiled, not based on the msys2 pkg). This build does not use FLAC/Vorbis/OGG binaries. It just use libsndfile. We should re-consider if building with the bloated msys2 pkg is needed.
We should do some testing with compressed sf3 files. (I only tested the "hedOrgan-Soundfont-sf3.zip" and it works on both types of builds)
--
Mensaje telepatico asistido por maquinas.
On Sun, 2021-01-10 at 18:51 -0300, Lucas Cordiviola wrote:
On 1/10/2021 6:06 PM, Roman Haefeli wrote:
From what I understand, the [fluidsynth~] external doesn't make use of this stuff, so there is no point in bloating the library and the number of dependencies unnecessarily.
We have and older Windows build system (which is more straight forward and can also be cross-compiled, not based on the msys2 pkg). This build does not use FLAC/Vorbis/OGG binaries. It just use libsndfile.
Hm, my understanding is that libsndfile doesn't do decoding of vorbis/flac files on its own, but uses libvorbis/libFLAC for that. I'd be surprised if there is absolutely no libvorbis/libFLAC involved.
We should re-consider if building with the bloated msys2 pkg is needed
Can't tell what is better for Windows.
We should do some testing with compressed sf3 files. (I only tested the "hedOrgan-Soundfont-sf3.zip" and it works on both types of builds)
Yes. I haven't even checked what type of compression it uses (if at all).
Roman
So, I created a script that tracks all dependencies of fluidsynth~.pd_linux and copies them to the local folder.
On Sun, 2021-01-10 at 17:14 +0100, Roman Haefeli wrote:
What I'm still wondering is how to distinguish dependencies required to be included into a Deken package from those that we assume are already installed on the system. Is there a proper way for making that distinction? Without that distintion, I'll probably have to hard-code all those libs that shouldn't be included in the final package.
This is the approach I used. I checked all libraries from ldd output which package they belong to with
`apt-file search`
and checked what happens when I emulate to uninstall that package with
`apt-get remove --dry-run <packagename>`
If the system would get horribly broken, I assumed the package is essential to the system and thus it is likely to be installed on any system. I made a hard-coded list of regex patterns matching those library names. Libraries matching any patterns of the list are not included in the final package.
Does that approach make sense?
See PR: https://github.com/porres/pd-fluidsynth/pull/5
Roman
On 1/14/21 10:42 AM, Roman Haefeli wrote:
given that i consider myself upstream of the original "localdeps.*.sh" scripts and those scripts are located under https://git.iem.at/pd/iem-ci where they are used by a number of (our, that is: the iem's) libraries, i would highly welcome it if you could submit a PR to that central location rather than a single one of the consumers of those scripts.
thanks for your consideration.
gfmards IOhannes
On Thu, 2021-01-14 at 16:52 +0100, IOhannes m zmölnig wrote:
On 1/14/21 10:42 AM, Roman Haefeli wrote:
given that i consider myself upstream of the original "localdeps.*.sh" scripts and those scripts are located under https://git.iem.at/pd/iem-ci where they are used by a number of (our, that is: the iem's) libraries, i would highly welcome it if you could submit a PR to that central location rather than a single one of the consumers of those scripts.
Sure. I wasn't even aware of the origin of those files.
Re PR/MR: While logged in as reduzent, I see only comport listed as repos I can create MRs for. I don't seem to have privileges for forking on git.iem.at nor for creating MRs for the iem-ci repo. Tell me if I'm overseeing something.
I created a fork on: https://gitlab.zhdk.ch/rhaefeli/iem-ci
You'll find the script addition in the linuxdep branch.
Roman
-
Alexandre Torres Porres -
IOhannes m zmölnig -
Lucas Cordiviola -
Roman Haefeli