Thank you all so much!
Building the filename and passing it onto an [ open $1 ( message worked perfectly.
One should know better by now, I should've thought of it... oh well. Hindsight is 20/20.
Cheers

On Sun, Feb 21, 2010 at 6:41 PM, Jonathan Wilkes <jancsika@yahoo.com> wrote:


--- On Sun, 2/21/10, Roman Haefeli <reduzierer@yahoo.de> wrote:

> From: Roman Haefeli <reduzierer@yahoo.de>
> Subject: Re: [PD] turn a symbol to a message
> To: "Ignacio Lois" <ignaciolois@gmail.com>
> Cc: pd-list@iem.at
> Date: Sunday, February 21, 2010, 11:03 AM
> On Sat, 2010-02-20 at 20:01 +0100,
> Ignacio Lois wrote:
> > Hello everyone.
> >
> > I've been pulling my hair out for a while with an
> inexplicable
> > problem.
> > I'm trying to build an [open file.wav( message to feed
> a [readsf~]
> > object.
> > A [makefilename] object is returning the exact symbol.
> I'm connecting
> > it to a [$1( message, and then onto the [readsf~]
> object and I get the
> > error: "readsf~_ no method for 'open file.wav'
> > If I replace the $1 message for the hard coded "open
> file.wav", it
> > works perfectly.
> > What am I doing wrong?
>
> And yeah: Pd is missing a way to display the distinction
> between:
>
> "'open file.wav'"       <-
> 'open file.wav' selector
>
> and:
>
> "'open' 'file.wav'"    <- message with 'open'
> selector
>                
>           and 'file.wav' as first
> argument
>
> Both look the same, when printed. This indeed could be
> confusing. How
> about adding a 'debug' [print] option (-d?) to make [print]
> not decode
> incoming message, but make it print all the implicit stuff,
> that is
> usually hidden? Would that make sense?

How would [print] resolve this ambiguity?  Both messages above
are handled by the print_anything method, which prints the selector
+ any atoms that make up the rest of the message.  Plus if there's a way
to clearly distinguish visually between these two messages, I'd rather see
that solution applied to Pd as a whole, so that for instance symbols with
spaces in them may be saved in a patch.

In the meantime, it might be helpful to make an abstraction that breaks up
an incoming message into its constituent parts.  So one's output would look like this:
selector: open file.wav
arguments:

while the the other's would look like this:
selector: open
arguments: file.wav

But I don't think this should be the job of the [print] object.

-Jonathan