I had a thought recently: if we treat Pd like Java, ie like a
framework to be installed, then all we need to do is make a nice
cross-platform app packaging format. To make this work, we'd need to
have file associations working. They already work beautifully on Mac
OS X, and basically work on Windows (but every double-click opens a
new instance of Pd).
If there was a format were you could bundle all needed files into a
double-clickable file format, then it would work much like an app as
long as you have Pd installed.
Think this could work? I am thinking something like .jar format.
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes.
Now that he can realize them, he must either change them, or perish.
-William Carlos
Williams
Think this could work? I am thinking something like .jar format.
considering one can already bundle code libraries in the same directory as patches/abstractions, what advantage does a format like .jar provide to offset the annoyance of having something to decompress when you want to start mucking with it?
I had a thought recently: if we treat Pd like Java, ie like a framework to be installed, then all we need to do is make a nice cross-platform app packaging format. To make this work, we'd need to have file associations working. They already work beautifully on Mac OS X, and basically work on Windows (but every double-click opens a new instance of Pd).
i'd hate to have 10 copies of maxlib just because it was in a .jar, or 30 copies of pthreadVC.dll. but those are facts of life on an OS whose idea of packaging is "click setup and click 'next' 10 times" or "search the web, download a disk image, decompress a disk image, copy something off a disk image, unmount the disk image, delete the disk image"..
If there was a format were you could bundle all needed files into a double-clickable file format, then it would work much like an app as long as you have Pd installed.
im definitely for the idea of smarter package management. but i dont htink .jar is the solution. perhaps mapping the gige/hcs namespace to a webservice so one can go to http://pure-data.info/library/osc/route/ and there are your binaries in subdirs like i386-linux/ mac-x86/, online docs, etc...
On Sun, 7 May 2006, carmen wrote:
Think this could work? I am thinking something like .jar format.
considering one can already bundle code libraries in the same directory as patches/abstractions, what advantage does a format like .jar provide to offset the annoyance of having something to decompress when you want to start mucking with it?
It would be one single file which you double'click to run. Easy to move, copy, and execute. Plus it provides a small hurdle to modifying the contents, which makes it less likely that people will inadvertently break it, say by modifying one of the internal files by accident.
I had a thought recently: if we treat Pd like Java, ie like a framework to be installed, then all we need to do is make a nice cross-platform app packaging format. To make this work, we'd need to have file associations working. They already work beautifully on Mac OS X, and basically work on Windows (but every double-click opens a new instance of Pd).
i'd hate to have 10 copies of maxlib just because it was in a .jar, or 30 copies of pthreadVC.dll. but those are facts of life on an OS whose idea of packaging is "click setup and click 'next' 10 times" or "search the web, download a disk image, decompress a disk image, copy something off a disk image, unmount the disk image, delete the disk image"..
That's the idea of Pd-extended as a platform. If someone was already writing applications using Pd-extended, then its highly unlikely that they would go out of there way to copy files from Pd-extended install to their .jar thingy.
If there was a format were you could bundle all needed files into a double-clickable file format, then it would work much like an app as long as you have Pd installed.
im definitely for the idea of smarter package management. but i dont htink .jar is the solution. perhaps mapping the gige/hcs namespace to a webservice so one can go to http://pure-data.info/library/osc/route/ and there are your binaries in subdirs like i386-linux/ mac-x86/, online docs, etc...
I think you misunderstand a bit. I am talking more about a application format rather than a library format here. THe idea is something that would be a double-clickable app in one file that would include any dependencies that are not in the standard platform. That's basically what a .jar is used for. This format would also work nicely for distributing libraries that are not included in the standard install.
.hc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
zen
\
\
\[D[D[D[D
This would be a wonderful thing, because I was just trying to load up PixelTANGO on my buddy's windows comp today, and we kept crashing it when pt.window would be opened in a patch (another story, I know).
But, it took a while to get it all going, even though pd-extended was friggin awesome to install on windows!! Good job there, Hans!
If only there would be a nice way to have stand-alone pd apps, then art installations would be much easier to maintain w/ non-expert curators, etc. Also, more people would be able to use Pd creations (like musicians who aren't computer saavy). This would rule because dudes like us could create custom patches for these musicians (and maybe make a little cash on the side)!
Another note is this: How can we get a VST/Audiounits/whatever kind of framework going that can be used in the various host system out there? I'm dying to have interoperability in this department!
~Kyle
On 5/15/06, Hans-Christoph Steiner hans@eds.org wrote:
On Sun, 7 May 2006, carmen wrote:
Think this could work? I am thinking something like .jar format.
considering one can already bundle code libraries in the same directory as patches/abstractions, what advantage does a format like .jar provide to offset the annoyance of having something to decompress when you want to start mucking with it?
It would be one single file which you double'click to run. Easy to move, copy, and execute. Plus it provides a small hurdle to modifying the contents, which makes it less likely that people will inadvertently break it, say by modifying one of the internal files by accident.
I had a thought recently: if we treat Pd like Java, ie like a framework to be installed, then all we need to do is make a nice cross-platform app packaging format. To make this work, we'd need to have file associations working. They already work beautifully on Mac OS X, and basically work on Windows (but every double-click opens a new instance of Pd).
i'd hate to have 10 copies of maxlib just because it was in a .jar, or 30 copies of pthreadVC.dll. but those are facts of life on an OS whose idea of packaging is "click setup and click 'next' 10 times" or "search the web, download a disk image, decompress a disk image, copy something off a disk image, unmount the disk image, delete the disk image"..
That's the idea of Pd-extended as a platform. If someone was already writing applications using Pd-extended, then its highly unlikely that they would go out of there way to copy files from Pd-extended install to their .jar thingy.
If there was a format were you could bundle all needed files into a double-clickable file format, then it would work much like an app as long as you have Pd installed.
im definitely for the idea of smarter package management. but i dont htink .jar is the solution. perhaps mapping the gige/hcs namespace to a webservice so one can go to http://pure-data.info/library/osc/route/ and there are your binaries in subdirs like i386-linux/ mac-x86/, online docs, etc...
I think you misunderstand a bit. I am talking more about a application format rather than a library format here. THe idea is something that would be a double-clickable app in one file that would include any dependencies that are not in the standard platform. That's basically what a .jar is used for. This format would also work nicely for distributing libraries that are not included in the standard install.
.hc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
zen \ \ \[D[D[D[D
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Another note is this: How can we get a VST/Audiounits/whatever kind of framework going that can be used in the various host system out there? I'm dying to have interoperability in this department!
you might be interested in the genesis of LV2, nee LADSPA v2. there's nothing stopping it from running on many platforms besides developer motivation; in contrast, you will likely never see AudioUnits on Windows or linux, and VST will always be a 2nd class citizen on OSX and 4th, 5th, or beyond on linux..
one of the goals, in addition to potential cross-platformability, is increasing the flexibility of the type/ports system to the point of 'PD external without PD'. i find it pretty exciting..
-
carmen -
carmen -
Hans-Christoph Steiner -
Kyle Klipowicz