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

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

I remember that when I made a pr for a "set" method for binops it was (rightly) pointed out to me that there isn't much advantage of using a [set( message instead of [f ].. message boxes are "objects" after all, plus [f ] only uses 1 float of comparative memory.

so maybe there shouldn't be a pr after all

@ingox said:

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

Speaking only for myself, there's a gap between the principle and understanding the application of the principle. Or, you have to get some distance into patching before you really grasp why [f] is important. Just like there are points of confusion in learning SuperCollider that I forgot about long ago.

I do agree there's no need for a PR, but I think the help should illustrate. I could PR something later.

hjh