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?
Thanks in advance...
Then the patch. Perhaps a space is being added somewhere with the
[makefilename].
.hcD
On Feb 20, 2010, at 2:01 PM, 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?Thanks in advance... _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
Hello Ignacio, see attached example, hope it helps... gr, Tim
2010/2/20 Ignacio Lois ignaciolois@gmail.com
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?
Thanks in advance...
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Somehow you managed to create a symbol "open file.wav" (with a space in between). Usually a space character is used as a delimiter for separating the elements of a Pd message. However, when the space character is part of the symbol itself, which is only possible to do by using [makefilename], it cannot serve as a delimiter between the 'open' part and the 'file.wav' part anymore. What [readsf~] expects is a message with the 'open' method with the first argument being the filename, for instance 'file.wav'. A message box with the following content could work:
[open file.wav(
But you also could compose such a message without using [makefilename]:
[symbol file.wav( | [open $1(
or:
[symbolbox
|
[open $1(
Traditionally, [makefilename] was used to compose the filename part (not the whole message), for example when you used some kind of a template for filenames, for instance fileX.wav, where X would have been a number.
[numberbox\ <- 40 | [makefilename file%d.wav] | [open $1(
-> open file40.wav
However, with modern versions of Pd, variable substitution within symbol elements works as well, which is even simpler:
[numberbox
|
[open file$1.wav(
Another case, which you still need [makefilename] for, is when you would like the number part of the composed message to be fixed-length:
[numberbox\ <- 91 | [makefilename file%04d.wav] | [open $1(
-> open file0090.wav
Hope that helps Roman
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?
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?
Roman
--- 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
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 firstargument
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
-
Hans-Christoph Steiner -
Ignacio Lois -
Jonathan Wilkes -
Roman Haefeli -
tim vets