Hi everyone,
I have an [expr] object in an abstraction and I'd like to set the formula for the [expr] from the main patch, either at creation via argument or later with a message of sorts if possible.

This seems to work with simple formulas (the objects created have the appropriate number of inlets and the output is correct), however with more complex ones which might include spaces, the object won't create.

Does anyone have any suggestion on how to set expressions for the [expr] object after the creation, if indeed it's possible at all?

Thanks for your help.

i just start to learn about the expr object, so i am not sure, but here is some information: http://yadegari.org/expr/expr.html
in the expr helpfile examples are some objects with spaces, i assume the spaces are allowed at certain positions. and you need $f1, $f2... for the variables.

@Jona Yes the spaces are allowed as long as the syntax is correct. However, as I have the [expr] in a subpatch and I'm trying to set its expression(s) from the parent patch, if I do it via creation argument it won't work because if there are spaces in the creation argument, then they are interpreted as different arguments.
I'm trying to see if it can be done with dynamic patching or with the iemguts objects like [sendcanvas], but I fear that creating an object with spaces in the name is going to be tricky. I have never done any dynamic patching before so I still hope there is a simpler solution.

is this what you want to do?exprabs.zip

@Jona No, I want to create multiple instances of the same abstraction and send to each 2 lists: one containing the expression for [expr] and one with the variables for the expression (sending the latter to the first inlet of [expr] will distribute the floats to the outlets, since different instances will have a different number of inlets depending on the expression). The parent would patch would look like this:

Actually it turns out that it can be done with dynamic patching somehow, but the problems are not the spaces but special characters like comma or $0 (which I might need to use if the [expr] expression is looking up values from a table in the parent patch), and so the message needs to be formatted like this.

It's pretty messy but at least it works.

@weightless i think it should be possible to do it with the creation argument and just leave out the spaces?

i made a rudimentary expression generator, that shows how it can be done with dynamic patching (for example, there might be other ways).

expression-generator.pd (updated just for fun)

Still, i wonder if the easiest way would be to just directly type into the expressions.

@weightless Ah, the way you did it is actually better!

@ingox

abs_expr_gen_extended-help.pd
abs_expr_gen_extended.pd

Hope you don't mind but I really like what you did with yours. So I took the liberty of extending it to

1. include the additional 10 functions: sin,cos,tan,sqrt,log,exp,abs,max,min, and pow
2. added number keys for 0-9
   and
3. abstracted it so it sends a symbol which using [namedcanvas] can write the objects directly to the current canvas, i.e. not to a subpatch nor abstraction.

Thanks, for you work on this. It's quite cool.

And yet another case of: Darn! I wish I had known this sooner.

Oh, I also included x and y, so you can tell it where to write the obj.

Peace, Love, and Music thru us all,
Scott

@svanya Just great! Thank you.

@ingox @svanya Thanks, great solutions but unfortunately there is a problem with functions that require a comma. I've taken bits from your patches to come up with this solution which is fairly involved but it works.

dynamic.expr.zip

Now the expression is taken from the argument. I've tried a few ways to send a list to the object to replace the expression and save is as new argument as well with [canvasargs], but none seemed to work when there is a comma involved. That would be very handy (in fact it was one of the main reasons to do this rather than just using [expr]) but right now my brain is melting after all the trial and errors and crashes.

There still is a problem with the use of $0. I would like the [expr] to be able to access values from tables in the parent patch. I can't think of how this could be done in my implementation since any $0 that is in the argument is passed to the abstraction as-is, and therefore becomes the $0 of the abstraction.

@weightless a couple of things. The comma is a tricky beast, but it still works with the [list tosymbol] method: expression-generator.zip. [list tosymbol] will escape the comma with a backslash, which still works inside the expression.

The $0 issue is different: expr cannot accept what is community standard $0-something. For one it will always read "-" as minus and second it won't accept symbols that begin with a float. So table$0 can be accessed by expr.

i made a working demo: dollar-zero.zip

We write $0, but pd will always convert it internally, so in the end it is just a number, i.e. 1061. The number changes when you, for instance, open a patch a second time, but the functionality stays the same. You can pass the $0 of the main patch into an abstraction via creation argument. Then inside the abstraction you can access stuff of the main patch that has $0 (of the main patch) in its name by using the creation argument instead. If you give $0 as the first creation argument, inside the abstraction you can then use $1, as it is in fact the $0 of the main patch. This is shown in the demo.

@ingox Thanks for your input. Yes the comma is a tricky beast indeed, but now I've got the patch working by passing the argument or an external message for the expression to a [text] object and that seems to work for now.

I'd given up on $0 after I tried everything but didn't think of putting it at the end of the table name without the "-" sign, I'll give it a try!

@weightless Just a quick note: If you are sending the expression and the parameters into the abstraction, you could also just do the calculation in the main patch and send the result into the abstraction... just a thought...

@ingox the problem with $0 here is that I'm writing the expression in full in the abstraction's arguments, and then inside the abstraction I'm getting all the arguments as a list of symbols and therefore $0 gets copied as-is, and so the expr object ends up with the name 'table$0', and $0 gets substituted with the unique identifier of the abstraction, not the parent patch. The only way I can think of to do it right now is thus:

And yes, it sounds like a lot of trouble to go to when I could just do the calculation in the parent. I'm trying to implement something in the vein of what's described in the paper Chaos Melody Theory by Elaine Walker, and I'm going for a modular setup here where I'm envisioning using lots of abstractions, each with it's formula that can also be changed on the fly (via external message), has an internal feedback of sorts and writes the last n states to a table that can be referenced by other abstractions.

Perhaps this is the wrong way to go about it, it sure seems to most immediate and at least I've learnt something about the [expr] object and the iemguts library!

@weightless Thanks for explaining, sounds interesting. And yes, regarding $0 the way you described would be the way to go, using table$1 as part of the creation argument. Best wishes

@ingox Thank you for your help. I'll post the patch when it's fully working and cleaned up.

@weightless @ingox
You guys lost me about 3 posts ago, but can't tell from what I saw in your shares the idea below (image). But it's one way to put $0 into messages: via pack. If you'll already got this, then please forgive my ignorance of y'all's concerns.

Also, found out how to include commas (as you mentioned ingot via [list tosymbol]) and added it to my "-extended version" and include it here in case anyone wants the comma-included version, (I apologize for the oversight on my part).

abs_expr_gen_extended.pd
abs_expr_gen_extended-help.pd

Peace,
Scott

@weightless [bytes2any] from the Moocow library is the same as [list tosymbol] but works with $0.

@LiamG That's good to know thanks, although in this particular situation I think it was a problem of using the syntax "$0-" inside [expr], and of addressing the wrong $0, so to speak.

I'd just have a send and receive in my abstraction, and then have the same sends and receives outside in my parent patch, with the expr

exprSending.zip

here's a better version of what i just posted, without the send/receives
exprSending.zip