Here we will discuss why $ act differently in object boxes and message boxes.

firstly, some basic things:

dollar signs generally stand for a SUBSTITUTION. It is generally accepted that where there is a dollar sign, that dollar sign will be substituted for another value. That much is true for both objects and message boxes.

The 'special case' is $0. This is a unique identifier that is randomly assigned to your patch. It is a number, usually around 1001~. The purpose of $0 is to give each patch its own identifier; so that, for example, you can open 2 versions of the same patch, and have them both operate separately to each other.

There is another tutorial/explanation i wrote called "what is an abstraction, and why use $0, $1, etc ??", Please go through that FIRST, as it forms a basis for what we will discuss next.

http://puredata.hurleur.com/sujet-5853-abstraction-why-use-etc

Ok, so now lets get into the nitty gritty of how these $ substitutions differ between objects and messages.

from 2.Control.Examples/14.dollarsigns.pd:

"Object and message boxes are both actually messages, but in the case of the Object box the message is passed at creation time, and for the Message box, at message time."

If you think through that statement carefully enough, it contains nearly everything we need to know here.

Let's break it down:

"in the case of the Object box the message is passed at creation time"

So, if we want to use $ inside objects in an abstraction, then we need to use creation arguments. The exception is $0, which will always be automatically assigned to any abstraction that is used as an object.

for example, if we have an abstraction called "myAbstraction.pd", and if we use it in a patch as [myAbstraction tango bravo 303],
then any Object Boxes inside that abstraction will substitute $1 with the symbol "tango". Likewise $2 will be substituted with the symbol "bravo" and $3 will be substituted with the float 303.
As mentioned before, $0 will be automatically assigned.

Ok, now let's look at the second part of that statement, dealing with $ in message boxes:

"…and for the Message box, (the message is passed) at message time."

This is the vital difference to Object Box use of $. The only way to get values in to a message box is to explicitly pass a message. If we just pass one message into a message box, then we only need to use $1. If we want to pass a list of messages, then we use $1,$2,$3….for as many items that we have in our list.

example:

