suggestion to add an object like [canvasinfo] from purr data in vanilla

[porres]

It could be a simple adoption of that object or a newly designed one with a different name and features.

For a previous discussion about it, see #150

[porres]

I don't really care abbout that many features, mostly "args" and "dir", in which I designed two externals myself that take care of that

[mrufrufin]

I would also find the "args" and "dir" functionality helpful as well as "name" (but I'd see no reason to exclude any of the apparent functionality of [canvasinfo], not so familiar with the object though). Another potential source of inspiration for canvas-oriented functionality would be the iemguts library which has [canvasargs], [canvasconnections], [canvasdollarzero], [canvaserror], [canvasindex], [canvasname]. [canvasobjectposition], [canvasposition], [canvasselect], [receivecanvas].

It looks like [canvasargs], [canvasdollarzero], [canvasindex], [canvasname], and [canvasposition] have similar functionality to [canvasinfo] (but the latter looks to be simply a "getter" and not a "setter" at least for name which is perhaps safer).

[porres]

but I'd see no reason to exclude any of the apparent functionality of [canvasinfo]

it'd be silly to have an object with the same name and less functionalities, indeed, but my point was that it could be a different object with different functionalities and a different name - like, it could be just [canvas] (as discussed in #150)

[HenriAugusto]

I back that especially because the |args( method is a must.

Currently the only vanilla solutions to get the argument list is either using a tricky exploit + dynamic patch routine

or

actually passing everything in a single symbol, like arg1/arg2/arg3, and then splitting it into a list using [list fromsymbol/tosymbol]. But this is not compliant with PD's standard syntax!

One thing a miss from [namecanvas] is a selector. If you send |args( to it i would like it to prepend "args" to the list of arguments. So one would be able to use something like [route args dir toplevel] to easily send the information to the right place.

---

On a side note: I see [namecanvas] on the "obsolete" (i'm reading deprecated) list of pd's object list so |name( might be a substitute, but i'm not sure. I like the ability to pass a canvas' name as an argument to an abstraction, like

|namecanvas $0-this]

[someAbstraction $0-this ]

It allows me to send |map 0, map 1( from the abstraction to the parent. It is useful in cases where the abstraction change it's graph-on-parent values during execution and need to tell the parent to update the canvas.

[HenriAugusto]

(although i do like getting the list of arguments using the $@ syntax in Purr Data because you can pass the list of arguments from one abstraction to another)

[porres]

you can also do things like that with an external, ask for the arguments of a parent patch

[HenriAugusto]

Yes but you can't pass them as abstraction arguments with [canvasinfo]. You must pass them through an inlet. Yet i still think [canvasinfo] is still desireable, of course.

[porres]

Yes but you can't pass them as abstraction arguments with [canvasinfo]. You must pass them through an inlet.

No, you don't need to pass them via an inlet. You can ask the object to give you the arguments of a parent patch, that is what I meant to say

[HenriAugusto]

Oh, i see. I've missed that.

Still beeing able to have the $@ expansion would allow you to do things like the following:

Take for example this abstraction to perform operations on two [value] objects:

You pass the operator as an argument and it is instantiated with [$1]. This is kind of works in the sense of a lambda function, comparing to major textual languages.

That case works because you know the operator is a "list of size 1". But let's say the user wants to pass a variable size object.

Let's say you want the user to be able to pass to the abstraction a "[drawpolygon] lamba". That means the user might call

[abstractionName drawpolygon 900 15 0 0 100 100]
[abstractionName drawpolygon 900 15 0 0 100 100 75 75 33 33 66 66]

By having a [$@] inside abstractionName it can instantiate the [drawpolygon] object properly.

Using a something like [$1 $2 $3 $4 $5 $6 $7 $8 $9 ... $256] definitely wouldn't work because there would be a lot of zeroes that shouldn't be there so the wrong polygon would be drawn.

[umlaeute]

That case works because you know the operator is a "list of size 1". But let's say the user wants to pass a variable size object.

how would you imagine that to work?
I'm interested in the case where you do not want to the entire list of arguments to be passed to an object, but only a subset.
(e.g. have [valueOp froynwine 42 1.05 $0-a $0-b] expand to a [froynwine 42 1.05] which is fed both $0-a and $0-b.)

[HenriAugusto]

The $@ syntax from purr data doesn't allow you to pass arguments subsets. It passes the whole argument list. It works for ex on cases like the one i've described but not on others where you need a subset.

But if you want a subset of the arguments and you know which subset it is you can just do something like this

[$3 $4 $5 $6]

The problem is that you would not be able to mix both aproaches.
For that we need to get creative. Like having, building on the $@ syntax:

• $@ - list of all arguments
• $@(3:6) - sublist of all arguments, from 3rd to 6th.
• $@(3) - sublist of all arguments, from 3rd to last.

Something like this.

So, let's say you want to pass 4 arguments to an abstraction and after that a variable number of arguments that are going to be a [drawpolygon] object.

You could have some objects using the first 4 arguments as normal and then an box with the new syntax for reading the rest of the arguments:

• [symbol $1] [float $2] [receive $3-someName] [+ $4]
• [$@(5)]

And instantiate it like

• [foo 10 15 20 30 drawpolygon 175 7 0 0 100 100]
• [foo 10 15 20 30 drawpolygon 175 7 -33 -33 75 -75 66 -66]
• [foo 10 15 20 30 drawpolygon 175 7 -50 -50 50 -50 50 50 -50 50]

[umlaeute]

btw the $@ syntax is no invention of purr-data, but had been in Pd-extended for ages (and originates from a Pd-vanilla patch a decade ago)

[HenriAugusto]

Totally missed it in extended.

Oh, the .patch was created in 2006! Why it wasn't included in vanilla?

[porres]

but had been in Pd-extended for ages

where is it?

[umlaeute]

@porres which version of Pd-extended is this?

[porres]

42-5, is it on the last one (43)?

[porres]

ok, I see, yes it is, and I also totally missed that too!!!

[porres]

Well, since you mentioned this was from a decade ago (actually from 2006 according to henri) and was in Extended for ages I assumed it should have been in 42-5... well, this is mind blowing! I also wonder why it didn't make into vanilla.

But anyway, this is a suggestion for an object maybe a discussion for $@ could be carried in another issue ;)

[porres]

I'm closing this since I don't think we should port this object from Purr Data and because I'm working on a new object from scratch.