Do we have patcher-bound send/receive?
I would like to send/receive only inside a subpatcher.
Can we do that, just with two objects?
[s #0identifier] -> [r #0identifier]
There is also [pvar]
Subpatcher no. Yaniki's advice applies only to abstractions. You can use pattr objects to make a kind of local remote messaging. They work, but probably they are not as efficient as plain send-receive objects.
YANIKI wrote:
[s #0identifier] -> [r #0identifier]
This is a normal send/receive and goes all over the place, through the whole patcher hierarchy.
SPECTRO wrote:
There is also [pvar]
[pvar] can only read a variable, you cannot send to [pvar]
——
But I found a solution with [pattrforward] to a named list trigger. Didn't know that [t l] can act as a receiving element.
With [t l MyVar] you can identify the object. And yes, named triggers can be read by [pvar].
See example patch below.
using named pairs of forward/receive work fine with arguments-to-patcher.
I think I have not declared my wish properly:
I want to keep the sent messages in the patcher.
They should NOT go to parent- or subpatchers.
The reason are bpatchers. A [send] or [forward] in a bpatcher goes to all loaded bpatchers, which I don't want.
We have no object for local send/receive, correct?
We got cables, though ;-)
If you have a patcher called xyz containing [send #0_abc] then every time you instantiate xyz in another patcher or in a bpatcher, the actual parameter to that send WILL be slightly different so they will not interfere with each other. The messages will not go to other patchers. That is certain.
(NB. You don't need that underscore after the #0 but I find it makes it a bit easier to notice that there is a parameter there.
forward, receive, patcherargs?
Can't get that working.
[s #o_MyVar] and [r #o_MyVar] go through all subpatches [p MySubpatch] and from them to the parent. I guess I am missing some basic knowledge here and don't find a reference/documentation for this technique.
Can someone please make an example patch with a [s #o...] object?
Are you using a lowercase 'o' rather than a numeric '0' after the #?
Sure looks like it.
Yes, that "#o" was in the suggestions above. With numbers I found at least something in the reference. Works partially for me: Send/Receive with #0 do not communicate between bpatchers and parent (good) but between bpatchers they do (bad).
I give up and use cables or the named [t l] trick I found.
If someone wrote #o instead of #0, then it was a typo.
However I still don't understand. If you load the same abstraction (containing references starting with #0) into multiple bpatchers, they WILL be unique and so if you're not seeing that then you're doing something wrong (or what you're trying to do is not what you say you're trying to do)
By the way, another approach to guarantee complete uniqueness in multiple bpatchers when the #0 isn't sufficient is to include a unique argument to each bpatcher instance and then construct your send (or forward) name so that it includes the argument.
What I do is simple, just testing:
New patcher with [s #0_MyVar] and [r #0_Myvar] plus two number boxes, then save as "MySubpatcher" and close. I open a new patcher, make a [bpatcher] and load the MySubpatcher. Then I duplicate the bpatcher (or make a new one). Now I can happily send between the two bpatchers. According to you all this is wrong, but maybe my bpatchers are close friends and have some telepathic skills.
Please post your patchers
yes bpatchers shouldn't have telepathic powers, or we've reached the singularity point already
Here is the sub patcher:
And here the main patcher:
The bpatchers talk to each other. Where is the failure?
By just looking at the subpatcher, the problem is obvious ---- you said you were using #0 as the prefix (which is what everyone told you to do) but in fact you're using the name #1_MyVar, not #0_MyVar
Oh my God, I am an idiot. That [s #1_...] is an example in the reference text, I thought the number wouldn't matter. Bad thinking, sorry, I should rather follow your advices.
Many thanks, It works now for bpatchers, which is my main point.Problem solved.
(It does not work yet for subpatchers within a patcher. I will look into that, but don't really need it.)
I don't understand the programming reason for your issue in subpatchers unless you are just duplicating the same code in multiple subpatchers. If that's what you're doing, then I suggest you turn those subpatchers into abstractions. Easier to maintain as well.
Yes I duplicate subpatchers and modify the processing of the same variables. But this isn't important, I can handle it. bpatchers were the main issue and they work now. Thanks again.
You could check out Jamoma. By making your (sub)patch a model (by inserting a j.model object) you get a local namespace that can be used for communication within the patch between j.parameter, j.message and j.return objects, and also communicating wiht j.send and j.receive. Here's an example with two identical subpatches, illustrating communication within each of them as models, and also how both of them can be addressed remotely:
Interesting package, thanks.