Hi all,
I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.
The patch was using *vbap* [0] and *soundfile_info* from iemlib [1].
The issue I found was that the pre-built binaries that work in the window version of the Pd authoring environment were linking against *pd.dll* (I'm assuming from Pd/bin/) in order to correctly link against the plugin API methods exposed in *m_pd.h*.
The solution I recently came to, though admittedly a bit of a hack, was to generate a custom VS2017 dll project for both *vbap*, and *soundfile_info*, include the relevant source files, and link against the compiled version of libpd to resolve the missing symbols instead of the authoring libraries.
The downside of this approach is that the manually compiled externals will no longer run in the Pd authoring environment, and it's not really maintainable from a development perspective.
From my days of making externals for macos, I don't think I ever had to
link against Pd, but just include *m_pd.h* and be done.
My question is whether this is usual behaviour when working with externals/libpd on Windows or if I'm missing something somewhere?
Any perspective would be much appreciated!
Thanks, Joe
[0] https://puredata.info/downloads/vbap [1] https://git.iem.at/pd/iemlib
yes, this is a limitation on windows where a DLL can't automatically import symbols from the executable where it was loaded (what you get on Linux with --export-dynamic). for Pd the solution is to make the app itself a thin wrapper around a DLL (pd.dll) which plugins can link to.
I found this link which might be helpful:
http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-...
I guess if you compile libpd as a DLL (with "--export-all-symbols") existing externals should load.
Gesendet: Freitag, 11. Mai 2018 um 19:21 Uhr Von: "Joe White" white.joe4@gmail.com An: Pd-list pd-list@lists.iem.at Betreff: [PD] Using externals with libpd on Windows
Hi all, I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd. The patch was using vbap [0] and soundfile_info from iemlib [1]. The issue I found was that the pre-built binaries that work in the window version of the Pd authoring environment were linking against pd.dll (I'm assuming from Pd/bin/) in order to correctly link against the plugin API methods exposed in m_pd.h. The solution I recently came to, though admittedly a bit of a hack, was to generate a custom VS2017 dll project for both vbap, and soundfile_info, include the relevant source files, and link against the compiled version of libpd to resolve the missing symbols instead of the authoring libraries. The downside of this approach is that the manually compiled externals will no longer run in the Pd authoring environment, and it's not really maintainable from a development perspective.
From my days of making externals for macos, I don't think I ever had to link against Pd, but just include m_pd.h and be done.
My question is whether this is usual behaviour when working with externals/libpd on Windows or if I'm missing something somewhere? Any perspective would be much appreciated! Thanks, Joe [0] https://puredata.info/downloads/vbap [1] https://git.iem.at/pd/iemlib%5Bhttps://git.iem.at/pd/iemlib%5D______________... Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Thanks for the info Christof!
It seems to me that compiling libpd via the makefile [0] in mingw already exports all the symbols correctly.
Seems like the solution in your link [1] suggests to export the symbols in the exe, and also update the plugins to load the functions via GetProcAddress. I'm trying to avoid touching the 3rd party externals if possible as I can already re-link them against the libpd.dll but don't feel that is very maintainable.
Has anyone managed to successfully load pre-compiled externals in a libpd-embedded Windows application?
I'm currently trying to see if it's possible to point the externals to the find the pd symbols elsewhere as they get loaded, but my hopes aren't high!
Thanks, Joe
[0] https://github.com/libpd/libpd/blob/master/Makefile#L23 [1] http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within-dynamic-library-MinGW
On 11 May 2018 at 20:04, Christof Ressi christof.ressi@gmx.at wrote:
yes, this is a limitation on windows where a DLL can't automatically import symbols from the executable where it was loaded (what you get on Linux with --export-dynamic). for Pd the solution is to make the app itself a thin wrapper around a DLL (pd.dll) which plugins can link to.
I found this link which might be helpful:
http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW
I guess if you compile libpd as a DLL (with "--export-all-symbols") existing externals should load.
Gesendet: Freitag, 11. Mai 2018 um 19:21 Uhr Von: "Joe White" white.joe4@gmail.com An: Pd-list pd-list@lists.iem.at Betreff: [PD] Using externals with libpd on Windows
Hi all,
I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.
The patch was using vbap [0] and soundfile_info from iemlib [1].
The issue I found was that the pre-built binaries that work in the window version of the Pd authoring environment were linking against pd.dll (I'm assuming from Pd/bin/) in order to correctly link against the plugin API methods exposed in m_pd.h.
The solution I recently came to, though admittedly a bit of a hack, was to generate a custom VS2017 dll project for both vbap, and soundfile_info, include the relevant source files, and link against the compiled version of libpd to resolve the missing symbols instead of the authoring libraries.
The downside of this approach is that the manually compiled externals will no longer run in the Pd authoring environment, and it's not really maintainable from a development perspective.
From my days of making externals for macos, I don't think I ever had to link against Pd, but just include m_pd.h and be done.
My question is whether this is usual behaviour when working with externals/libpd on Windows or if I'm missing something somewhere?
Any perspective would be much appreciated!
Thanks, Joe
[0] https://puredata.info/downloads/vbap [1] https://git.iem.at/pd/iemlib%5Bhttps://git.iem.at/pd/ iemlib]_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list]
just to be sure: are you using a static or dynamic version of libpd in your program?
Gesendet: Freitag, 18. Mai 2018 um 17:38 Uhr Von: "Joe White" white.joe4@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] Using externals with libpd on Windows
Thanks for the info Christof! It seems to me that compiling libpd via the makefile [0] in mingw already exports all the symbols correctly.
Seems like the solution in your link [1] suggests to export the symbols in the exe, and also update the plugins to load the functions via GetProcAddress. I'm trying to avoid touching the 3rd party externals if possible as I can already re-link them against the libpd.dll but don't feel that is very maintainable. Has anyone managed to successfully load pre-compiled externals in a libpd-embedded Windows application? I'm currently trying to see if it's possible to point the externals to the find the pd symbols elsewhere as they get loaded, but my hopes aren't high! Thanks, Joe [0] https://github.com/libpd/libpd/blob/master/Makefile#L23 [1] http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-...] On 11 May 2018 at 20:04, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> wrote:yes, this is a limitation on windows where a DLL can't automatically import symbols from the executable where it was loaded (what you get on Linux with --export-dynamic). for Pd the solution is to make the app itself a thin wrapper around a DLL (pd.dll) which plugins can link to.
I found this link which might be helpful:
http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-...]
I guess if you compile libpd as a DLL (with "--export-all-symbols") existing externals should load.
Gesendet: Freitag, 11. Mai 2018 um 19:21 Uhr Von: "Joe White" <white.joe4@gmail.com[mailto:white.joe4@gmail.com]> An: Pd-list <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> Betreff: [PD] Using externals with libpd on Windows
Hi all, I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd. The patch was using vbap [0] and soundfile_info from iemlib [1]. The issue I found was that the pre-built binaries that work in the window version of the Pd authoring environment were linking against pd.dll (I'm assuming from Pd/bin/) in order to correctly link against the plugin API methods exposed in m_pd.h. The solution I recently came to, though admittedly a bit of a hack, was to generate a custom VS2017 dll project for both vbap, and soundfile_info, include the relevant source files, and link against the compiled version of libpd to resolve the missing symbols instead of the authoring libraries. The downside of this approach is that the manually compiled externals will no longer run in the Pd authoring environment, and it's not really maintainable from a development perspective.
From my days of making externals for macos, I don't think I ever had to link against Pd, but just include m_pd.h and be done.
My question is whether this is usual behaviour when working with externals/libpd on Windows or if I'm missing something somewhere? Any perspective would be much appreciated! Thanks, Joe [0] https://puredata.info/downloads/vbap%5Bhttps://puredata.info/downloads/vbap%...] Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
I'm linking against libpd dynamically, also using the windows .lib to statically import the symbols.
On 18 May 2018 at 19:35, Christof Ressi christof.ressi@gmx.at wrote:
just to be sure: are you using a static or dynamic version of libpd in your program?
Gesendet: Freitag, 18. Mai 2018 um 17:38 Uhr Von: "Joe White" white.joe4@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] Using externals with libpd on Windows
Thanks for the info Christof!
It seems to me that compiling libpd via the makefile [0] in mingw already exports all the symbols correctly.
Seems like the solution in your link [1] suggests to export the symbols in the exe, and also update the plugins to load the functions via GetProcAddress. I'm trying to avoid touching the 3rd party externals if possible as I can already re-link them against the libpd.dll but don't feel that is very maintainable.
Has anyone managed to successfully load pre-compiled externals in a libpd-embedded Windows application?
I'm currently trying to see if it's possible to point the externals to the find the pd symbols elsewhere as they get loaded, but my hopes aren't high!
Thanks, Joe
[0] https://github.com/libpd/libpd/blob/master/Makefile#L23 [1] http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW]
On 11 May 2018 at 20:04, Christof Ressi <christof.ressi@gmx.at[mailto: christof.ressi@gmx.at]> wrote:yes, this is a limitation on windows where a DLL can't automatically import symbols from the executable where it was loaded (what you get on Linux with --export-dynamic). for Pd the solution is to make the app itself a thin wrapper around a DLL (pd.dll) which plugins can link to.
I found this link which might be helpful:
http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW]
I guess if you compile libpd as a DLL (with "--export-all-symbols") existing externals should load.
Gesendet: Freitag, 11. Mai 2018 um 19:21 Uhr Von: "Joe White" <white.joe4@gmail.com[mailto:white.joe4@gmail.com]> An: Pd-list <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> Betreff: [PD] Using externals with libpd on Windows
Hi all,
I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.
The patch was using vbap [0] and soundfile_info from iemlib [1].
The issue I found was that the pre-built binaries that work in the window version of the Pd authoring environment were linking against pd.dll (I'm assuming from Pd/bin/) in order to correctly link against the plugin API methods exposed in m_pd.h.
The solution I recently came to, though admittedly a bit of a hack, was to generate a custom VS2017 dll project for both vbap, and soundfile_info, include the relevant source files, and link against the compiled version of libpd to resolve the missing symbols instead of the authoring libraries.
The downside of this approach is that the manually compiled externals will no longer run in the Pd authoring environment, and it's not really maintainable from a development perspective.
From my days of making externals for macos, I don't think I ever had to link against Pd, but just include m_pd.h and be done.
My question is whether this is usual behaviour when working with externals/libpd on Windows or if I'm missing something somewhere?
Any perspective would be much appreciated!
Thanks, Joe
[0] https://puredata.info/downloads/vbap%5Bhttps:// puredata.info/downloads/vbap][1] https://git.iem.at/pd/ iemlib[https://git.iem.at/pd/iemlib]_______________________ ________________________[https://git.iem.at/pd/iemlib%5B https://git.iem.at/pd/iemlib%5D_______________________________ ________________] Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list][https://lists. puredata.info/listinfo/pd-list[https://lists.puredata. info/listinfo/pd-list]]
hmmm, I might try it myself in the next few days.
BTW,
also using the windows .lib to statically import the symbols.
the import library (.lib) is only necessary if you work with MSVC, GCC can directly link to a DLL
Gesendet: Montag, 21. Mai 2018 um 12:10 Uhr Von: "Joe White" white.joe4@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: Re: [PD] Using externals with libpd on Windows
I'm linking against libpd dynamically, also using the windows .lib to statically import the symbols. On 18 May 2018 at 19:35, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> wrote:just to be sure: are you using a static or dynamic version of libpd in your program?
Gesendet: Freitag, 18. Mai 2018 um 17:38 Uhr Von: "Joe White" <white.joe4@gmail.com[mailto:white.joe4@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> Cc: Pd-list <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> Betreff: Re: [PD] Using externals with libpd on Windows
Thanks for the info Christof! It seems to me that compiling libpd via the makefile [0] in mingw already exports all the symbols correctly.
Seems like the solution in your link [1] suggests to export the symbols in the exe, and also update the plugins to load the functions via GetProcAddress. I'm trying to avoid touching the 3rd party externals if possible as I can already re-link them against the libpd.dll but don't feel that is very maintainable. Has anyone managed to successfully load pre-compiled externals in a libpd-embedded Windows application? I'm currently trying to see if it's possible to point the externals to the find the pd symbols elsewhere as they get loaded, but my hopes aren't high! Thanks, Joe [0] https://github.com/libpd/libpd/blob/master/Makefile#L23%5Bhttps://github.com...] [1] http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-...]] On 11 May 2018 at 20:04, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at][mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]]> wrote:yes, this is a limitation on windows where a DLL can't automatically import symbols from the executable where it was loaded (what you get on Linux with --export-dynamic). for Pd the solution is to make the app itself a thin wrapper around a DLL (pd.dll) which plugins can link to.
I found this link which might be helpful:
http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-...]]
I guess if you compile libpd as a DLL (with "--export-all-symbols") existing externals should load.
Gesendet: Freitag, 11. Mai 2018 um 19:21 Uhr Von: "Joe White" <white.joe4@gmail.com[mailto:white.joe4@gmail.com][mailto:white.joe4@gmail.com[mailto:white.joe4@gmail.com]]> An: Pd-list <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at][mailto:pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]]> Betreff: [PD] Using externals with libpd on Windows
Hi all, I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd. The patch was using vbap [0] and soundfile_info from iemlib [1]. The issue I found was that the pre-built binaries that work in the window version of the Pd authoring environment were linking against pd.dll (I'm assuming from Pd/bin/) in order to correctly link against the plugin API methods exposed in m_pd.h. The solution I recently came to, though admittedly a bit of a hack, was to generate a custom VS2017 dll project for both vbap, and soundfile_info, include the relevant source files, and link against the compiled version of libpd to resolve the missing symbols instead of the authoring libraries. The downside of this approach is that the manually compiled externals will no longer run in the Pd authoring environment, and it's not really maintainable from a development perspective.
From my days of making externals for macos, I don't think I ever had to link against Pd, but just include m_pd.h and be done.
My question is whether this is usual behaviour when working with externals/libpd on Windows or if I'm missing something somewhere? Any perspective would be much appreciated! Thanks, Joe [0] https://puredata.info/downloads/vbap%5Bhttps://puredata.info/downloads/vbap%...]] Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at][mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]]
As an update for any potential future Pd-nauts...
The issue: Why don't my 3rd party externals load in libpd within my Windows application?
The cause: It's due to pre-compiled dlls for Windows implictly linking against Pd/bin/pd.dll. The external dll get's unloaded when it's pd.dll dependency can not be found.
The solution: Modify the libpd MINGW makefile so that the library output is pd.dll instead of libpd.dll
Many thanks to the help from @Chrisof, who also kindly submitted a PR with some more discussion here: https://github.com/libpd/libpd/pull/241
Thanks, Joe
On 21 May 2018 at 11:38, Christof Ressi christof.ressi@gmx.at wrote:
hmmm, I might try it myself in the next few days.
BTW,
also using the windows .lib to statically import the symbols.
the import library (.lib) is only necessary if you work with MSVC, GCC can directly link to a DLL
Gesendet: Montag, 21. Mai 2018 um 12:10 Uhr Von: "Joe White" white.joe4@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: Re: [PD] Using externals with libpd on Windows
I'm linking against libpd dynamically, also using the windows .lib to statically import the symbols.
On 18 May 2018 at 19:35, Christof Ressi <christof.ressi@gmx.at[mailto: christof.ressi@gmx.at]> wrote:just to be sure: are you using a static or dynamic version of libpd in your program?
Gesendet: Freitag, 18. Mai 2018 um 17:38 Uhr Von: "Joe White" <white.joe4@gmail.com[mailto:white.joe4@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> Cc: Pd-list <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> Betreff: Re: [PD] Using externals with libpd on Windows
Thanks for the info Christof!
It seems to me that compiling libpd via the makefile [0] in mingw already exports all the symbols correctly.
Seems like the solution in your link [1] suggests to export the symbols in the exe, and also update the plugins to load the functions via GetProcAddress. I'm trying to avoid touching the 3rd party externals if possible as I can already re-link them against the libpd.dll but don't feel that is very maintainable.
Has anyone managed to successfully load pre-compiled externals in a libpd-embedded Windows application?
I'm currently trying to see if it's possible to point the externals to the find the pd symbols elsewhere as they get loaded, but my hopes aren't high!
Thanks, Joe
[0] https://github.com/libpd/libpd/blob/master/Makefile# L23[https://github.com/libpd/libpd/blob/master/Makefile#L23] [1] http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW][http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW]]
On 11 May 2018 at 20:04, Christof Ressi <christof.ressi@gmx.at[mailto: christof.ressi@gmx.at][mailto:christof.ressi@gmx.at[mailto:c hristof.ressi@gmx.at]]> wrote:yes, this is a limitation on windows where a DLL can't automatically import symbols from the executable where it was loaded (what you get on Linux with --export-dynamic). for Pd the solution is to make the app itself a thin wrapper around a DLL (pd.dll) which plugins can link to.
I found this link which might be helpful:
http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW][http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343- RESOLVED-accessing-symbols-in-appllication-from-within- dynamic-library-MinGW]]
I guess if you compile libpd as a DLL (with "--export-all-symbols") existing externals should load.
Gesendet: Freitag, 11. Mai 2018 um 19:21 Uhr Von: "Joe White" <white.joe4@gmail.com[mailto:white.joe4@gmail.com ][mailto:white.joe4@gmail.com[mailto:white.joe4@gmail.com]]> An: Pd-list <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at][mailto:pd -list@lists.iem.at[mailto:pd-list@lists.iem.at]]> Betreff: [PD] Using externals with libpd on Windows
Hi all,
I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.
The patch was using vbap [0] and soundfile_info from iemlib [1].
The issue I found was that the pre-built binaries that work in the window version of the Pd authoring environment were linking against pd.dll (I'm assuming from Pd/bin/) in order to correctly link against the plugin API methods exposed in m_pd.h.
The solution I recently came to, though admittedly a bit of a hack, was to generate a custom VS2017 dll project for both vbap, and soundfile_info, include the relevant source files, and link against the compiled version of libpd to resolve the missing symbols instead of the authoring libraries.
The downside of this approach is that the manually compiled externals will no longer run in the Pd authoring environment, and it's not really maintainable from a development perspective.
From my days of making externals for macos, I don't think I ever had to link against Pd, but just include m_pd.h and be done.
My question is whether this is usual behaviour when working with externals/libpd on Windows or if I'm missing something somewhere?
Any perspective would be much appreciated!
Thanks, Joe
[0] https://puredata.info/downloads/vbap%5Bhttps:// puredata.info/downloads/vbap][1][https://puredata.info/ downloads/vbap[https://puredata.info/downloads/vbap][1]] https://git.iem.at/pd/iemlib%5Bhttps://git.iem.at/pd/ iemlib]_______________________________________________[ https://git.iem.at/pd/iemlib%5Bhttps://git.iem.at/pd/iemlib%5D_ ______________________________________________][https://git. iem.at/pd/iemlib[https://git.iem.at/pd/iemlib]_____________ __________________________________[https://git.iem.at/pd/ iemlib[https://git.iem.at/pd/iemlib]_______________________ ________________________]] Pd-list@lists.iem.at[mailto:Pd -list@lists.iem.at][mailto:Pd-list@lists.iem.at[mailto:Pd- list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list][https://lists. puredata.info/listinfo/pd-list[https://lists.puredata. info/listinfo/pd-list]][https://lists.puredata.info/ listinfo/pd-list[https://lists.puredata.info/listinfo/ pd-list][https://lists.puredata.info/listinfo/pd- list[https://lists.puredata.info/listinfo/pd-list]]]
Joe White wrote:
Hi all,
I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.
The patch was using /vbap/ [0] and /soundfile_info/ from iemlib [1].
hi,
just the other night i was hacking together a [sound_file] info alternative with purely vanilla objects WITHOUT loading an entire file into RAM.
the method is basically to use [soundfiler] to load 1 sample of a file into a table with a -skip message, and recalculate the skip position until [soundfiler]'s left outlet outputs 1 (instead of 0).
all of [soundfile_info]'s other values are also output from [soundfiler]'s right outlet as of PD version 0.48.
it takes a tad longer than [soundfile_info] to output the soundfile's length, but it's acceptable imho. plus you can use .aiff too !
best
oliver
a new flag for [soundfiler] will make this easier without the need of a dummy buffer
see https://github.com/pure-data/pure-data/pull/193
2018-05-12 14:06 GMT-03:00 oliver oliver@klingt.org:
Joe White wrote:
Hi all,
I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.
The patch was using /vbap/ [0] and /soundfile_info/ from iemlib [1].
hi,
just the other night i was hacking together a [sound_file] info alternative with purely vanilla objects WITHOUT loading an entire file into RAM.
the method is basically to use [soundfiler] to load 1 sample of a file into a table with a -skip message, and recalculate the skip position until [soundfiler]'s left outlet outputs 1 (instead of 0).
all of [soundfile_info]'s other values are also output from [soundfiler]'s right outlet as of PD version 0.48.
it takes a tad longer than [soundfile_info] to output the soundfile's length, but it's acceptable imho. plus you can use .aiff too !
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Hey Oliver,
This is a neat trick, however for my purposes [soundfle_info] was being used to extract both the sample rate and sample length to calculate the duration of the file.
Looks like in order to switch to [soundfiler] I'd have to load the whole
file to memory regardless, as the -skip 1 flag means the left outlet
(sample length) of [soundfiler] only outputs '1'.
Cheers, Joe
On 12 May 2018 at 19:37, Alexandre Torres Porres porres@gmail.com wrote:
a new flag for [soundfiler] will make this easier without the need of a dummy buffer
see https://github.com/pure-data/pure-data/pull/193
2018-05-12 14:06 GMT-03:00 oliver oliver@klingt.org:
Joe White wrote:
Hi all,
I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.
The patch was using /vbap/ [0] and /soundfile_info/ from iemlib [1].
hi,
just the other night i was hacking together a [sound_file] info alternative with purely vanilla objects WITHOUT loading an entire file into RAM.
the method is basically to use [soundfiler] to load 1 sample of a file into a table with a -skip message, and recalculate the skip position until [soundfiler]'s left outlet outputs 1 (instead of 0).
all of [soundfile_info]'s other values are also output from [soundfiler]'s right outlet as of PD version 0.48.
it takes a tad longer than [soundfile_info] to output the soundfile's length, but it's acceptable imho. plus you can use .aiff too !
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 2018-05-24 15:03, Joe White wrote:
Hey Oliver,
This is a neat trick, however for my purposes [soundfle_info] was being used to extract both the sample rate and sample length to calculate the duration of the file.
Looks like in order to switch to [soundfiler] I'd have to load the whole file to memory regardless, as the
-skip 1flag means the left outlet (sample length) of [soundfiler] only outputs '1'.
have a look again.
in the middle of the patch, i use soundfiler's right outlet (available since PD 0.48, so make sure you are using this !) to get the file's samplerate, even though it is just reading 1 sample of it. so, no need to load the whole thing.
the left part of the patch gives you the file's length in samples, which you can then re-calculate (using the file's samplerate) to ms or whatever you need.
yes, the left outlet always only puts out 1 or 0, which i use to narrow down the last valid sample position, which is then the file's length in samples (endpoint).
i send the patch again to illustrate what i mean (unless i misunderstood something)
best
oliver
Cheers, Joe
On 12 May 2018 at 19:37, Alexandre Torres Porres porres@gmail.com wrote:
a new flag for [soundfiler] will make this easier without the need of a dummy buffer
see https://github.com/pure-data/pure-data/pull/193 [1]
2018-05-12 14:06 GMT-03:00 oliver oliver@klingt.org:
Joe White wrote: Hi all,
I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.
The patch was using /vbap/ [0] and /soundfile_info/ from iemlib [1].
hi,
just the other night i was hacking together a [sound_file] info alternative with purely vanilla objects WITHOUT loading an entire file into RAM.
the method is basically to use [soundfiler] to load 1 sample of a file into a table with a -skip message, and recalculate the skip position until [soundfiler]'s left outlet outputs 1 (instead of 0).
all of [soundfile_info]'s other values are also output from [soundfiler]'s right outlet as of PD version 0.48.
it takes a tad longer than [soundfile_info] to output the soundfile's length, but it's acceptable imho. plus you can use .aiff too !
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list [2]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list [2]
Links:
[1] https://github.com/pure-data/pure-data/pull/193 [2] https://lists.puredata.info/listinfo/pd-list
Hey Oliver,
I will admit to not fully digesting your patch, but from skim reading it I'm assuming it loops over the sample data by incrementing the -skip argument until you reach the end of the file. For my purposes memory usage isn't really an issue, so I'd imagine it would be far quicker to just load the whole sample into the table.
What would be nice is if [soundfiler] additionally read the data chunk size property in the wav header for the number of samples. I imagine that's why [soundfile_info] was created in the first place.
Cheers, Joe
On 24 May 2018 at 14:38, oliver oliver@klingt.org wrote:
On 2018-05-24 15:03, Joe White wrote:
Hey Oliver,
This is a neat trick, however for my purposes [soundfle_info] was being used to extract both the sample rate and sample length to calculate the duration of the file.
Looks like in order to switch to [soundfiler] I'd have to load the whole file to memory regardless, as the
-skip 1flag means the left outlet (sample length) of [soundfiler] only outputs '1'.have a look again.
in the middle of the patch, i use soundfiler's right outlet (available since PD 0.48, so make sure you are using this !) to get the file's samplerate, even though it is just reading 1 sample of it. so, no need to load the whole thing.
the left part of the patch gives you the file's length in samples, which you can then re-calculate (using the file's samplerate) to ms or whatever you need.
yes, the left outlet always only puts out 1 or 0, which i use to narrow down the last valid sample position, which is then the file's length in samples (endpoint).
i send the patch again to illustrate what i mean (unless i misunderstood something)
best
oliver
Cheers, Joe
On 12 May 2018 at 19:37, Alexandre Torres Porres porres@gmail.com wrote:
a new flag for [soundfiler] will make this easier without the need
of a dummy buffer
see https://github.com/pure-data/pure-data/pull/193 [1]
2018-05-12 14:06 GMT-03:00 oliver oliver@klingt.org:
Joe White wrote: Hi all,
I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.
The patch was using /vbap/ [0] and /soundfile_info/ from iemlib [1].
hi,
just the other night i was hacking together a [sound_file] info alternative with purely vanilla objects WITHOUT loading an entire file into RAM.
the method is basically to use [soundfiler] to load 1 sample of a file into a table with a -skip message, and recalculate the skip position until [soundfiler]'s left outlet outputs 1 (instead of 0).
all of [soundfile_info]'s other values are also output from [soundfiler]'s right outlet as of PD version 0.48.
it takes a tad longer than [soundfile_info] to output the soundfile's length, but it's acceptable imho. plus you can use .aiff too !
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list [2]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list [2]
Links:
[1] https://github.com/pure-data/pure-data/pull/193 [2] 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 2018-05-24 16:43, Joe White wrote:
Hey Oliver,
I will admit to not fully digesting your patch, but from skim reading it I'm assuming it loops over the sample data by incrementing the -skip argument until you reach the end of the file.
well, more like see-sawing between a possible maximum of samples and 0, and then find the last valid point "in the middle"
For my purposes
memory usage isn't really an issue, so I'd imagine it would be far quicker to just load the whole sample into the table.
depends on the length of the file. if it's a 30 minute file, this will freeze PD and probably lock the memory too. my approach tries to overcome that. and also is of course much faster than waiting for a long file to get loaded into RAM just to know its length.
What would be nice is if [soundfiler] additionally read the data chunk size property in the wav header for the number of samples. I imagine that's why [soundfile_info] was created in the first place.
yes, that would be the nicest solution !
as alex pointed out, this is already a pull request. so, probably available in PD 0.49 ...
https://github.com/pure-data/pure-data/pull/193
until that, it's either [soundfile_info] or a workaround, like i proposed
best
oliver
-
Alexandre Torres Porres -
Christof Ressi -
Joe White -
oliver