hi all,
in the ideal world there is only a patch file.
In most real cases patches depend on various resources -- sound files, midi files, abstractions, externals, and what not. This is a tough thing to deal with, if pd projects are to be moved between systems, merged one with another, or simply survive installation changes.
I wonder how people handle these things. Is there a common practice, or any home-brew tricks which help in interchanging (or merging, or switching between, etc.) projects more reliably than by hand?
This is quite a general problem. One special case is, of course, resolving object creation names (i.e. dealing with external name clashes, among other things).
Krzysztof
(The resources 'widget' depends on are ``widget definition files''. Currently, widget uses both the installation-wide default.wid file, and per-widget-type definition files. Now I am looking for a way of associating these with particular patches.)
here is my reply Krysztof, with headers, your isp rejected it.
The original message was received at Tue, 29 Apr 2003 21:15:51 +1000 from [host omitted] [x,x,x,x]
----- The following addresses had permanent fatal errors ----- czaja@chopin.edu.pl (reason: 550 5.0.0 Sorry, we do not accept networks that relay spam.)
----- Transcript of session follows ----- ... while talking to suita.chopin.edu.pl.:
MAIL From:des1gner@optusnet.com.au
<<< 550 5.0.0 Sorry, we do not accept networks that relay spam. 554 5.0.0 Service unavailable
Reporting-MTA: dns; mail012.syd.optusnet.com.au Received-From-MTA: DNS; c17673.sunsh2.vic.optusnet.com.au Arrival-Date: Tue, 29 Apr 2003 21:15:51 +1000
Final-Recipient: RFC822; czaja@chopin.edu.pl Action: failed Status: 5.0.0 Diagnostic-Code: SMTP; 550 5.0.0 Sorry, we do not accept networks that relay spam. Last-Attempt-Date: Tue, 29 Apr 2003 21:15:54 +1000
Return-Path: des1gner@optusnet.com.au Received: from [host omitted] [x,x,x,x]) by mail012.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id h3TBFpo22454 for czaja@chopin.edu.pl; Tue, 29 Apr 2003 21:15:51 +1000 Mime-Version: 1.0 Message-Id: <p0501040bbad40f17b6ad@[x.x.x.x]> In-Reply-To: 3EAE53EC.60603@chopin.edu.pl References: 3EAE53EC.60603@chopin.edu.pl Date: Tue, 29 Apr 2003 21:15:49 +1000 To: Krzysztof Czaja czaja@chopin.edu.pl From: des1gner@optusnet.com.au Subject: Re: [PD-dev] dealing with patch dependencies (being stuck at widget's redesign) Content-Type: text/plain; charset="us-ascii" ; format="flowed"
in the max-msp-nato world it is quite common for dependencies which are patchers and objects and files to be included in the directory which contains the patch...is this a reasonable solution for pd also?
At 12:29 +0200 4/29/03, Krzysztof Czaja wrote:
hi all,
in the ideal world there is only a patch file.
In most real cases patches depend on various resources -- sound files, midi files, abstractions, externals, and what not. This is a tough thing to deal with, if pd projects are to be moved between systems, merged one with another, or simply survive installation changes.
I wonder how people handle these things. Is there a common practice, or any home-brew tricks which help in interchanging (or merging, or switching between, etc.) projects more reliably than by hand?
This is quite a general problem. One special case is, of course, resolving object creation names (i.e. dealing with external name clashes, among other things).
Krzysztof
(The resources 'widget' depends on are ``widget definition files''. Currently, widget uses both the installation-wide default.wid file, and per-widget-type definition files. Now I am looking for a way of associating these with particular patches.)
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
hi des1gner,
yeah, that would be the best way. It works in Pd, as long as the stuff used in a single Pd session does not come from more than one directory. I mean, for example, an external, once loaded, is registered for good, and used in any patch, which happens to be loaded later -- regardless of its home directory.
Same goes for widget type in my case, this is the point I am stuck in...
However you are right. Resolution should be directory-based, this is the most natural way,
thanks, Krzysztof
and sorry for my isp (having all sorts of trouble with chopin.edu.pl, most of the time)
des1gner@optusnet.com.au wrote: ...
in the max-msp-nato world it is quite common for dependencies which are patchers and objects and files to be included in the directory which contains the patch...is this a reasonable solution for pd also?
I have been using the CVS compiles on Windows, Linux and MacOS X and that has helped a lot in terms of having all of the same objects on all platforms. (It would be great if cyclone was in there too.)
And now that CVS externals are starting to get made into OS packages, it will be much easier to keep up to date. (Debian .debs and MacOS X .pkgs, currently, I plan on trying my hand at a Windows installer this summer, and Nando from CCRMA has RPMs, I think).
.hc
On Tue, 29 Apr 2003, Krzysztof Czaja wrote:
hi des1gner,
yeah, that would be the best way. It works in Pd, as long as the stuff used in a single Pd session does not come from more than one directory. I mean, for example, an external, once loaded, is registered for good, and used in any patch, which happens to be loaded later -- regardless of its home directory.
Same goes for widget type in my case, this is the point I am stuck in...
However you are right. Resolution should be directory-based, this is the most natural way,
thanks, Krzysztof
and sorry for my isp (having all sorts of trouble with chopin.edu.pl, most of the time)
des1gner@optusnet.com.au wrote: ...
in the max-msp-nato world it is quite common for dependencies which are patchers and objects and files to be included in the directory which contains the patch...is this a reasonable solution for pd also?
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
zen \ \ \[D[D[D[D
-
des1gner＠optusnet.com.au -
Hans-Christoph Steiner -
Krzysztof Czaja