Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux.
I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd?
Thanks, Katja
Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them.
I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way.
.hc
On Dec 7, 2012, at 6:50 PM, katja wrote:
Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux.
I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd?
Thanks, Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK if these extensions are introduced in Pd 0.42 or earlier, it is safe to use them now. And I definitely will.
Hans, I can see why libraries in Pd-extended must not go this way. But for projects which are not (yet) in Pd-E, the 'bitwise' extension is a great solution, as you can simply distribute one package with no complicated instructions for the user of what to get and what to put where. It also simplifies building such projects. Very useful in projects which are too individual or experimental to get into Pd-E, or libs which are in testing phase, like when porting a lib to Pd.
I also like the 'apt-get-for-Pd-' idea, where external libs could live decentralized in various repos. This would give developers more autonomy and a clearer responsability over their libs.
Katja
On Sat, Dec 8, 2012 at 2:09 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them.
I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way.
.hc
On Dec 7, 2012, at 6:50 PM, katja wrote:
Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux.
I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd?
Thanks, Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
... or indeed, to distribute a patch with a piece of music, for example - it's best if the patch works cross-platform, and for that, any externs should be bundled with a variety of compiled versions, which then need individual filenames. I think in general, if you're distributing software, compiling it specificly and separately for different platforms (as is Pd extended) is the best way to go, but when distributing something that functions as a document, you'd like one version to work the same everywhere. So it's appropriate that Pd supports (or at least tries to support) both models.
cheers Miller
On Sat, Dec 08, 2012 at 11:40:21AM +0100, katja wrote:
OK if these extensions are introduced in Pd 0.42 or earlier, it is safe to use them now. And I definitely will.
Hans, I can see why libraries in Pd-extended must not go this way. But for projects which are not (yet) in Pd-E, the 'bitwise' extension is a great solution, as you can simply distribute one package with no complicated instructions for the user of what to get and what to put where. It also simplifies building such projects. Very useful in projects which are too individual or experimental to get into Pd-E, or libs which are in testing phase, like when porting a lib to Pd.
I also like the 'apt-get-for-Pd-' idea, where external libs could live decentralized in various repos. This would give developers more autonomy and a clearer responsability over their libs.
Katja
On Sat, Dec 8, 2012 at 2:09 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them.
I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way.
.hc
On Dec 7, 2012, at 6:50 PM, katja wrote:
Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux.
I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd?
Thanks, Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Bundling externals for all the different platforms is workable at them moment for those who can handle building software, and have access to machines that can build for all the target environments.
Along those lines, I think we can make it easy to take that idea all the way by smoothing the process of getting artworks into Debian or at least packaged so that people can either 'apt-get install myworkofgenius' or easily build a live CD that boots straight into 'myworkofgenius' on just about any x86 computer.
I think this approach is much easier to automate and therefore easier to make straightforward for non-technical people. Plus there are already lots of people working on making live CDs that work (puredyne, Fedora, Ubuntu, Knoppix, Debian, etc. etc.).
Pd-extended on Mac OS X will also build a double-clickable MyWorkOfGenius.app with all the libraries embedded inside. I haven't heard much feedback about it, so I wonder how its working for people.
.hc
On Dec 8, 2012, at 12:40 PM, Miller Puckette wrote:
... or indeed, to distribute a patch with a piece of music, for example - it's best if the patch works cross-platform, and for that, any externs should be bundled with a variety of compiled versions, which then need individual filenames. I think in general, if you're distributing software, compiling it specificly and separately for different platforms (as is Pd extended) is the best way to go, but when distributing something that functions as a document, you'd like one version to work the same everywhere. So it's appropriate that Pd supports (or at least tries to support) both models.
cheers Miller
On Sat, Dec 08, 2012 at 11:40:21AM +0100, katja wrote:
OK if these extensions are introduced in Pd 0.42 or earlier, it is safe to use them now. And I definitely will.
Hans, I can see why libraries in Pd-extended must not go this way. But for projects which are not (yet) in Pd-E, the 'bitwise' extension is a great solution, as you can simply distribute one package with no complicated instructions for the user of what to get and what to put where. It also simplifies building such projects. Very useful in projects which are too individual or experimental to get into Pd-E, or libs which are in testing phase, like when porting a lib to Pd.
I also like the 'apt-get-for-Pd-' idea, where external libs could live decentralized in various repos. This would give developers more autonomy and a clearer responsability over their libs.
Katja
On Sat, Dec 8, 2012 at 2:09 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them.
I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way.
.hc
On Dec 7, 2012, at 6:50 PM, katja wrote:
Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux.
I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd?
Thanks, Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/8/12, Hans-Christoph Steiner hans@at.or.at wrote:
Pd-extended on Mac OS X will also build a double-clickable MyWorkOfGenius.app with all the libraries embedded inside. I haven't heard much feedback about it, so I wonder how its working for people.
.hc
I did use the 'make-an-app' option, it works great but it makes a large app file which is not easy to distribute from a homepage with 'fair use policy' and certainly not via a forum or mailing list. For that reason I prefer to package patches plus specific source files and binaries only. With the advantage that it works on 'all' platforms. And the disadvantage that I have to build on all platforms. This poses a natural limit on my ambitions to publish new projects. Maybe not so bad after all...
Katja
At this point, to get the apt-get idea works, someone just needs to write the client for downloading from the repo. There is a standard library format with the meta subpatch for things like version. It would probably be easy to write in Tcl, then it could be incorporated into the Pd GUI or as a plugin in the meantime.
.hc
On Dec 8, 2012, at 5:40 AM, katja wrote:
OK if these extensions are introduced in Pd 0.42 or earlier, it is safe to use them now. And I definitely will.
Hans, I can see why libraries in Pd-extended must not go this way. But for projects which are not (yet) in Pd-E, the 'bitwise' extension is a great solution, as you can simply distribute one package with no complicated instructions for the user of what to get and what to put where. It also simplifies building such projects. Very useful in projects which are too individual or experimental to get into Pd-E, or libs which are in testing phase, like when porting a lib to Pd.
I also like the 'apt-get-for-Pd-' idea, where external libs could live decentralized in various repos. This would give developers more autonomy and a clearer responsability over their libs.
Katja
On Sat, Dec 8, 2012 at 2:09 AM, Hans-Christoph Steiner hans@at.or.at wrote:
Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them.
I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way.
.hc
On Dec 7, 2012, at 6:50 PM, katja wrote:
Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux.
I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd?
Thanks, Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 08/12/12 07:50, katja wrote:
Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux.
it would be better to use .pd_li386 or something like that, since it is good to be able to search for name.pd* in your filesystem to find the file for [name] without knowing if it is an abstraction or external. Given the way pd/extra is organised this is important, it is not at all obvious where to look.
For example here on debian if I am missing an object in a patch I can find the packages that could supply it, and where they would put it ...
$ apt-file search uzi.pd pd-cyclone: /usr/lib/pd/extra/cyclone/uzi.pd_linux pd-pmpd: /usr/lib/pd/extra/pmpd/examples/ch_uzi.pd pd-purepd: /usr/lib/pd/extra/purepd/uzi.pd
.. or I could search locally in my files system to find which library the file is in.
But this would not find uzi.l_ia64 and just searching for uzi finds 60 mostly irrelevant files which happen to have "uzi" somewhere in the name.
Simon
-
Hans-Christoph Steiner -
katja -
Miller Puckette -
Simon Wise