*cough*
There are of course of general use just to help me with making the pixelTANGO abstractions easier and less redundant. So far I have:
stripExtension which allows you to remove the .pd part of a filename so you can call it as an abstraction in the patch.
stripPath removes the path component of a filename leaving just the "tail" this is useful for #1, making popup's full of files show only the tail and not the WHOLE path to the file. This system will need a little help to make it work better. This is also useful to generate a pd-abstraction.pd name from a set of listed files.
dirlist just globs the files in a certain folder.
There will probably be more things like this as things move along.
So there are two parts to these things, the script (currently called "pt.py" which contains the python code for all of them.) and abstraction wrappers that look like:
[inlet] | [py pt (function)] | [outlet]
Where (function) is the name of the abstraction as well as the method in the pt.py file. dirlist, stripExtension, stripPath.
These patches are so simple that they could be generated from the pt.py script.
The only reason I did not use pyext is that there seems to be more code for the same thing and the same complex treatment of atom types and such. This method looks to be much faster.
My main reason for asking the question was that we have both the abstractions (that should reasonably go into abstractions) and then the script part, that should go in scripts/ or along side the abstractions in abstractions? (since the script needs to be in the pd path anyhow).
I think it makes more sense to put it all in the abstractions section, but perhaps the script to generate the patches should be in scripts... Arg!
Advice?
b>
Hans-Christoph Steiner wrote:
The python scripts could fit there but I am not really sure what they do. If they are meant for general use, then they would fit there. If they are specifically for pixelTANGO, I'd say keep them with pixelTANGO.
The scripts that I made me think of adding this section are a pd diff script, a SysV init script (/etc/init.d/pd), and now the MacOS X plist swapper script.
pdsend/pdreceive scripts seem to fit well there also.
.hc
On Mar 26, 2005, at 6:42 PM, B. Bogart wrote:
Hmmm,
Would/Could python scripts aimed at PD tasks fit in here?
I'm not sure if I should wrap my python scripts into abstractions or not... abstractions would be easier to use, [dirlist] rather than [py pt dirlist] and the whole special message to py in the first inlet.
I suppose scripts that deal with the pdsend receive format could fit in there...
B.
Hans-Christoph Steiner wrote:
I got no responses to this, but I thought I'd try again since IOhannes was talking about cleaning up the CVS.
Any objections?
.hc
Begin forwarded message:
*From: *Hans-Christoph Steiner <hans@eds.org> *Date: *March 10, 2005 4:35:06 PM EST *To: *pd-dev <pd-dev@iem.at> *Subject: [PD-dev] "scripts" section of CVS X-Mailer: *Apple Mail (2.619.2) I am thinking of starting a "scripts" section of the CVS because I have written two handy scripts for Pd and there doesn't seem tobe a logical place to put them in CVS. I have a /etc/init.d/pd SysV-style start/stop script and pd-diff, a rough idea of how to get useful results from diffing .pd files.
Any objections, ideas, comments? .hc
Man has survived hitherto because he was too ignorant to knowhow to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
There is no way to peace, peace is the way. -A.J. Muste
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra