Apologies if this is a duplicate question -- keywords like "value" and "object" do not exactly search well...

Why does [value] only store a single float? (I mean... Ok, in the source code, the object's struct only allows for a single float... but one wonders why it was deemed not useful to store arbitrary messages.)

You could press [text] into service as an arbitrary storage location, but if you try to wrap this up as an abstraction, then you'll run into problems with multiple [text define] instances for the same name. That's a nasty, difficult problem that I've run into before... why isn't there a [text define -once] flag? It seems to me that there are cases that are impossible to handle without it -- and "impossible" is something that programming environments should take pains to avoid, except for undecidable problems... but storage and retrieval don't fall into that category.

So how to do an arbitrary-message [value]?

hjh

@ddw_music Here is an abstraction for a general purpose variable that can hold floats, symbols or lists:

var.zip

Supports state saving.

Code:

@ingox

That is... baroque

OK, I see what you have to do... each [var] instance gets its own local [text], and the [s] [r] pairs are keyed off of the name rather than the instance number.

There's one thing [value] can do, which I'm not sure this approach can handle. If [value] doesn't specify a name as an argument, then it has a right inlet to accept name changes by receiving a symbol. To do that here, it would be necessary to change the name of an [r] object. This is not documented in [receive] help -- which doesn't mean it's impossible, just that it's obscure.

I still feel pretty strongly that [array] and [text] would benefit from a global flag. I guess I'll log an issue about that.

hjh

@ddw_music You can instead use a global send, prepend the keyword and route for it to filter.

You can also check for creation argument and delete the second inlet via dynamic patching if desired.

An alternative that is most of the time sufficient is to just use send and receive and store the data in the cold inlet of [f], [symbol] or [list]. Works almost like [v]

So I did log the feature request -- it turns out there's some interest in a way to create shared instances of an abstraction, related to a singleton. That would take care of it: a hypothetical [val] abstraction could use a (now hypothetical) [singleton valStorage] where the valStorage abstraction defines the text object. Multiple instances of the singleton would refer to the same memory object. That could be useful for more purposes other than just text or array.

[send] / [receive] for fundamental flow of control... I guess I have some trust issues about sending to multiple receive-s but I guess in this case it's a reasonable workaround for limitations on object management.

hjh