Why does [pack] not implement a "set" method?

There are cases where you need to update the data stored within a [pack] but output the message only on demand.

A workaround would be [pack...] --> [list store] --> [list trim] but that's annoying.

hjh

@ddw_music Just do [pack 0 f f f...] and use the hot inlet to bang. follow with a list split if you can not have the leading zero or what ever you put there, good spot for your $0 if you need it. I assume it is not implemented because it is just so simple and more versatile to roll your own.

@ddw_music I usually just do a [f ] beforehand.. I ran into this issue not 2 minutes ago myself.

Perhaps a pull request is in order..

Aha, it's so obvious that... I didn't think of it.

OK, I can accept why it isn't implemented... I have a harder time accepting why it isn't documented...

Edit: Actually seb's is more efficient.

hjh

@ddw_music It is probably not documented because it is the same as all other storage devices, pack is just [float] or [symbol] for lists, hot inlet can always be banged for output. I think This is explained in the documentation, just not in the online help. Seb's is more efficient except when you need a constant like $0 and can just have it live in the first spot.

@ddw_music Or store the list from [pack] in a list object and bang it later.

@ingox

You mean like where I said "A workaround would be [pack...] --> [list store] --> [list trim]"

@oid

"It is probably not documented because it is the same as all other storage devices"

OK.

Well, you're correct about one thing -- in fact, I do know how [f] and [list] work, but for some reason, in this case, I hadn't extended the same logic to [pack]. And yeah, that's my own lack of insight.

On the other hand... "set x" messages are used elsewhere to make a hot inlet behave as if it were cold. So it's not unreasonable for a user to infer that [pack] might do something similar (especially since IIRC Max's [pack] object does use "set x" messages this way). Consequently, it's not unreasonable for a user to hope that [pack] documentation will would advise the user against that inference, and suggest a correct alternative.

E.g. "Note: Unlike Max's [pack] object, Pure Data's [pack] does not support 'set' messages in any inlet. See this subpatch for techniques to withhold [pack]'s output."

hjh

@ddw_music The online help is just a quick reference, it is not the manual, it has room for improvement but it will never be a manual. I think it is unreasonable to expect the PD help to endlessly explain how it is different from Max, it would be very tiring and detrimental for those who have not used Max and would ultimately read like a commercial for Max, look at all the features you are missing by using PD instead of Max! You could fork the github and start updating the help, once setup it would take no more time or effort than these posts where you point out the flaws of the help and I would bet they would take almost every update to the help files, push your updates and make the pull request. Not that I am complaining about your complaining, I am certainly not doing the work either, and that is part of the problem with opensource, no one wants to do the grunt work even when it is stupid simple.

@ddw_music

@ddw_music In addition to what @oid said, the mailing list is probably another good place to discuss ideas about the improvement and development of Pd: https://lists.puredata.info/listinfo/pd-list.

This forum is in my perception mostly frequented by users, not so much by developers.

especially since IIRC Max's [pack] object does use "set x" messages this way

That's a good reason to look into adding a "set" method to Pd's [pack].

looks at code for Pd's [pack]

Oh, wow-- I didn't realize that it already has an "anything" method. This means that arbitrary methods will get converted to a list which then gets resent to the object as a list.

