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!
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
