[PD-dev] new pd-devel feature: patches for file associations

[Hans-Christoph Steiner]

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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev



----------------------------------------------------------------------------

                   ¡El pueblo unido jamás será vencido!