Hey Frank,
So right now, this isn't for d-n-d, but for opening files from the Open panel. It may or may not make sense to use this for d-n-d, but this is just a place to start testing the ideas. The $FILENAME syntax is odd, that is true. The patch is rewritten using a regsub, so $FILENAME is replaced with the path of the file opened. Perhaps there is a better symbol to rewrite, I chose that because its not part of Pd syntax, so it wouldn't restrict possibilities of that patch (i.e. its not $1). Maybe just the word 'FILENAME' would be better. It would be much nicer to do it in a way that is pure Pd syntax, but I haven't thought of a good way to do it.
About the filename convention (wav.pd, ogg.pd, etc.), that is used to register an association with the GUI's $filetypes, it has nothing to do with how the patch works, so it doesn't violate the 'printability' rule.
I think the easiest way to discuss this is use cases, I've mostly been thinking about opening files via File->Open so far, with Drag-N-Drop in the background. At first, I thought that these two cases would be very similar, but your email makes me think maybe not. I now see three use cases:
1) File->Open of .wavs, .ogg, etc. for creating a starting point for a patch based on that file 2) dropping a .wav, .ogg, etc. file into an existing patch and have it paste in the Pd code for playing that file 3) generating a programmatic response to to a Drag-N-Drop event
I have been thinking of this purely from the perspective of the 'pd- gui' editor, not 'pd'. Indeed the association feature I implemented is only in 'pd-gui', it would not work in 'pd -nogui' mode. I think it makes sense to think about it more broadly, but I am afraid of being distracted by making the problem too large.
I hadn't thought of #3 before, which I think you are outlining here. Upon thinking about it, I think it wouldn't be too hard to implement in Tcl. The drag-n-drop event would just send a pd message to 'pd', something like [;dragndrop pd-dndreceiver.pd filename.ogg 51 413( But it probably makes more sense if that message was sent to the patch, like [;pd-dndreceiver.pd dragndrop filename.ogg 51 413(. That would be implemented on the C side, and would work in 'pd -nogui' mode.
Or perhaps there could be a 'pastefile' method in 'pd' which would copy the contents of a file, then paste it into a given canvas at a given location, like [; pd-dndreceiver.pd pastefile filename.pd 50 50(. 'pastefile' would then, copy the contents of filename.pd, then paste it into dndreceiver.pd at 50,50. This could be used for #1 and #2.
The final question for me here is how much of this functionality to include in 'pd' or whether to keep it in 'pd-gui' only. Anything that is useful to use programmatically should be available in 'pd -nogui', but things that are just for the editor should not. I guess it depends on how Pd's model/view/controller is defined, to put it into those terms. For example, there is no method in 'pd' for creating a new patch, File->New invokes the Tcl proc menu_new. File->Save is in 'pd'.
.hc
On Aug 19, 2009, at 2:14 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
So I fixed a couple bugs in Pd-devel and added a new feature which I'd like feedback on:
Here's some quick feedback, it's all IMO, of course.
I created a system for associating pd patches to file extensions and created an example wav.pd for opening .WAVs. Basically, create a patch using the text "$FILENAME" for the filename should go, name it after the file extension (i.e. wav.pd), then drop it into 'pd/associations'. On start-up, Pd will set up the associations for that filetype. When you then open a .wav in Pd, it will open wav.pd, replace $FILENAME with the complete path, then create the patch by sending the contents of wav.pd to pd.
I think, that the $FILENAME syntax is a bit strange in adding another meaning to dollar signs in messages. Having a message without any incoming connection do something is pretty mysterious. I'd very much prefer a receiver message coming in through [r pd] and tagged accordingly like:
[r pd] | [route dnd] | [route wav] | [s $0-dropped-wavefile]
Alternatively and IMO even better would be to use an object like:
[draganddrop wav] | [s $0-dropped-wavefile]
The next step would be to use this for drag-n-drop functionality, so when you drop an associated file on a canvas (i.e. voice.wav), it would copy-n-paste the contents of wav.pd to that canvas, with the $FILENAME replacement.
Thoughts, objections, comments, improvements?
In general the global registering of filetypes in my view is too restrictive. I'm pretty sure, that if I'd want to use d'n'd, I'd want it to do different things depending on which canvas I drop it in. A sample might be played, when dropped on a sample player, and it might be loaded into a table when used in a sample bank. The only useful way to make "wav.pd" work for everything with your system then would be:
[symbol $FILENAME( | [s DROPPED_FILE]
and then we could just directly use a receiver like above.
Third: I'd don't like, that some information about what the associations patch does is encoded in the filename rsp. object name "wav.pd", which is a bit against Pd's loose convention of having patches retain crucial information when printed. [route wav] would better fit this philosophy.
However patchers should also remember, that some systems (the command line, RjDj, ...) don't support drag and drop at all.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!