So if you have [hello 1 2 3(---[pack s f f f], the anything method handler converts the "hello" method to "list hello 1 2 3" and resends it so that the list gets distributed among the inlets.

Lots of great details here:

• inconsistency with [select] and many other core objects which don't autoconvert like this
• requires allocating and freeing heap memory on every call to the anything method
• makes it impossible to ever implement the set method without breaking backward compatibility

Anyhow, if you'll tell me your desired line to add to the Purr Data docs about the lack of "set", I'll add it.

While I could also add a check and a warning for "set" messages being sent to [pack], that risks being noisy to users who-- possibly through the use of a nested abstraction library they didn't create-- are relying on the current behavior.

Hehe-- I guess technically [pack] converts arbitrary methods into "[null] 1 2 3" internally. But immediately calls its own list handler, so I guess it's moot (unless or until someone unwittingly tries to do something with the selector in the implementation and forgets to check for NULL).

@jancsika [list] also converts:

@ingox That's just playing musical chairs for Pd's unnecessary inconsistencies. For example, [pipe] has essentially the same interface as [pack] with a trailing float argument to set the delay. But [pipe] does not convert arbitrary messages to lists.

@jancsika Yes, sure thing. I would never dispute Pd being inconsistent in many places.

@ingox It makes me think of the various ways flags are used for commands on the command line in Gnu/Linux. It would be neat if someone did research to actually measure how much time is wasted with figuring which commands have flags that can be combined, which commands use subcommands instead of flags, which mix the two, which use double flags for full words, which don't, etc.

E.g., "git checkout -b". That bothers me so much.

@jancsika Haha, true.

@jancsika said:

That's a good reason to look into adding a "set" method to Pd's [pack].

What is your reasoning? The closer PD's user experience gets to Max the more people will expect it to be Max and complain about it not being Max.

inconsistency with [select] and many other core objects which don't autoconvert like this

This seems consistent from the user standpoint. If an object needs more than one value it will expand the list to get those. [select] can require more than one value if they had no arguments at creation but it would be almost pointless to expand the stream that way. [pipe] is an exception but it makes some sense, would it expand to outputs or to delay time or to both? Which ever you picked there would be people complaining that it should be the other and the help file shows us how to to work around the lack of expansion with [trigger]

EDIT; You are referring to [select] needing symbols to explicitly be stated with [symbol( or [symbol], not your explicit example using a list. Yes, this is irksome. Number like symbols are just as bad and [f] can not always convert them, like when that number like symbol comes out of [route].

The closer PD's user experience gets to Max the more people will expect it to be Max and complain about it not being Max.

That doesn't tend to happen. E.g., [expr] has been a core Pd Vanilla object for some time. It interprets its args as Max-style ints/floats, but (quite rightly) nobody requests adding the int/float difference to the core.

Also, Pd-l2ork and Purr Data have opportunistically pulled improvements from Max when backward compatible. I don't think I've had any complaints about it being insufficiently Max-like.

I did have a user request the strange Max feature of hiding all wires and xlets. But they didn't even complain when I implemented it as GUI preset named "footgun."

@oid said:

@ddw_music I think it is unreasonable to expect the PD help to endlessly explain how it is different from Max...

Difference from Max isn't fully the point... What I'm really driving at, perhaps clumsily, is that "use an [f], [list] or [symbol] box to cold-ify [pack]'s (well, any object's) hot inlet" is a pattern of usage that transcends object-by-object documentation. Users aren't going to get very far with Pd unless they learn a few of these key patterns and apply them generally. How do they learn them, if the help doesn't demonstrate them?

Applying them generally is another matter -- I'm asking myself the question, how is it that I taught, a month ago, how to use [f] to make a math operator cold, but I didn't think to do the same with [pack]? That's of course largely on me -- but also, if the help repeats patterns in more than one context, then the patterns enter the culture in a way that they don't if they're considered ad hoc workarounds for isolated problems. That's ultimately what I would like to see -- a handful of these object constellations becoming part of Pd lingua franca.

Fair enough to ask me to "do-ocracy" these points in the help.

@jancsika good catch on the impossibility of implementing "set." So it is a documentation matter, then.

hjh

@ddw_music [float] and [symbol] only exist to store a value via cold inlet and output the value later via hot inlet. This is also documented in the help files. [list] is a more complex object and the documentation for this is in the [pd append] subpatch.

In the online documentation the concept is described in chapter 2.3.3. among the very first basic principles.

It is surprising to me how this would not be one of the first things to learn in Pd.

It is true, however, that list usage is not described in the control examples in the help browser. It would be great to have an explanation there.