-history: no such object
-history: no such object

I know you can't get $0 in a message box.

Looked through the subpatch/abstraction/locality help patches, no relevant example. It's kinda an important topic, but... where should I look it up?

So what am I doing wrong?

hjh

@ddw_music $0 is not a symbol. It is internally rendered to a number. [print] should show what is going on...

You can also give preset values to many objects, i.e. [pack 10 $0].

@ddw_music being able to preset values into [pack] as @ingox mentioned is very handy but it can cause some headaches as well as reveal one of [pack]'s less used/known features, it can split lists. If you want that preset value to be a constant you should always precede the left inlet with something which will keep out accidental lists, a list sent there will either populate the [pack]'s other arguments or throw type errors. Only the left inlet will accept lists, the others complain as [float] and [symbol] do when fed a list.

Also, when naming things with $0, it seems best to always do name-$0 instead of $0-name as most every example does, name-$0 can be called directly from [expr}, $0=name can not. I assume the $0-name convention predates [expr].

@oid Haha, yes, the distribution of lists among inlets is a ridiculous feature...

@ingox

$0 is not a symbol. It is internally rendered to a number.

OK, got it.

Is this documented anywhere?

You can also give preset values to many objects, i.e. [pack 10 $0].

Ah, that's very nice. It hasn't entered my vocabulary yet. Maybe it will sink in now.

oid:

If you want that preset value to be a constant you should always precede the left inlet with something which will keep out accidental lists...

In fact, I have two of them: [unpack 0] [f], and a f outlet of a trigger.

Also, when naming things with $0, it seems best to always do name-$0 instead of $0-name as most every example does,

Understood, but... again, is this documented anywhere? "13.locality.pd" demonstrates $0 as a prefix -- if this is out of date, shouldn't somebody put in a pull request to update the help file?

Anyway, with that, I was able to wrap up this moving-average abstraction:

moving-avg.pd

hjh

@ddw_music said:

In fact, I have two of them: [unpack 0] [f], and a f outlet of a trigger.

You do, it was more for general info, this is the sort of error that can be very difficult to hunt down when you are unaware of this behavior.

Understood, but... again, is this documented anywhere? "13.locality.pd" demonstrates $0 as a prefix -- if this is out of date, shouldn't somebody put in a pull request to update the help file?

I do not think it is really out of date, this is more coding style than anything, you set yourself up for easy use of {expr] and arrays/values if you get in the habbit of name-$0. The only place I know of that mentions name-$0 is the [expr] help file in the 'Dealing with $0' subpatch, I can not think of a situation where $0-name has the advantage.

@oid There was a time when $0 could only be used at the beginning of a symbol......
https://puredata.info/docs/tutorials/TipsAndTricks
That changed a long time ago.
@ddw_music It is easiest just to use $0 as an object argument as in [pack f $0] rather than sending $0 into the object.
As far as I know that is valid for all objects..... so true for abstractions as well.
Except [symbol] as it expects a symbol argument. Pretty sure you found the only exception...!
Of course $0 has no meaning (it returns a value of zero) in a message and so has to be translated to another $ index in a message as you did in your op.
David.

P.S The change occurred prior to Pd-extended (2011).
From the help patch [dynamic_sends] in extended........ dynamic_sends.pd

"In the old days, $0 was only expanded if it started the name, so it was necessary to use [makesymbol] in order to put the value of $0 into the middle of the name (as in the patch below). Additionally, the entire patch had to be drawn by hand on a punchcard (taking care to avoid punching any holes whatsoever) and then given directly to Miller, who would file it away in a drawer for safekeeping through the harsh Winter months."

So things have improved over the years.