novasnoa

In the bpatcher you can set Arguments and use them in any object by typing "#1" for the first Argument "#2" for the second Argument...

Is there an object that can create this kind of arguments?

Writing "s #1" in my send object would create "s free"

Writing "s #2" in my send object would create "s world"

If i change the first argument in my object to "my" my send object would change to "s my". And so would all other objects with the argument "#1"

In the bpatcher you can set Arguments and use them  in any object by typing "#1" for the first Argument "#2"  for the second Argument...

Is there an object that can create this kind of arguments?
Like i can set it to: "free world"

Writing "s #1" in my send object would create "s free"
 Writing "s #2" in my send object would create "s world" 

If i change the first argument in my object to "my" my send object  would change to "s my".  And so would all other objects with the argument "#1"

In the bpatcher you can set Arguments and use them  in any object by typing "#1" for the first Argument "#2"  for the second Argument...
Is 

are-there-changeable-arguments-like-you-have-in-a-bpatcher-but-as-an-object-that-you-can-use-more-flexible

they key property of arguments-to-patcher is that they are loaded before anything else, so the argument-to-patcher itself can not be changed on purpose.

you might have noticed that objects reload whenever you type new arguments in the object box.

mabye it is too early to add the second part of the answer: you should always create abstractions and bpatchers like compiled objects work, too. i.e. if you want to change that parameter which is currently set by an argument, provide and inlet for it.


what do you mean with "create"?

they key property of arguments-to-patcher is that they are loaded before anything else, so the argument-to-patcher itself can not be changed on purpose.

you might have noticed that objects reload whenever you type new arguments in the object box.

mabye it is too early to add the second part of the answer: you should always create abstractions and bpatchers like compiled objects work, too. i.e. if you want to change that parameter which is currently set by an argument, provide and inlet for it.


I can change the name of a send object (and therefore the destination of the messages send by it) by sending a "set [symbol]" message to its inlet.

I want the same effect but by naming it "s #1" and then have another object (lets call it "arg object") that will define #1.

Lets say in the "arg object" i define: #1 = hello. 

My send object would now send to a receive object called "hello"

If i now change in the "arg object": #1 = world all objects with "#1" in their names would change to "world".

also my send object would now send to receive objects called "world"

This would obviously not only make sense for send object but in lots of situations...

Right now i want to use it to change the first argument of "sprintf object" without triggering it

I just wonder if there is a solution like this.

I want the same effect but by naming it "s #1" and then have another object (lets call it "arg object") that will define #1.
Lets say in the "arg object" i define: #1 = hello. 
My send object would now send to a receive object called "hello"
If i now change in the "arg object": #1 = world all objects with "#1" in their names would change to "world".
 also my send object would now send to receive objects called "world"

This would obviously not only make sense for send object but in lots of situations...
Right now i want to use it to change the first argument of "sprintf object" without triggering it

This should be possible, right? 
I just wonder if there is a solution like this.

you will find that some objects dont allow to use patcher arguments, send, receive, forward, a few others.

then you will have to provide them from outside. which is not a bad thing because it allows you to do some processing to the arguments (for example to create [forward funnyname-01], [forward funnyname-02] , [forward funnyname-03] or make things depend on some argument in the mother patch.)

do you find it handy to write #3 right into object boxes? okay, mabye sometimes it is. but it is also great to always do it outside, then you have total control over it. 

and it also helps with readability of patches and you can choose a certain load order from loadbang if required.

and of course it also solves the scenario you need; prodiving it at position A and then sending it to multiple different locations. (but by connections or sends, not by reinstantiation, because that doesnt work. :) )

i recently posted this example for pd somewhere... this is how i usually provide arguments to the interns of a patcher... then your abstraction works exactly like most objects do.

grafik.png


you will find that some objects dont allow to use patcher arguments, send, receive, forward, a few others.

then you will have to provide them from outside. which is not a bad thing because it allows you to  do some processing to the arguments (for example to create [forward funnyname-01],  [forward funnyname-02] ,  [forward funnyname-03] or make things depend on some argument in the mother patch.)

do you find it handy to write #3 right into object boxes? okay, mabye sometimes it is. but it is also great to always do it outside, then you have total control over it. 

and it also helps with readability of patches and you can choose a certain load order from loadbang if required.

and of course it also solves the scenario you need; prodiving it at position A and then sending it to multiple different locations. (but by connections or sends, not by reinstantiation, because that doesnt work. :) )

i recently posted this example for pd somewhere... this is how i usually provide arguments to the interns of a patcher... then your abstraction works exactly like most objects do.



Are there changeable Arguments (like you have in a bpatcher) but as an object that you can use more flexible?