[PD] Pd-style executable

Kyle Klipowicz kyleklip at gmail.com
Tue May 16 05:04:54 CEST 2006

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!


On 5/15/06, Hans-Christoph Steiner <hans at 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 at iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >
>         zen
>            \
>             \
>              \
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list




More information about the Pd-list mailing list