Forums > MaxMSP

sfplay~/sfinfo~ + name argument…

October 18, 2008 | 10:00 pm

Hi,
I’m trying to get sfinfo~ to recognize the filename of whatever is currently loaded in an sfplay~. It doesn’t seem to be working. I keep getting "could not find named object [mysfplay~name] in the Max window, and can’t figure out what I’m doing wrong. It DOES work if I use the name msg to sfplay~ and not the argument. Can anyone advise? I’m sure it’s something simple, as I’m a newbie.
Excerpted below:

– Pasted Max Patch, click to expand. –

Thanks,
Brian


October 18, 2008 | 10:21 pm

On 19 oct. 08, at 00:00, Brian Heller wrote:

> Hi,
> I’m trying to get sfinfo~ to recognize the filename of whatever is
> currently loaded in an sfplay~. It doesn’t seem to be working. I
> keep getting "could not find named object [mysfplay~name] in the Max
> window, and can’t figure out what I’m doing wrong. It DOES work if
> I use the name msg to sfplay~ and not the argument. Can anyone
> advise? I’m sure it’s something simple, as I’m a newbie.

You have to send the name message to [sfplay~].

HTH,
ej

– Pasted Max Patch, click to expand. –

October 19, 2008 | 2:25 am


October 21, 2008 | 9:30 pm


October 22, 2008 | 1:43 am

>>>> Yes, sfplay’s name is not an argument.
>> By the way, there is a problem in the design of this "name" feature in
>> [sfplay~]. When you give a name (with a message), it is stored in
>> the object
>> (open such a Max patch later with a text editor to check).
>> But there is then no way to say "no name, please".
>> Result: when you name a sfplay~ to be used in an abstraction or
>> bpatcher, if
>> it’s used several times in the main patch, you get a "name already
>> used"
>> error.
>> Workaround: instantiate a [sfplay~] and never name it before saving
>> your
>> abstraction patch.
>
> Another workaround is to send the name message without argument.
>
Thanks ej, I hadn’t tried that (but you still have to send it each time
before you save).


October 23, 2008 | 7:39 am


October 27, 2008 | 6:59 am

Thanks guys, sorry for not getting back sooner. Good to know about the naming issue. But just to be clear, since I’m learning, my impression from the reference file was that the name *could* be an argument in [sfplay~]. As you say, that’s not the case, so what is this part of the documentation referring to?

"If the last argument is a symbol, it specifies a name by which other objects can refer to the sfplay~ object to access its contents."

Thanks again,
Brian



jml
October 27, 2008 | 8:13 am

Based on the sfplay~ reference (and the helpfile), the sflist-object-name only refers to an sflist-object, *not* an sfinfo~ object. The shared-data functionality for sfinfo~/etc. only works with the name given.

Hope that this helps,
jml


October 27, 2008 | 6:34 pm

Duh! Sorry, my fault…reading too late at night I guess!

Thanks,
Brian


Viewing 9 posts - 1 through 9 (of 9 total)