Not sure if this is an intentional restriction, but the name attribute to fluid.dataset~ doesn’t allow you to change it. This happens either with the attrui or with name $1.
The use case here is instantiating a random/unique fluid.dataset~ inside an abstraction, (as detailed in this thread).
I can give it a name on instantiation (e.g. fluid.dataset~ #0), but I want to give it a nicer random name, or may want to programmatically name several ones.
Alternately I can just fluid.dataset~ generate its own random name (as it does if you instantiate one without a declared name), there’s then no way of querying what that random name is…
That doesn’t work if that other dataset doesn’t already exist. But I can’t give the other dataset a name for the same reason. So if I want to create a new dataset but don’t have a name for it, its the same problem.
Handy!
That doesn’t show up in the “right-click input” thing, the helpfile, or the reference page though.
Well, I will manually create the dataset by creating an object called fluid.dataset~. I want to dynamically name it. So like, a patch may have a few of these “unnamed” fluid.dataset~s which I’ll (programmatically) name unique identifiers + strings.
Nice. Is that like common knowledge? Never in a million years would I have started typing arbitrary requests to an object that doesn’t say what it’s list of messages are.
Ok. Not possible, I’m afraid, but what’s wrong with the unique names that come with putting no name in?
It’s certainly true for all the jitter objects, not sure what of the newer Max object use dump outlets. Will make sure we add to docs somewhere, because evidently not common enough knowledge. It applies to any attribute on one of our objects that has a dump outlet at the right
Yes, to be fair to @rodrigo.constanzo I had the same epiphany at the hands of @weefuzzy at some point. It’s a convention that is quite useful, at least, you really are pleased when you know you need it and you are granted the wisdom to getstuff.