In Max/MSP you can save (compile) your patches into various plug-ins or applications. I was wondering can this be done in Pd (which is what I use at home) If it can , could someone let me know please, it would be MUCH!!! appreciated
cheers steve
Steve Peach wrote:
In Max/MSP you can save (compile) your patches into various plug-ins or applications. I was wondering can this be done in Pd (which is what I use at home) If it can , could someone let me know please, it would be MUCH!!! appreciated
it cannot be done. why should it? (the reason for max/msp to offer this possibility is in its proprietary nature. for pd this is not necessary: just give away your patches + pd)
fmga.sdr. IOhannes
On Fri, 27 Jan 2006, IOhannes m zmoelnig wrote:
Steve Peach wrote:
In Max/MSP you can save (compile) your patches into various plug-ins or applications. I was wondering can this be done in Pd (which is what I use at home) If it can , could someone let me know please, it would be MUCH!!! appreciated
it cannot be done. why should it? (the reason for max/msp to offer this possibility is in its proprietary nature. for pd this is not necessary: just give away your patches + pd)
The problem is that just giving away a working pd that will continue to work on the target computer is not always easy.
Does Pd have any "static-linked" version or otherwise self-contained? If externals have dependencies, is there anything that can copy those dependencies inside of a directory that can easily by zipped and shipped?
It doesn't have much to do with proprietary vs free.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Fri, 27 Jan 2006, IOhannes m zmoelnig wrote:
Steve Peach wrote:
In Max/MSP you can save (compile) your patches into various plug-ins or applications. I was wondering can this be done in Pd (which is what I use at home) If it can , could someone let me know please, it would be MUCH!!! appreciated
it cannot be done. why should it? (the reason for max/msp to offer this possibility is in its proprietary nature. for pd this is not necessary: just give away your patches + pd)
The problem is that just giving away a working pd that will continue to work on the target computer is not always easy.
Does Pd have any "static-linked" version or otherwise self-contained? If externals have dependencies, is there anything that can copy those dependencies inside of a directory that can easily by zipped and shipped?
since i am no max-user i might talk nonsense here: but i don't think that a compiled max-patch is totally self-contained (i mean: it lacks the dependency on max; but what else?)
if you want to make sure that you have "everything" at hand, i would suggest to put your patch + pd + all externals + all secondary libraries onto a linux live-cd (based on pure::dyne or knoppix or whatever you want).
this way you only need a computer which is able to put from CDrom.
i don't know whether it is possible to make CDroms that are bootable for several architectures (like i386 AND PowerPC). however, i daresay that max/msp-"binaries" are not cross-platform either. the only cross-platform way would be to use plain pd-patches...
It doesn't have much to do with proprietary vs free.
it does have a lot to do with proprietary vs free. the main reason for max/msp to offer the functionality of compiling a patch into an executable is, that you can give away your patches to people who do not own max/msp (and/or are not willing to pay for it)
mf.asr IOhannes
Le 27 Janvier 2006 13:55, IOhannes m zmoelnig a écrit :
since i am no max-user i might talk nonsense here: but i don't think that a compiled max-patch is totally self-contained (i mean: it lacks the dependency on max; but what else?)
I remember from the old days of MacOS7 that a Max player was an runtime Max with embedded patches and externals in its "resource fork". For example, using ResEdit, I extracted the patch from the iCube player. -- Marc
On Fri, 27 Jan 2006, IOhannes m zmoelnig wrote:
since i am no max-user i might talk nonsense here: but i don't think that a compiled max-patch is totally self-contained (i mean: it lacks the dependency on max; but what else?)
Actually I didn't mean something totally self-contained, I meant something that can run on the base OS. On Linux this is quite fuzzy but still libquicktime may be considered for bundling while libc doesn't have to be bundled, because libquicktime isn't available on all linux setups.
It doesn't have much to do with proprietary vs free.
it does have a lot to do with proprietary vs free. the main reason for max/msp to offer the functionality of compiling a patch into an executable is, that you can give away your patches to people who do not own max/msp (and/or are not willing to pay for it)
Oops, you are right, sorry. I don't know what I was thinking about.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 27, 2006, at 1:41 PM, Mathieu Bouchard wrote:
On Fri, 27 Jan 2006, IOhannes m zmoelnig wrote:
Steve Peach wrote:
In Max/MSP you can save (compile) your patches into various plug-ins or applications. I was wondering can this be done in Pd (which is
what I use at home) If it can , could someone let me know please, it would be MUCH!!! appreciatedit cannot be done. why should it? (the reason for max/msp to offer
this possibility is in its proprietary nature. for pd this is not
necessary: just give away your patches + pd)The problem is that just giving away a working pd that will continue to work on the target computer is not always easy.
Does Pd have any "static-linked" version or otherwise self-contained?
If externals have dependencies, is there anything that can copy those dependencies inside of a directory that can easily by zipped and
shipped?It doesn't have much to do with proprietary vs free.
Pd-extended is self-contained. That's a big motivation in the creation
of it.
But compiling Pd patches isn't purely a question of proprietary vs
free. If Pd could be compiled, it could run on embedded systems like
mobile phones and microcontrollers. It would be quite difficult to
make a Pd port to Microchip PIC.
Its also a question of flexibility, it would be a nice feature to have.
But its probably not easy to implement.
.hc
¡El pueblo unido jamás será vencido!
On Fri, 27 Jan 2006, Hans-Christoph Steiner wrote:
Pd-extended is self-contained. That's a big motivation in the creation of it.
btw, on win32 it's missing PYTHON24.DLL
But compiling Pd patches isn't purely a question of proprietary vs free.
If Pd could be compiled, it could run on embedded systems like mobile phones and microcontrollers. It would be quite difficult to make a Pd port to Microchip PIC.
Yeah, there's compiling, compiling, and then there's compiling too. I see three things here conflated into one:
making something sufficiently self-contained
translating a program from one language (.pd) to another (machinecode
or bytecode or even another more efficient high-level language e.g. C++)
- cutting on the fat (space): removing unneeded libraries, classes, functions, variables, etc.
Its also a question of flexibility, it would be a nice feature to have.
But its probably not easy to implement.
(1) is mostly done by pd-extended
(2) is very difficult. If I were whoever, I wouldn't attempt it without a completely working PureUnity (tm) test suite. Then I would add functions to Pd's API so that the classes may participate in the compilation by giving hints to the compiler because else there won't be that much to optimize.
(3) would be partially doable now, in the form of providing the user with a generator for custom pd-extended distributions, which would contain only the necessary files. Breaking down libraries into single classes helps eliminate the maximum possible of unused classes just by looking for unused files. Finer-grained space-saving requires compiler-driven surgery (Frankenstein on the PIC).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi Steve,
Steve Peach wrote:
In Max/MSP you can save (compile) your patches into various plug-ins or applications. I was wondering can this be done in Pd (which is what I use at home) If it can , could someone let me know please, it would be MUCH!!! appreciated
Max/MSP and other commercial softwares make stand-alone apps in order to get around the fact that each copy of the program is licensed to one machine, or to hide the structure of work made with them. Being free and open source, PD lacks that ability. To get the same functionality, you would simply have to distribute your patch with a version of PD suited for whatever platform you wanted it to run on (don't forget the externals!). This is a lot less simple than making a standalone, however. Perhaps a simpler solution would be to make sure your PD patch works with one of the available installers and distribute it with that. The benefit of the situation is that whoever gets your patch is free to open it up and change it if they like, an option which is unavailable with commercial stand-alones.
As far as plugins, you could check out PDVST to get PD running as a VST/VSTi under windows:
http://crca.ucsd.edu/~jsarlo/pdvst/
Besides running PD in a VST host, you could also run it alongside whatever other app you are using, and connect them together using OSC for data, MIDI for control and JACK for audio (if you are on Linux or OSX). This should approximate most of what you would gain from having a true plug-in system, except maybe for presets and BPM syncing (both of which could be programmed into your PD patches with some work). It's not Pluggo, but it's not useless either.
good luck, d.
Does PDVST actually work? I could never get it to run (on Windowze XP), has anyone ever gotten it to run successfully?
I personally think that the ability to compile PD patches would be extremely helpful, regardless of the fact that it is open source. Sometimes the whole open source perspective gets too focused on needs of developers, and not on needs of musicians and composers and end users, who might just want a cool application to play with.
I would love to build an application to share with my friends, that I could package as a self-contained unit. If I could compile it as Audio Unit and VST, that would be even better. Until that day, I prefer commercial software to make things to share. It's just easier to give away a VST, than try and get pure data installed in many cases. If it was built with PD, then those interested could also see the source patch, but only if they wanted to bother with that.
It personally took me months, and several version changes, until finally Hans released the PD Extended-RC7, to get PD going with a decent amount of externals. Well, at least now I can finally recommend it to my friends, which I could not do when things were always broken...
~David
As far as plugins, you could check out PDVST to get PD running as a VST/VSTi under windows:
http://crca.ucsd.edu/~jsarlo/pdvst/
Besides running PD in a VST host, you could also run it alongside whatever other app you are using, and connect them together using OSC for data, MIDI for control and JACK for audio (if you are on Linux or OSX). This should approximate most of what you would gain from having a true plug-in system, except maybe for presets and BPM syncing (both of which could be programmed into your PD patches with some work). It's not Pluggo, but it's not useless either.
good luck, d.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 18: "Balance the consistency principle with the inconsistency principle"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, cyborgk@nocturnalnoize.com hat gesagt: // cyborgk@nocturnalnoize.com wrote:
I personally think that the ability to compile PD patches would be extremely helpful, regardless of the fact that it is open source. Sometimes the whole open source perspective gets too focused on needs of developers, and not on needs of musicians and composers and end users, who might just want a cool application to play with.
I would love to build an application to share with my friends, that I could package as a self-contained unit.
Hm, I share Pd patches with people on and off this list for years now, it never was a big problem to use patches made by someone else, so I don't see where the problem is? Is it installing externals? Difficulties in installing externals won't be fixed by standalone Pd patches, it will be fixed by getting e.g. Pd-extended to run and install easily everywhere.
Pd is free software, everyone can install it and IMO everyone interested in sound software should have a copy installed anyway, if just to quickly built little helper tools to convert Midi to OSC or similar.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hm, I share Pd patches with people on and off this list for years now, it never was a big problem to use patches made by someone else, so I don't see where the problem is? Is it installing externals?
its knowing which externals to use, in the nameclash sense, as well as in the nondescript error in the scroll like: expected float but got '', etc. practically impossible to even tell which object it is talking about...
On Jan 30, 2006, at 11:01 PM, cdr wrote:
Hm, I share Pd patches with people on and off this list for years now, it never was a big problem to use patches made by someone else, so I don't see where the problem is? Is it installing externals?
its knowing which externals to use, in the nameclash sense, as well as
in the nondescript error in the scroll like: expected float but got
'', etc. practically impossible to even tell which object it is
talking about...
This demonstrates why I am pushing for a namespace. If each patch has
a namespace, then that patch can save which versions of the objects it
uses as part of the patch.
Plus that error message should be more descriptive, its maddeningly
useless.
.hc ________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity."
-John Gilmore
Hallo, cdr hat gesagt: // cdr wrote:
Hm, I share Pd patches with people on and off this list for years now, it never was a big problem to use patches made by someone else, so I don't see where the problem is? Is it installing externals?
its knowing which externals to use, in the nameclash sense, as well as in the nondescript error in the scroll like: expected float but got '', etc. practically impossible to even tell which object it is talking about...
Here again making Pd patches compilable is not fixing the underlying problem - which is a problem, but none that ever stopped us all here from sharing patches.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Does PDVST actually work? I could never get it to run (on Windowze XP), has anyone ever gotten it to run successfully?
I personally think that the ability to compile PD patches would be extremely helpful, regardless of the fact that it is open source. Sometimes the whole open source perspective gets too focused on needs of developers, and not on needs of musicians and composers and end users, who might just want a cool application to play with.
I would love to build an application to share with my friends, that I could package as a self-contained unit. If I could compile it as Audio Unit and VST, that would be even better. Until that day, I prefer commercial software to make things to share. It's just easier to give away a VST, than try and get pure data installed in many cases. If it was built with PD, then those interested could also see the source patch, but only if they wanted to bother with that.
It personally took me months, and several version changes, until finally Hans released the PD Extended-RC7, to get PD going with a decent amount of externals. Well, at least now I can finally recommend it to my friends, which I could not do when things were always broken...
~David
Derek wrote:
As far as plugins, you could check out PDVST to get PD running as a VST/VSTi under windows:
http://crca.ucsd.edu/~jsarlo/pdvst/
Besides running PD in a VST host, you could also run it alongside whatever other app you are using, and connect them together using OSC for data, MIDI for control and JACK for audio (if you are on Linux or OSX). This should approximate most of what you would gain from having a true plug-in system, except maybe for presets and BPM syncing (both of which could be programmed into your PD patches with some work). It's not Pluggo, but it's not useless either.
good luck, d.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 18: "Balance the consistency principle with the inconsistency principle"
-
cdr -
cyborgk＠nocturnalnoize.com -
derek holzer -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Marc Lavallée -
Mathieu Bouchard -
Steve Peach