[99 balloons(
|
[$1 red $2(
|
[print songtitle]

As should be quite obvious, the $1 is substituted with the float 99, and the $2 is substituted with the symbol "balloons", so our song title is printed as "99 red balloons". (as a side note: if you want to mix floats and symbols like this, then you should always put a float first, otherwise pd gets angry)

please note 2 more important things here:

The creation arguments of our parent patch have NO effect on what happens inside message boxes. Only the message passed into the message box will affect it.

$0 has basically NO meaning in message boxes. $0 would be the "zero-th" item in our list - an pd just always substitutes that for 0. Ideally, i think it would be better if an error were printed to the console instead of this behavior. For all intents and purposes though, there would never be a case when you would want to use $0 inside a message box.

(There are, however, many cases where you would like the use the patch's $0 value inside a message box ... in which case, the $0 value of the parent is passed into the message box as $1 or $2...etc... Please see the example patch for a demonstration of this)

OK, that is pretty much all there is to know. It seems quite simple, and if you follow these basic rules, it really IS simple. The reason why it can appear complicated, is that there are a few occasions when you need to mix up objects and messages, and it's too easy to lose track of which $ do what.

Have a look at the annotated example patch (and abstraction) to see objects and message boxes in action.

http://www.pdpatchrepo.info/hurleur/playerMain.pd

Hey joncrg, when you try to grab the arguments using [$1 $2], you're getting into some shady territory. If you use a symbol as the first argument, Pd will actually try to interpret that as an object name. So if you were to do [abstraction + 1], the object would be [+ 1]. It doesn't become two separate arguments; it becomes an entirely new object. So, don't do it! Unless, of course, that's what you're trying to do.

There are a few ways of doing what you want. First, you could just separate them into different object with the type defined. [symbol $1] and [f $2] will ensure that the first argument is a symbol, and the second argument won't report an error if it is a float. If you want to keep the types arbitrary, I personally like to do this:

In that case, it doesn't matter what the types are. They will just be put together as a list, and you can split it or force types as needed using [symbol], [f ], [t ], etc. But, I should point out, MAKE SURE YOU INCLUDE THE "APPEND" ("prepend" works fine, too). That's bitten me in the ass a few times. Just doing ends up with a similar problem to what you're having: the $1 gets translated as the first argument to . without arguments defaults to , but adding the $1 means it doesn't default.

ok, once again, question: say you have an abstraction with a message inside, the message contains 2 variables, one of them would be the creation argument, lets say it's a number, 1, the other one would be a number received from another abstraction... so, how does the following work: you send this value from the send-abstraction to the receive-abstraction that contains your message, and you want the message to understand this value + the abstractions creation argument at the same time when the value is sent = ?

sorry WK, i reread that 10 times, and really can't understand.

could you explain it more clearly, or post a small zip with the patches to illustrate?

yeah, i know...:)
attached an example, it's quite simple

http://www.pdpatchrepo.info/hurleur/example.zip

here, use this receive abstraction.

http://www.pdpatchrepo.info/hurleur/receiveabstraction.pd

thanks mod! i knew it would be something like that and i was very close to this
i didn't try a bang inside the [trigger]-object but a float instead... the bang is a bit confusing

I understand that message and object dollar args ($1 etc) are substituted with values from different types of sources: Object arg values are from their enclosing scope's creation arg values and message args are from their inlet values. What do I do if I want to create an object with a dynamic value from a message?

Specifically I want a small abstraction wrapping [ctlin] so I can choose during runtime which control (and/or its channel) it's getting CC values from. [ctlin] has no inlets, nor properties (so no receive symbol), only creation args. I thought that I could Put a [ctlinWrapper] subpatch in my patch (saved in the same folder or in the Path as ctlinWrapper.pd ). In the subpatch include [inlet]-[f] to accept a message sent in the enclosing patch connected to the subpatch inlet, that would be available in the subpatch as $1. Then I could include in the subpatch [ctlin $1] . But the $1 in [ctlin $1] doesn't seem to receive the value from the inlet, as [ctlin $1] doesn't output any value even when I work the MIDI control that generates the CC signal.

Is there a way to specify by message during runtime a creation arg of an object? Or otherwise specify during runtime rather than at creation the control that [ctlin] reports?

Matthew, mke ctlin omni and filter out the ch, ctrl# you want after ctlin.

I have run into a snag with renaming gui send and receive that have $0 and need $0 in the name after the change.

a message box filled with

**
[f $0]
[; $1-gui-rx send $1-gui-tx(

works but gui's send is named "1202-gui-tx" so then i can change it to gui2 or gui3 or whatever and that is fin e while the patch is running but if i save the patch and open it back up gui's send still has the float value from the last run of the patch in the properties dialog instead of $0

so I got clever and

done this

**
[f $0]
[pack f 0]
[; $1-gui-rx send $2-gui-tx(

that also worked while the patch was running as well as sent the $0 to the send name and could be checked in the properties dialog

except after the patch was saved and opened back up

the message mbox looked like this

[; $1-gui-rx send $\$2-gui-tx(

actually i will add another $ variable now to show you what the source looked like
$\$2-gui-tx\$3

has another variable parameter in it like $0-gui-tx7 or wat have you
so now I am stuck.

I will get the source and paste it in here so you can see what I'm talking about.

the probl;em is getting actually the $0 instead of what $0 is equal to at runtime int the name of a send or receive at runtime.

#X msg 188 -194 \; \$1-o\$2-waveform-rx receive \$4-o\$3-waveform-rx
\; \$1-o\$2-dt-rx receive-rx \$4-o\$3-dt-rx \; \$1-env\$2-o\$2-dt-rx
receive \$4-env\$3-o\$3-dt-rx \; \$1-lfo\$2-o\$2-dt-rx receive \$4-lfo\$3-o\$3-dt-rx
\; \$1-o\$2-pw receive-rx \$4-o\$3-pw-rx \; \$1-env\$2-o\$2-pw-rx
receive \$4-env\$3-o\$3-pw-rx \; \$1-lfo\$2-o\$2-pw-rx receive \$4-lfo\$3-o\$3-pw-rx
\; \$1-env\$2-o\$2-rx receive \$4-env\$3-o\$3-rx \; \$1-lfo\$2-o\$2-rx
receive \$4-lfo\$3-o\$3-rx;
#X msg -109 -193 \; \$1-o\$2-waveform-rx send \$4-o\$3-waveform \;
\$1-o\$2-dt-rx send \$4-o\$3-dt \; \$1-env\$2-o\$2-dt-rx send \$4-env\$3-o\$3-dt
\; \$1-lfo\$2-o\$2-dt-rx send \$4-lfo\$3-o\$3-dt \; \$1-o\$2-pw-rx
send \$4-o\$3-pw \; \$1-env\$2-o\$2-pw-rx send \$4-env\$3-o\$3-pw
\; \$1-lfo\$2-o\$2-pw-rx send \$4-lfo\$3-o\$3-pw \; \$1-env\$2-o\$2-rx
send \$4-env\$3-o\$3 \; \$1-lfo\$2-o\$2-rx send \$4-lfo\$3-o\$3;****

@billystiltner said:

Matthew, mke ctlin omni and filter out the ch, ctrl# you want after ctlin.

Yes, that will work but I try to reduce computation as much as possible. Pd is signal processing that is demanding of HW capacity, and some code I'd like to work on the tiniest HW (Raspberry Pi and smaller as they come out). Since [ctlin] takes a parameter at least filtering (if not actually selectively generating) for the specified control, I'd like to be able to select at runtime the control whose state it outputs. Plus the filtering approach clutters the patch, not just computation overhead but also it makes the program's logic less clear for ongoing revisions.

It seems that's not possible using Pd in its current state, so filtering is necessary. That's something to consider for revisions to Pd, since it should be possible. Dynamic patching should have available a more consistent model of the patch components and patches to make from them.

Matt, if you could figure out the particular ctlin's object number maybe you could use pdmsg somehow to change the ch and control # at runtime, I am getting ready to look into this to fix my problem with the $0

it seems that tcl has a special way to signify a literal

puts "$Z_LABEL $Z" ;# Prints the value of Z
puts "$Z_LABEL \$Z" ;# Prints a literal $Z instead of the value of Z

sorry for the uninformed intrusion,

but doesn't all midi input need filtering at some stage anyway?

Is there really that much difference in cpu usage if it's filtered at the C level inside an object, or at the abstraction level within the pd environment???

@billystiltner said:

Matt, if you could figure out the particular ctlin's object number maybe you could use pdmsg somehow to change the ch and control # at runtime, I am getting ready to look into this to fix my problem with the $0

Thanks, I'll look into it.

@billystiltner said:

it seems that tcl has a special way to signify a literal

puts "$Z_LABEL $Z" ;# Prints the value of Z
puts "$Z_LABEL \$Z" ;# Prints a literal $Z instead of the value of Z

Yes, Pd has a lot of problems using metacharacters (including $, {, } and some others) in data - usually prohibiting them. It usually doesn't even allow them, but in this case it allows the (somewhat) integrated Tcl to do what most languages do: use the backslash \ as an escape to indicate to the runtime data processor that the following $ character is not a metacharacter, but a literal.

There is no quoting system, and not even strings - except some crude instances that aren't all the same thing, like comment objects (not exposed to the Pd API) vs messages vs anything data etc. I guess it's "pure data" in that it's "no metadata". The somewhat arbitrary limits to dynamic patching are because there really isn't any "metaprogramming" available (programmer makes a patch that does some programming, like create objects at runtime).

I wish Pd could treat a patch's objects and connections as data at runtime. But I also wish it used Javascript instead of Tcl, and a browser/DOM instead of Tk. The patch window (or even better, a purely virtual object, not a GUI, container of the patch) should have an addressable data structure of the patch, and objects should be readable/writable/creatable/destroyable at runtime through that structure. Maybe next time.

@mod said:

sorry for the uninformed intrusion,

but doesn't all midi input need filtering at some stage anyway?

Is there really that much difference in cpu usage if it's filtered at the C level inside an object, or at the abstraction level within the pd environment???

I haven't measured the difference between [ctlin]-[filter for cc] and [ctlin cc]. Maybe [ctlin cc] doesn't query the MIDI driver by cc, but itself filters for cc. But even if the latter, filtering downstream from [ctlin] (without a cc creation arg) means Pd has to transmit all MIDI data to whichever downstream objects filter it, plus the filtering.

In any case there's a problem with semantics, and hence maintainability, when the object can be created by GUI with a filter/query arg but dynamically the filter/query arg is unavailable. Dynamic patching would be a lot more useful if its API were identical to (or better yet a strict subset of) what's exposed to the patching GUI. Pd would be a lot less idiosyncratic, and own more of the simplicity from graphical patching that it claims.

@Matthew said:

I haven't measured the difference between [ctlin]-[filter for cc] and [ctlin cc].

can you measure it and pass on the info?
if you can find a significant difference, then we might get the change you're asking for

@mod said:

@Matthew said:

I haven't measured the difference between [ctlin]-[filter for cc] and [ctlin cc].

can you measure it and pass on the info?
if you can find a significant difference, then we might get the change you're asking for

What's the accepted benchmarking approach?

A solution has been found from the pd-list

**
[f $0]
[$1 $ 0 (
[; $1-gui-rx send $2$3-gui-tx(

with a gui which has it's receive named $0-gui-rx
this will rename it's send to $0-gui-tx**

Im not sure if this is helpful to the proposed question, but '$0' can be sent as a literal in a pd message box if done so in the following way:
[ f 0 ]
|
[ $1 (
|
[ print ]

The result will be "\$0," Which can then be sent in message boxes or [iemguts/sendcanvas ] to named objects as an argument for naming sends etc.
Cheers!

@th8a Are you sure? That prints 0 (zero).... as expected..... in every version of Pd that I have. What is your distribution?
This normally works.....
[list $ 0(
|
[$1$2(
|
[print]

David.

(There are, however, many cases where you would like the use the patch's $0 value inside a message box ... in which case, the $0 value of the parent is passed into the message box as $1 or $2...etc... Please see the example patch for a demonstration of this)

In Pd-l2ork/Purr Data you can just use [$0( and it will expand to the value of "$0" for that canvas. This gets rid of the little clumps of [f $0] every time you want it in a message box.

Edit: clarification

@whale-av sorry for the delayed reply. I can see where the confusion is here. It would seem that the form of the website took what I typed and saw it as code, changing what I typed to what is seen here. Yes, what you see in my post will indeed print '0' as expected. lol. If you change [$1( to have two dollar signs. which won't show up if I type it... then the result will be \$0. '[$1( '