Pure-data: [expr~] sometimes loaded wrong from file

[hjek]

Hi,

I've noticed in some circumstances, [expr~] objects inside patches will stop working when the patch is saved and loaded again.

Say I want to get the size of a local array, array$0, then I could make a new patch,foo.pd, and add the object [expr~ size("array$0")] to the patch. When I save, close and re-open foo.pd; everything is ok.

However, if I add a signal/vector input, like this [expr~ $v1*size("array$0")], the patch will work fine while it's open, but when saved, closed and re-opened, the text of the object has changed to [expr~ $v1*size("array\$0")], and the object has a dashed line around it, indicating an error.

The same thing happens with [expr] objects that have both a reference to a local array and a float input.

(I'm running Pd 0.47.1 on FreeBSD)

[danomatika]

This is probably related to the creation order of the objects when they loaded from the patch file. If the array is created first, then all expr objects which refer to it afterwards are created. If the expr objects are created before the array object, they won't create.

Try this: Make a patch where some of the expr objects don't create on a reload, then select the array object, delete it, undo, then save. This should fix the patch.

[danomatika]

Also, I'm not seeing this issue with either Pd 0.48-2 or the new Pd 0.49-0test3 build. Likely, this has been fixed with the update to the expr objects for Pd 0.48.

[hjek]

Hi @danomatika , thanks for looking at this issue!

Also, I'm not seeing this issue with either Pd 0.48-2

I'm still seeing this issue in pd-0.48.2-5 on Arch.

This is probably related to the creation order of the objects when they loaded from the patch file. If the array is created first, then all expr objects which refer to it afterwards are created. If the expr objects are created before the array object, they won't create.

I believe this is incorrect. The issue happens regardless of whether the array in question actually exists. For example [expr~ $v1*size("array$0")] initialises fine, even when array$0 isn't created anywhere.

[umlaeute]

i can reproduce the problem (on Debian/sid with both the packaged Pd-0.48.2 and the Pd-0.49-test 90d6c897c8cd1c9b69f782ba67b377d3ed51a389).

i quick and simple workaround is put the two dollars into separate symbols, by adding a whitespace around *:

~
[expr~ $v1 * size("array$0")]
~

[danomatika]

Yeah, I was wrong about creation order.

I think this is due to the new string handling which escapes some of the special characters. Maybe the expr strings shouldn't be escaped? #473 seems to be a duplicate issue.

[hjek]

i quick and simple workaround is put the two dollars into separate symbols, by adding a whitespace around *:

Thanks for the workaround, @umlaeute .

@danomatika, I haven't looked at the expr code, but given that adding a space between the tokens corrects the escapes, my guess would be a problem with the string tokenisation, and possibly not escaping in general. But, also, I have no idea how expr actually works.

[danomatika]

Is this fixed in 0.50? If not, let's move it to the 0.51 milestone.

[porres]

I see you already checked that it hasn't been fixed ;) anyway, just making it clear that this is a duplicated issue https://github.com/pure-data/pure-data/issues/473

[porres]

funny, I still see it as milestone "0.50", I thought you had changed to 0.51

[porres]

while we're at it, is the plan to keep some as '0.50' in order to suggest it could be part of 0.50.1 or something? or should they all be moved to '0.51'?

[danomatika]

So far, I think I’m the only one tagging issues with milestones. I think I will stop as this seems to imply some sort of organization other than what I as one person was quickly thinking at the time.

As for what the “correct” baking should be, ask Miller what his next release plan is. As far as I could tell, it’s probably 0.51 in the winter.