Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

On Thu, 2021-01-14 at 16:52 +0100, IOhannes m zmölnig wrote:
> On 1/14/21 10:42 AM, Roman Haefeli wrote:
> > See PR:
> > https://github.com/porres/pd-fluidsynth/pull/5
> > 
> 
> 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


signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[IOhannes m zmölnig]

On 1/14/21 10:42 AM, Roman Haefeli wrote:


See PR:
https://github.com/porres/pd-fluidsynth/pull/5



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



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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 `

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





signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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



signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Lucas Cordiviola]

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.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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 <
> reduz...@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



signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Alexandre Torres Porres]

Em dom., 10 de jan. de 2021 às 16:40, Alexandre Torres Porres <
por...@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...
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Alexandre Torres Porres]

Em dom., 10 de jan. de 2021 às 13:40, Roman Haefeli 
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 :)
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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


signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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-amd64-32).zip

Read more about $ORIGIN and RUNPATH:
https://nehckl0.medium.com/creating-relocatable-linux-executables-by-setting-rpath-with-origin-45de573a2e98

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







signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Alexandre Torres Porres]

Em dom., 10 de jan. de 2021 às 12:48, Roman Haefeli 
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
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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


signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Lucas Cordiviola]

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.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Alexandre Torres Porres]

Em sáb., 9 de jan. de 2021 às 15:15, IOhannes m zmölnig 
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
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Lucas Cordiviola]

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.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[IOhannes m zmölnig]

Am 9. Jänner 2021 18:39:30 MEZ schrieb Alexandre Torres Porres 
:
> 
> 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


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Alexandre Torres Porres]

Ok, for reference, this
 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 <
por...@gmail.com> escreveu:

> Em sáb., 9 de jan. de 2021 às 12:33, Alexandre Torres Porres <
> por...@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/fluid/fluid/main.cpp#l193
>
> 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~/fluid~.c#L93
>
> 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.
>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Alexandre Torres Porres]

Em sáb., 9 de jan. de 2021 às 12:33, Alexandre Torres Porres <
por...@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/fluid/fluid/main.cpp#l193

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~/fluid~.c#L93

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.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Alexandre Torres Porres]

Em sáb., 9 de jan. de 2021 às 12:25, Alexandre Torres Porres <
por...@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?
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Alexandre Torres Porres]

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 
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 <
> > reduz...@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
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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


signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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 <
> reduz...@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



signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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


signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Alexandre Torres Porres]

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 
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 <
> > reduz...@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
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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 <
> reduz...@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


signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Alexandre Torres Porres]

Em sex., 8 de jan. de 2021 às 08:48, Roman Haefeli 
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...
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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




signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[IOhannes m zmölnig]

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 <
reduz...@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.
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



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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 (0x7ffca270b000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 
(0x7f4536a8b000)
libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 
(0x7f4536a85000)
libjack.so.0 => /lib/x86_64-linux-gnu/libjack.so.0 (0x7f4536a39000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f4536a16000)
libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 
(0x7f453691b000)
libpulse-simple.so.0 => /lib/x86_64-linux-gnu/libpulse-simple.so.0 
(0x7f4536914000)
libsndfile.so.1 => /lib/x86_64-linux-gnu/libsndfile.so.1 
(0x7f4536895000)
libSDL2-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2-2.0.so.0 
(0x7f453674)
libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 
(0x7f45366ef000)
libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 
(0x7f453669f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f453655)
libinstpatch-1.0.so.2 => /lib/x86_64-linux-gnu/libinstpatch-1.0.so.2 
(0x7f4536495000)
libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 
(0x7f4536433000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4536241000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f45361ce000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f45361c8000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f45361bd000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f4535fdc000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f4535fbf000)
/lib64/ld-linux-x86-64.so.2 (0x7f4536cae000)
libpulse.so.0 => /lib/x86_64-linux-gnu/libpulse.so.0 
(0x7f4535f6a000)
libpulsecommon-13.99.so => 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so 
(0x7f4535ee8000)
libFLAC.so.8 => /lib/x86_64-linux-gnu/libFLAC.so.8 (0x7f4535eaa000)
libogg.so.0 => /lib/x86_64-linux-gnu/libogg.so.0 (0x7f4535e9d000)
libvorbis.so.0 => /lib/x86_64-linux-gnu/libvorbis.so.0 
(0x7f4535e6d000)
libvorbisenc.so.2 => /lib/x86_64-linux-gnu/libvorbisenc.so.2 
(0x7f4535dc2000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7f4535c85000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x7f4535c7)
libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1 
(0x7f4535c63000)
libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 
(0x7f4535c5e000)
libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x7f4535c4a000)
libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 
(0x7f4535c3d000)
libXss.so.1 => /lib/x86_64-linux-gnu/libXss.so.1 (0x7f4535c38000)
libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 
(0x7f4535c31000)
libwayland-egl.so.1 => /lib/x86_64-linux-gnu/libwayland-egl.so.1 
(0x7f4535c2c000)
libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0 
(0x7f4535c1b000)
libwayland-cursor.so.0 => /lib/x86_64-linux-gnu/libwayland-cursor.so.0 
(0x7f4535c0e000)
libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0 
(0x7f4535bcc000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f4535b1d000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f4535aed000)
libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x7f4535ae1000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x7f4535ab5000)
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x7f4535aa9000)
libasyncns.so.0 => /lib/x86_64-linux-gnu/libasyncns.so.0 
(0x7f45358a3000)
libapparmor.so.1 => /lib/x86_64-linux-gnu/libapparmor.so.1 
(0x7f453588e000)
libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 
(0x7f4535684000)
libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 
(0x7f453567a000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f4535651000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f453563)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f4535512000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x7f453550c000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 
(0x7f4535502000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f45354e5000)
libresolv.so.2 => 

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Lucas Cordiviola]

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 <
reduz...@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 

[PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Roman Haefeli]

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 <
> reduz...@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







signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev