Ullstein

I have a request that is maybe impossible.

I created several patches that can be used again in other combinations. These patches contain send/receive pairs. Now if I use the same patch in 2 different sets parallel, the data from the send objects will appear in both sets at the similar named receive object.

Is there a possibility to add a second argument to object boxes remotely with loadbang, I mean like patcherargs, that my main patchers name becomes part of the send/receive objects names? 

For example, I build a patch named "Good music" and use my abstraction patch in it, it would be great if my send/receive objects would have this name as argument in it ("s pitch" / "r pitch" become "s pitch_Good_music" / "r pitch_Good_music" - to add the underline js strjoin.js would do, but how to change the name of the object? The way by creating new Objects with "thispatcher" is to complicated due to all connections need to be redone as well. 

I have a request that is maybe impossible.
I created several patches that can be used again in other combinations. These patches contain send/receive pairs. Now if I use the same patch in 2 different sets parallel, the data from the send objects will appear in both sets at the similar named receive object.
My question:
Is there a possibility to add a second argument to object boxes remotely with loadbang, I mean like patcherargs, that my main patchers name becomes part of the send/receive objects names? 
For example, I build a patch named "Good music" and use my abstraction patch in it, it would be great if my send/receive objects would have this name as argument in it ("s pitch" / "r pitch"  become "s pitch_Good_music" / "r pitch_Good_music" - to add the underline js strjoin.js would do, but how to change the name of the object? The way by creating new Objects with "thispatcher" is to complicated due to all connections need to be redone as well. 
Any chance?

Thanks for advice 

I have a request that is maybe impossible.
I created several patches that can be used again in other combinations. These patches contain sen

maybe-impossible

Have a look in the max examples folder for "send-receive-hoard-#0". If you prepend #0 to the [send] and [receive] names it will turn into a different random number in each subpatcher on instantiation.

https://cycling74.com/forums/generic-sends-and-receives

https://cycling74.com/forums/send-and-receive-with-variable-names

Have a look in the max examples folder for "send-receive-hoard-#0". If you prepend #0 to the  [send] and [receive] names it will turn into a different random number in each subpatcher on instantiation.

Further articles on the topic
https://cycling74.com/forums/generic-sends-and-receives 
https://cycling74.com/forums/send-and-receive-with-variable-names



Thanks Martin, looks like I can get there...

Thanks Martin,  looks like I can get there...


[object #0_myfunnyname] works well as far as the s/r is really only inside the patcher.

as soon as you need to s/r to the outer world it will fail.

in this case the trick is to use different arguments-to-patcher to generate send and receive names inside.

so you patch will be e.g. [mycoolpatch a] and another instance if it will be [mycoolpatch b]

inside the patch you will now have to do:

or to be exact, [send a_myfunnyname] in the first instance and [send b_myfunnyname]

now you do not even have the same abstraction with different & known names for the s/r, it is even better: you can see it from outside how the name is. :)

[object #0_myfunnyname] works well as far as the s/r is really only inside the patcher.

as soon as you need to s/r to the outer world it will fail.

in this case the trick is to use different arguments-to-patcher to generate send and receive names inside.

so you patch will be e.g. [mycoolpatch a] and another instance if it will be [mycoolpatch b]

inside the patch you will now have to do:

[loadbang]
[t #1]
[sprintf s%_myfunnyname]
[prepend set]
[forward] (or receive)

it will be the same as

[send myfunnyname] (or receive) 

or to be exact, [send a_myfunnyname] in the first instance and  [send b_myfunnyname]

now you do not even have the same abstraction with different & known names for the s/r, it is even better: you can see it from outside how the name is. :)

-110





knowing that you are a long time Max expert I certainly trust your expertise, but I have to admit that Martin's suggestion works for me over the hierarchy of several patches without any problem. Anyhow many thanks for taking care.

Hi Roman,
knowing that you are a long time Max expert I certainly trust your expertise, but I have to admit that Martin's suggestion works for me over the hierarchy of several patches without any problem. Anyhow many thanks for taking care.

OK, you are of course right, it makes problems, so I checked your suggestion, but either I misunderstood and have it not written correctly. Anyhow no matter what I do in both patchers appear always the same numbers . Can you please advice again? Many thanks, Hans Peter

tester a.maxpat

tester b.maxpat

the issue is that the outer world can not know what happens exclusively inside a patch - and if you would tell the patch from outside how something is called internally, then you could as well give up using s/r.

that is a classic and it happens to me once a week: you accidentially wrote "prepend send".

i knew you would find out yourself. :)

the issue is that the outer world can not know what happens exclusively inside a patch - and if you would tell the patch from outside how something is called internally, then you could as well give up using s/r.

that is a classic and it happens to me once a week: you accidentially wrote "prepend send".



oh, and i also wrote nonsese, the sprintf does not work this way. (i usually answer posts without max.)

it should now properly output "thisargument_ myfunnyname" and "thatargument_ myfunnyname" 

btw. for my part i use base names which are identical to or contain the name of the abstraction patcher where it is used. that way you will never create double names for your sends, not in 20 years.

oh, and i also wrote nonsese, the sprintf does not work this way. (i usually answer posts without max.)

please replace it with

[append _myfunnyname]
[sprintf %s%s]

it should now properly output "thisargument_ myfunnyname" and  "thatargument_ myfunnyname" 

btw. for my part i use base names which are identical to or contain the name of the abstraction patcher where it is used. that way you will never create double names for your sends, not in 20 years.


hm, I changed aeverything as you said, no change. When I bang "t #1" it delivers a "bang", is that supposed to be that way?

you can test patches containing #0 or arguments #1 - #9 only when loaded as abstraction. (otherwise every argument, including symbols, are 0, that is correct)

remove the spaces from their names and then call three instances like this:

[TesterA firstinstance] [TesterA secondinstance] [TesterA 3]

you can test patches containing #0 or arguments #1 - #9 only when loaded as abstraction. (otherwise every argument, including symbols, are 0, that is correct)

remove the spaces from their names and then call three instances like this:

[TesterA firstinstance]  [TesterA secondinstance]  [TesterA 3]



 you accidentially wrote "prepend send". 

and once more i told you nonsense instead of just patching it myself. :(

this time i will just provide a working patch instead of making claims about how things would work.

howto-sr-in-abs.zip


 you accidentially wrote "prepend send". 

and once more i told you nonsense instead of just patching it myself. :(

this time i will just provide a working patch instead of making claims about how things would work.


I am super sorry, but I don't get anything. If I change the numbers in your main patch nopthing happens at the receive side. I did save "mycoolpatch" as an abstraction. But nothing moves. I don't want to take all your time, maybe it does not really make sense, it seems to be very difficult. Sorry.

the send in the main patch is only received in the subpatch. and the other way round. (open the subpatcher when you are in the main patch)

OK, I got it, but that is much to complicated, I was looking for a simple setting of the s/r combination. Obviously that is not possible in Max, well... Anyhow, thank you so much for spending all the effort and time to bring me to this point. 

But to be positive, maybe this is a good suggestion to the Max-team to create s/r bundle that can be named with the patcher-name it lives in. Yes?

Just like saying "send my_data mainpatcher_name" or whatever similar. And the patchername would be chosen like an patcherargs-argument.

Again many thanks and sorry for using up your time, was not intended like this.

OK, I got it, but that is much to complicated, I was looking for a simple setting of the s/r combination. Obviously that is not possible in Max, well... Anyhow, thank you so much for spending all the effort and time to bring me to this point. 
But to be positive, maybe this is a good suggestion to the Max-team to create s/r bundle that can be named with the patcher-name it lives in. Yes?

Just like saying "send my_data mainpatcher_name" or whatever similar. And the patchername would be chosen like an patcherargs-argument. 

Again many thanks and sorry for using up your time, was not intended like this.
 All the best, Hans Peter

when you make the whole thing an abstraction (hp.send?), it is less than one line of code and no longer complicated at all. :)

dont worry.

when you make the whole thing an abstraction (hp.send?), it is less than one line of code and no longer complicated at all. :)


Strange, I thought I wrote a response, it's not there, so I do it again:

Although I am an old MAX-user, I got introduced in 1990/91 at IRCAM, where I had a short residency, it was Max 2 I think. This experience inspired me to get many of my friends hooked as well. Nevertheless I am really no Computer programmer and C or the like are for me cryptic. I am happy to understand this visual consept that Max offers.

However I won't be able to write this, I tried to make an abstraction, but when you add a second argument, it looses it "abstractionhood".

So, I guess, I give up and check for other ideas and work. It was nice communicating with you, thanks for spending so much time on my issue and

Although I am an old MAX-user, I got introduced in 1990/91 at IRCAM, where I had a short residency, it was Max 2 I think. This experience inspired me to get many of my friends hooked as well. Nevertheless I am really no Computer programmer and C or the like are for me cryptic. I am happy to understand this visual consept that Max offers.
However I won't be able to write this, I tried to make an abstraction, but when you add a second argument, it looses it "abstractionhood".
So, I guess, I give up and check for other ideas and work. It was nice communicating with you, thanks for spending so much time on my issue and

Maybe impossible?