[bug?] [sfplay~] @audiofile attribute only works from inspector
This thread (http://www.cycling74.com/forums/index.php?t=msg&th=38985&start=0&rid=4220&S=fdbf4994e6467e025c1cf8e661816cc5)just had me investigate setting attributes from the inspector and I noticed that [sfplay~] got an attribute in Max5 for the initial audiofile.
When I try setting this attribute from typing [sfplay~ @audiofile myfile.aif] into an object box, I get the error "no open file" in the Max window. I’m not sure if this is a bug because until know I didn’t know this was even an option for [sfplay~].
I’m using Max 5.0.6 on OS X 10.5.6.
It seems to me it is not the first time I see an attribute that is not supported by the "@" technique. Does "@" works for every attribute normally? If not, does anyone know how to find out which ones are (not) supported.
of course the workaround is to use [loadmess audiofile myfile.aif] but that looks less elegant.
Another solution is to simply choose the file within the inspector and then "freeze" the attribute. This will cause the object to remember it and load up with the file. You can then change the file with the regular "open $1" or even "audiofile $1" messages after your patch is opened and the next time you open your patch it will only remember the file which was initially frozen into the attribute.
|Ch wrote on Thu, 09 April 2009 03:32|
|It seems to me it is not the first time I see an attribute that is not supported by the "@" technique. Does "@" works for every attribute normally? If not, does anyone know how to find out which ones are (not) supported.|
Do you remember which other attributes you encounter this with? I suppose in some ways it is a little misleading everything in the inspector has an "@" next to it even though they can’t all be used in the objectbox as an attribute. The case of "@audiofile" it is a whitebackground attribute in the inspector and is listed as an attribute in the reference so I would assume it would be designed to type in an objectbox.
The freeze attribute option is probably the best way to use this at the moment, but any time that I can think of that I would use this attribute would be in teaching examples, and I’d rather have the loaded soundfile obvious from using the patch (and will probably stick to [loadmess open myfile.aif] unless this functionality changes).