Brian H.

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.

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:

sfplaysfinfo-name-argument

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

> 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~].

> 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.

>>>> 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

>> (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

>> it's used several times in the main patch, you get a "name already

>> Workaround: instantiate a [sfplay~] and never name it before saving

> 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

>>>> 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).

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 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?

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.

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.

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

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

sfplay~/sfinfo~ + name argument...