This is what I want to do (using pd-extended_0.43.4-1, Ubuntu 11.04): when the variable varA changes, I want to explicitly set the variable varB to 1; when either varA or varB changes, I want to compute the result of 2*varA+varB, and print all three (varA, varB and the result) values.

I came up with this PD patch (code below):

The problem is - when I click to set the value of varA, there are four printouts, all different; when I click to set the value of varB, there are two printouts (which is why there is the metro/onebang thing - so I add a delimiter after such a quick sequence has finished, so I can see how many printouts were there per click). So after patch load - if I first click [2( of varB, and after I click the [2( of varA, I get the printout:

A/B/res: 0 0 2
A/B/res: 0 2 2
---------: bang
A/B/res: 0 2 1
A/B/res: 0 1 1
A/B/res: 0 1 5
A/B/res: 2 1 5
---------: bang

If I remove the bang connections from the [t b f] to the [pack], after patch load, and the same click sequence, then there is no printout for the first click (on [2( of varB), and for the subsequent click of varA I get:

A/B/res: 2 1 5

... which actually turns out to be correct (as 2*2+1 is 5, given that varA also sets varB to 1); and it's printed in a single line, which is what I want. However, I'd like the same effect when values for varB are changed - which is why I added those [t b f] there in the first place (however, those cause multiple messages to be output/printed).

What is the recommended way to do this (e.g. output a list - but only once - from an object, and only after other calculations have completed)?

(I simply don't trust removing the bang connections from the [pack], as it's pretty clear that [expr] should finish later than when varA comes into the hot inlet of [pack], if it is varA being set. The [onebang] thing could be modified to "gate" quick sequential messages if the timing isn't relevant - but what if I need the reaction/printout ASAP after the result has been computed?)

Thanks in advance for any answers,
Cheers!

Patch as attachment: test.pd

Ok, I think I got it - test2.pd is what worked for me:

Basically, the trick was to use a named variable, which in PD is afforded by the [value] ([v]) object - [expr], it turns out, can use named variables directly, so the worries about triggering it correctly in terms of hot and cold inlets (when using $f1 etc) disappear. The only thing left then is to use a [t b b b] to set all [pack] inlets in a sequence (the final, as hot inlet, will trigger the packed output).

It's only a shame one cannot control whether the [value] is local to the patch - it's always global. In this case it suits me fine, but I could imaging other cases where I'd want it local. Still - it works for me, all is good :)

Cheers!

EDIT: Note that [send] interferes with [value] names; e.g. if you add something like this in this post's patch:

[2(
|
|
[s varB]

... and click the [2(, you'd get:

value: no method for 'float'

... which, I guess, means that [v varB] is reacting to the [send]. However, [receive varB] doesn't print anything if any [value varB] object is changed or banged. So, careful with naming send/receive vs. value names...

Hi, if you want local values you could try a more "anonymous variable" approach:
resultAB.pd

edit: I saw you had the printout in a different order in your patches:
ABresult.pd

Thanks for sharing your reasoning, and for telling us about the final outcome. One never knows when one is going to find a similar problem.

"It's only a shame one cannot control whether the [value] is local to the patch - it's always global. In this case it suits me fine, but I could imaging other cases where I'd want it local".

According to Pd's documentation, there's a workable if clunky solution...using underscores.

For example, if the following [value], or [v], is in a certain patch...

[440(
|
[v _$0_tuning]

it will NOT communicate with the following [value], or [v], in a different patch:

[445(
|
[v _$0_tuning]

Besides, this also works for the [expr], [expr~], and [fexpr~] family . For example:

[expr $f1 + _$0_tuning]

Search in your system for the all_about_expr_and_value.pd file. There you can read more about how to "deglobalize" [value].

(However, wouldn't it be simpler to give each [value] a different name....[value globalCoffee] and in some other patch [value localCoffee]? This would be using the prefixes global and local as reminders).

Anyway, for that kind of thing, Pd's solution is simple, which I could summarize as follows: surround $0 with two underscores.

Hi @seb-harmonik.ar, @LandonPD - many thanks for your replies!

if you want local values you could try a more "anonymous variable" approach: [...]
ABresult.pd

Thanks for that, ABresult.pd works great - and that was exactly what I was trying to do with my first patch, but failed to :) For reference, here's a screenshot of ABresult.pd (I just moved the boxes a bit, no change otherwise):

I like the use of the cold inlet of the [float] box - wish I could think of it at the time :)

[...] it's always global.

[...] using underscores.

Thanks for pointing that out, I missed that in the documentation! However, I'd disagree the underscores are doing the trick here - I'd guess it's the "dollar-zero" $0. For example, open a new patch and try this:

[bang(
|
[print $0]

I get printout like

1023: bang
1023: bang

.... Then open another new patch, add the same objects, click on [bang( -- now I get:

1024: bang
1024: bang

So, $0 looks like an unique (random?) integer identifier of each patch window - and thus objects like [v _$0_tuning] will still be global; except there will be multiple instances of them, with unique names based on the ID of the patch window - which is good enough of a variable partition/segmentation (as far as I am concerned :))

wouldn't it be simpler to give each [value] a different name....[value globalCoffee] and in some other patch [value localCoffee]? This would be using the prefixes global and local as reminders

What I am afraid of, in this case, is what is stated in the [pd scope] inside doc/5.reference/value-help.pd:

The exception to the above rule is [value]. This object is a container which makes its data known to all [value] objects of the same name in all active Pd windows on a single computer: hence, GLOBAL scope.

Thus, I think the $0 is probably the best approach, in order to limit the influence of [value] to a single patch window - even if also that variable is still global; the only caveat being that it would limit the influence to the master patch window only, and not its subpatches (as the subpatches will also have their own unique $0).

Thanks again for the feedback - cheers!

Yes, the $0 is the one doing the trick, of course. And, when we put a couple of underscores surrounding it, we are avoiding crosstalk between active patches. These are really nice flexible features!

By the way, I've seen you've liked @seb-harmonik.ar 's use of the cold inlet of [float]. I've noticed that building a really simple GOP subpatch made with an f-tagged number box inside, can allow you to understand better or debug all sorts of things. A GUI float...which you can later delete if you don't want it anymore. Simple but it can multiply your headaches by 0.5.

Try this one (it still looks good when you increase the font size from 10 to 12):

GUIfloat.pd

I also uploaded the GUI float thing here: http://forum.pdpatchrepo.info/topic/8950/gui-float

Have a nice day

Hi @LandonPD :

[...] And, when we put a couple of underscores surrounding it, we are avoiding crosstalk between active patches.

Ah, I wasn't aware of that - many thanks for clarifying!

GUI float

That looks really good - thanks, much appreciated...

Cheers!