what do you gain from turning abstractions into subpatches??
You gain the advantage of being able to distribute a Pd patch built from many disparate abstractions as a single file.
padawan12@obiwannabe.co.uk wrote:
what do you gain from turning abstractions into subpatches??
You gain the advantage of being able to distribute a Pd patch built from many disparate abstractions as a single file.
this advantage you gain from being able to embed abstractions in abstractions, while at the same time you still have the features of abstractions (namely: abstraction)
apart from that, tar allows you to distribute your multi-file Pd patch as a single file too.
mfga.sdr IOhannes
Yes, that's true, the real problem is something else: There is no easy way to get a list of external/abstraction dependencies for any given patch. If you could get such a list, complete with file locations, it would be easier to collect all your patches for an archive file.
~David
On 5/15/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
padawan12@obiwannabe.co.uk wrote:
what do you gain from turning abstractions into subpatches??
You gain the advantage of being able to distribute a Pd patch built from many disparate abstractions as a single file.
this advantage you gain from being able to embed abstractions in abstractions, while at the same time you still have the features of abstractions (namely: abstraction)
apart from that, tar allows you to distribute your multi-file Pd patch as a single file too.
mfga.sdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 15/05/2007, at 18.30, IOhannes m zmoelnig wrote:
apart from that, tar allows you to distribute your multi-file Pd patch as a single file too.
I second that.
A more robust way of loading "stuff" (from fx. an untar'd tar ball)
would make a better solution. I.e. something that works in different
distributions (extended, vanilla, etc), is independent from the
preference and is not a shell script with a bunch of start up
options. This rant/request might be utter rubbish though - please let
me know.
Hallo!
A more robust way of loading "stuff" (from fx. an untar'd tar ball)
would make a better solution. I.e. something that works in different
distributions (extended, vanilla, etc), is independent from the
preference and is not a shell script with a bunch of start up
options. This rant/request might be utter rubbish though - please let
me know.
That's what declare, import and etc. is for ...
LG Georg
True, it would be great if these features were somehow automated. Like a dynamic object creation scheme where the external libraries and abstractions are created as arguments as they are imported.
Probably too much wishing on my end for that though!
~Kyle
On 5/15/07, Georg Holzmann grhPD@gmx.at wrote:
Hallo!
A more robust way of loading "stuff" (from fx. an untar'd tar ball) would make a better solution. I.e. something that works in different distributions (extended, vanilla, etc), is independent from the preference and is not a shell script with a bunch of start up options. This rant/request might be utter rubbish though - please let me know.
That's what declare, import and etc. is for ...
LG Georg
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
David Powers -
Georg Holzmann -
IOhannes m zmoelnig -
Kyle Klipowicz -
padawan12＠obiwannabe.co.uk -
Steffen