Ok, we made lots of progress and now we have tests versions for macOS and Windows (32 and 64 bits).
Here's for everyone to test if all the links for dynamic libraries are working :) https://github.com/porres/pd-fluidsynth/releases/tag/test-1
we still need to sort this for linux, write a better readme with build instructions and reorganize things so then we can upload it to deken as a final/oficial release.
thanks for everyone who helped. Alex
On Thu, 2021-01-07 at 00:14 -0300, Alexandre Torres Porres wrote:
Ok, we made lots of progress and now we have tests versions for macOS and Windows (32 and 64 bits).
I think it's great you put effort into making [fluid~] available. Cool!
we still need to sort this for linux,
It builds without troubles on Linux-amd64-32. However, it assumes libfluidsynth2 to be installed. I don't know what the common process on Linux is, but since the dependencies are usually easily installable with some kind of package manager, there is probably no need to include additional local libraries. Is this notion widely accepted? Maybe include something in the README like:
On Debian and derivatives, you need to install the libfluidsynth2 package:
sudo apt install libfluidsynth2
Here is the build for Linux-amd64-32:
https://netpd.org/~roman/tmp/fluid~/
I can provide builds for Linux-i386-32, Linux-arm7-32, too, once the stuff is ready for release.
write a better readme with build instructions and reorganize things so then we can upload it to deken as a final/oficial release.
Cool. Some things I noticed:
Roman
On 1/7/2021 6:39 AM, Roman Haefeli wrote:
there is probably no need to include additional local libraries.
Hi Roman :)
I think that for a Deken package is better to include the dependencies. In this case they will be "additional" only if the user has fluidsynth already installed.
--
Mensaje telepatico asistido por maquinas.
here:
https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx
are linux64/32 test versions that includes fluidsynth 2.1.6
feedback is welcomed
:)
--
Mensaje telepatico asistido por maquinas.
works fine here (Ubuntu 16.04). It's ready for deken ;) Thanks for that!
Antoine
Le jeu. 7 janv. 2021 à 11:40, Lucas Cordiviola lucarda27@hotmail.com a écrit :
here:
https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx
are linux64/32 test versions that includes fluidsynth 2.1.6
feedback is welcomed
:)
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Works fine here on Win10 64bit. Thanks! Only little thing to watch out is that [ fluid~ ] is the name of another external contained in the (very nice) ceammc library. Obviously calling this by [fluid~/fluid~] just works.
www.elgallorojorecords.bandcamp.com/ https://elgallorojorecords.bandcamp.com/ soundcloud.com/alfonsosantimone www.facebook.com/alfonsosantimone
On Thu, Jan 7, 2021 at 12:59 PM Antoine Rousseau antoine@metalu.net wrote:
works fine here (Ubuntu 16.04). It's ready for deken ;) Thanks for that!
Antoine
Le jeu. 7 janv. 2021 à 11:40, Lucas Cordiviola lucarda27@hotmail.com a écrit :
here:
https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx
are linux64/32 test versions that includes fluidsynth 2.1.6
feedback is welcomed
:)
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Ubuntu Studio 20.04, https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx doesn't work at all and https://netpd.org/~roman/tmp/fluid~/ gives me these error messages when I create the [fluid~] object:
fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable fluidsynth: error: Unknown numeric setting 'synth.midi-channels' fluidsynth: error: Unknown numeric setting 'synth.polyphony' fluidsynth: error: Unknown string setting 'synth.chorus.active' fluidsynth: error: Unknown string setting 'synth.reverb.active' fluidsynth: error: Unknown string setting 'synth.ladspa.active'
plus a
(Tcl) UNHANDLED ERROR
Le jeu. 7 janv. 2021 à 13:38, alfonso santimone alfonso.santimone@gmail.com a écrit :
Works fine here on Win10 64bit. Thanks! Only little thing to watch out is that [ fluid~ ] is the name of another external contained in the (very nice) ceammc library. Obviously calling this by [fluid~/fluid~] just works.
www.elgallorojorecords.bandcamp.com/ https://elgallorojorecords.bandcamp.com/ soundcloud.com/alfonsosantimone www.facebook.com/alfonsosantimone
On Thu, Jan 7, 2021 at 12:59 PM Antoine Rousseau antoine@metalu.net wrote:
works fine here (Ubuntu 16.04). It's ready for deken ;) Thanks for that!
Antoine
Le jeu. 7 janv. 2021 à 11:40, Lucas Cordiviola lucarda27@hotmail.com a écrit :
here:
https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx
are linux64/32 test versions that includes fluidsynth 2.1.6
feedback is welcomed
:)
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Thu, 2021-01-07 at 14:29 +0100, Allister Sinclair wrote:
On Ubuntu Studio 20.04, https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx doesn't work at all
What exactly? It loads fine and example from help creates sound here on Ubuntu 20.04.
and https://netpd.org/~roman/tmp/fluid~/ gives me these error messages when I create the [fluid~] object:
fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable fluidsynth: error: Unknown numeric setting 'synth.midi-channels' fluidsynth: error: Unknown numeric setting 'synth.polyphony' fluidsynth: error: Unknown string setting 'synth.chorus.active' fluidsynth: error: Unknown string setting 'synth.reverb.active' fluidsynth: error: Unknown string setting 'synth.ladspa.active'
I get those, too, also with Lucarda's version. The example from the help works anayway. Have you tested it?
plus a
(Tcl) UNHANDLED ERROR
I don't understand this error. What action exactly triggers it? When does it happen?
Roman
What exactly? It loads fine and example from help creates sound here on Ubuntu 20.04.
The [fluid~] object just can't be created
I get those, too, also with Lucarda's version. The example from the help works anayway. Have you tested it?
I can't test it because of the " (Tcl) UNHANDLED ERROR" that crashes Tcl/tk so I can't see/use the patch anymore.
The " (Tcl) UNHANDLED ERROR" comes up when I try to create the [fluid~] object. The result is a weird blank box...
Le jeu. 7 janv. 2021 à 15:15, Roman Haefeli reduzent@gmail.com a écrit :
On Thu, 2021-01-07 at 14:29 +0100, Allister Sinclair wrote:
On Ubuntu Studio 20.04, https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx doesn't work at all
What exactly? It loads fine and example from help creates sound here on Ubuntu 20.04.
and https://netpd.org/~roman/tmp/fluid~/ gives me these error messages when I create the [fluid~] object:
fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable fluidsynth: error: Unknown numeric setting 'synth.midi-channels' fluidsynth: error: Unknown numeric setting 'synth.polyphony' fluidsynth: error: Unknown string setting 'synth.chorus.active' fluidsynth: error: Unknown string setting 'synth.reverb.active' fluidsynth: error: Unknown string setting 'synth.ladspa.active'
I get those, too, also with Lucarda's version. The example from the help works anayway. Have you tested it?
plus a
(Tcl) UNHANDLED ERROR
I don't understand this error. What action exactly triggers it? When does it happen?
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em qui., 7 de jan. de 2021 às 09:38, alfonso santimone < alfonso.santimone@gmail.com> escreveu:
Works fine here on Win10 64bit. Thanks! Only little thing to watch out is that [ fluid~ ] is the name of another external contained in the (very nice) ceammc library.
it's the other way around, ceammc has an object with the same name as this external, which is originally from 2003!
but yeah, using [fluid~/fluid~] in the help file can fix this problem, or [declare/fluid~]
Em qui., 7 de jan. de 2021 às 09:38, alfonso santimone < alfonso.santimone@gmail.com> escreveu:
Works fine here on Win10 64bit. Thanks! Only little thing to watch out is that [ fluid~ ] is the name of another external contained in the (very nice) ceammc library. Obviously calling this by [fluid~/fluid~] just works.
funny, I tested [declare -path fluid~] and that *DOESN'T WORK *if I have ceammc in the start up. Meaning it'll just load fluid~ from ceammc. Now, I did not expect that... still thinking about it, but it feels like it shouldn't be that way.
Em qui., 7 de jan. de 2021 às 14:05, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em qui., 7 de jan. de 2021 às 09:38, alfonso santimone < alfonso.santimone@gmail.com> escreveu:
Works fine here on Win10 64bit. Thanks! Only little thing to watch out is that [ fluid~ ] is the name of another external contained in the (very nice) ceammc library. Obviously calling this by [fluid~/fluid~] just works.
funny, I tested [declare -path fluid~] and that *DOESN'T WORK *if I have ceammc in the start up. Meaning it'll just load fluid~ from ceammc. Now, I did not expect that... still thinking about it, but it feels like it shouldn't be that way.
On the other hand, having [declare -lib fluid~] works by superseding the priority of 'ceammc' in startup! So I'm using this instead (cause fluid~/fluid~ just looks terrible!).
And it seems once you load a binary in startup, it stays there forever and has priority over search paths. So I need to document this.
I see [declare -path fluid~] and ./fluid~ also works
On Thu, 7 Jan 2021 at 14:10 Alexandre Torres Porres porres@gmail.com wrote:
Em qui., 7 de jan. de 2021 às 14:05, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em qui., 7 de jan. de 2021 às 09:38, alfonso santimone < alfonso.santimone@gmail.com> escreveu:
Works fine here on Win10 64bit. Thanks! Only little thing to watch out is that [ fluid~ ] is the name of another external contained in the (very nice) ceammc library. Obviously calling this by [fluid~/fluid~] just works.
funny, I tested [declare -path fluid~] and that *DOESN'T WORK *if I have ceammc in the start up. Meaning it'll just load fluid~ from ceammc. Now, I did not expect that... still thinking about it, but it feels like it shouldn't be that way.
On the other hand, having [declare -lib fluid~] works by superseding the priority of 'ceammc' in startup! So I'm using this instead (cause fluid~/fluid~ just looks terrible!).
And it seems once you load a binary in startup, it stays there forever and has priority over search paths. So I need to document this.
On Thu, 2021-01-07 at 07:40 -0300, Lucas Cordiviola wrote:
here:
https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx
are linux64/32 test versions that includes fluidsynth 2.1.6
feedback is welcomed
Works for me. Your libfluidsynth dynamic library is very stripped down. I checked the one from repos of Ubuntu 20.04 and it links to a lot of other libraries (jack, opus, systemd, wayland etc.) that probably don't make any sense in the given use case. How did you create yours? Did you just compile yourself with everything disabled? How do you link fluid~ to the local libfluidsynth.so? I followed the thread about including local libraries on macOS on Windows, but don't understand how this is done on Linux.
Roman
but don't understand how this is done on Linux.
As I've written in the original thread:
Linux: -Wl,-rpath,"$$ORIGIN",--enable-new-dtags
This makes sure that the loader will look for dynamic libraries in the same folder as the Pd external. This is what pd-lib-builder uses for shared helper libraries, but it works for any shared library.
Christof
On 07.01.2021 15:20, Roman Haefeli wrote:
On Thu, 2021-01-07 at 07:40 -0300, Lucas Cordiviola wrote:
here:
https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx https://nc.nubegris.com.ar/index.php/s/nRWQi3CBCdYctHx
are linux64/32 test versions that includes fluidsynth 2.1.6
feedback is welcomed
Works for me. Your libfluidsynth dynamic library is very stripped down. I checked the one from repos of Ubuntu 20.04 and it links to a lot of other libraries (jack, opus, systemd, wayland etc.) that probably don't make any sense in the given use case. How did you create yours? Did you just compile yourself with everything disabled? How do you link fluid~ to the local libfluidsynth.so? I followed the thread about including local libraries on macOS on Windows, but don't understand how this is done on Linux.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em qui., 7 de jan. de 2021 às 11:22, Roman Haefeli reduzent@gmail.com escreveu:
but don't understand how this is done on Linux.
me neither, in any case, this thread was just for people to download the test binaries for mac and windows and test it :) not build it for any system.
Anyway, I guess Lucas made it happen for Linux already and put up some binaries we can test as well, but only he can say what he did so we're sure.
But again, I hope we can focus if the provided test binaries work, cause those are going up to deken next soon ;)
cheers
On Thu, 2021-01-07 at 12:01 -0300, Alexandre Torres Porres wrote:
Em qui., 7 de jan. de 2021 às 11:22, Roman Haefeli < reduzent@gmail.com> escreveu:
but don't understand how this is done on Linux.
me neither, in any case, this thread was just for people to download the test binaries for mac and windows and test it :) not build it for any system.
I understand this and was trying to help out on Linux and obviously failed. I wasn't complaining about the help not giving me instructions on how to compile fluid~ on Linux (btw: it compiles fine on Linux).
Anyway, I guess Lucas made it happen for Linux already and put up some binaries we can test as well, but only he can say what he did so we're sure.
He included a libfluidsynth binary that doesn't link to all kinds of other libraries. I think that is the way it should be done.
But again, I hope we can focus if the provided test binaries work, cause those are going up to deken next soon ;)
Absolutely. Nevertheless, it would be nice to provide them at least for most common Linux platforms. As I'm using fluid~ already myself, I'm interested in getting it done "the right way".
Roman
On 1/7/2021 11:20 AM, Roman Haefeli wrote:
Works for me. Your libfluidsynth dynamic library is very stripped down. I checked the one from repos of Ubuntu 20.04 and it links to a lot of other libraries (jack, opus, systemd, wayland etc.) that probably don't make any sense in the given use case. How did you create yours?
I'd compiled as written in the readme from https://github.com/porres/pd-fluidsynth
I guess is true that is a stripped down version. If anyone knows how to improve that we are all ears.
:)
Mensaje telepatico asistido por maquinas.
On Fri, 2021-01-08 at 07:35 -0300, Lucas Cordiviola wrote:
On 1/7/2021 11:20 AM, Roman Haefeli wrote:
Works for me. Your libfluidsynth dynamic library is very stripped down. I checked the one from repos of Ubuntu 20.04 and it links to a lot of other libraries (jack, opus, systemd, wayland etc.) that probably don't make any sense in the given use case. How did you create yours?
I'd compiled as written in the readme from https://github.com/porres/pd-fluidsynth
I guess is true that is a stripped down version.
I meant your libfluidsynth.so was a stripped down-version, at least compared to what I get from Ubuntu. Not fluid~.pd_linux.
If anyone knows how to improve that we are all ears.
I wasn't complaining. In contrary, I was trying to point out that this is a good thing because yours doesn't have any external dependencies (or only the kind that is installed anyway). Anyway, to me it seems the only sane way to go forward is compiling fluidsynth with exactly the support that we want for fluid~ and not rely on any binary shipped by a repo.
I'll look into sf3 (flac, vorbis) support and tiding up things a bit according to what IOhannes said. Not today, though.
Roman
Em qui., 7 de jan. de 2021 às 06:48, Roman Haefeli reduzent@gmail.com escreveu:
On Thu, 2021-01-07 at 00:14 -0300, Alexandre Torres Porres wrote:
Ok, we made lots of progress and now we have tests versions for macOS and Windows (32 and 64 bits).
I think it's great you put effort into making [fluid~] available. Cool!
we still need to sort this for linux,
It builds without troubles on Linux-amd64-32. However, it assumes libfluidsynth2 to be installed. I don't know what the common process on Linux is, but since the dependencies are usually easily installable with some kind of package manager, there is probably no need to include additional local libraries. Is this notion widely accepted? Maybe include something in the README like:
On Debian and derivatives, you need to install the libfluidsynth2 package:
sudo apt install libfluidsynth2
Yeah, it's important we make all of this clear. I just want this to be available via deken, so people can download it and use it right away. So statically/dynamic linking is the only way to go I guess.
If there's something in the way and if there are just too many different options for linux distributions (does this make sense? What do I know?), then we can maybe put this instructions on the help file instead? Well, Linux people, enlighten me...
On Thu, 2021-01-07 at 12:22 -0300, Alexandre Torres Porres wrote:
Em qui., 7 de jan. de 2021 às 06:48, Roman Haefeli < reduzent@gmail.com> escreveu:
Maybe include something in the README like:
On Debian and derivatives, you need to install the libfluidsynth2 package:
sudo apt install libfluidsynth2
Yeah, it's important we make all of this clear. I just want this to be available via deken, so people can download it and use it right away. So statically/dynamic linking is the only way to go I guess.
If libfluidsynth is part of the Deken package as in the one provided by Lucas, this is not necessary anymore.
So maybe including all dependencies is the better way, after all. I would like to hear some expert's opinion on it.
If there's something in the way and if there are just too many different options for linux distributions (does this make sense? What do I know?), then we can maybe put this instructions on the help file instead? Well, Linux people, enlighten me...
There is no way to distinguish by Linux distro in Deken. From what I understand, it wouldn't be necessary when such dependencies are included in the package.
Roman
Em qui., 7 de jan. de 2021 às 06:48, Roman Haefeli reduzent@gmail.com escreveu:
- a fluid~-meta.pd file is missing.
I never knew why there needs to be a file for this... there's a [pd meta] subpatch in the help file though, isn't it enough? What's the deal?
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), I made a build for Linux-arm7-32 (Raspberry Pi):
https://netpd.org/~roman/tmp/fluid~/
The library libfluidsynth is included, so it should work out-of-the- box, in case anyone wants to test.
Roman
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? Can you describe the steps and put it in our readme (with a PR)?