EasyMac

Now I know I can send a message out of an outlet of the bpatcher, then route it back as a message in the form of {args $1 $2 $3 ... $n}, but is it possible to have this all happen automatically inside the bpatcher, with no need to do any handling of it in the host patch?

Perhaps some message could be sent to a [thispatcher] inside the bpatcher?

bpatcher-changing-its-own-arguments

you could send a message to the thispatcher of the _parent - and

scriptdelete and recreate the bpatcher from there.

but please use a delay or the second message to recreate it can

but why do you want to reinitialze one objects default arguments-to-patcher

(to save conections to many places where you use them inside?)

you could send a message to the thispatcher of the _parent - and
scriptdelete and recreate the bpatcher from there.

but please use a delay or the second message to recreate it can
no longer be sent. ^^

but why do you want to reinitialze one objects default arguments-to-patcher
anyway?
(to save conections to many places where you use them inside?)

I want to be able to instantiate these objects on the fly, adjust their visible GUI elements and have them be saved in the parent patch as the arguments of each particular instance of the object (where the GUI elements get their initial values).

I'm trying to avoid using pattrs, because it seems like it'll be difficult to make them work in a self-contained way to save the specific values of each instance without any help from me.

If there's some other way to do this easily, I'd be open to this.

I just want a way to keep track of my objects' values in my patches without impeding my workflow.

I'm trying to avoid using pattrs, because it seems like it'll be difficult to make them work in a self-contained way to save the specific values of each instance without any help from me.  

I just want a way to keep track of my objects' values in my patches without impeding my workflow.


ah, i see what you mean: it is too much work to enter arguments to bpatchers

compared to regular object boxes, of course.

depending on what you do with these arguments i would just enter

them from outside. loadbang 1 2 3 4 5 6 7 8 9 and inside the bpatcher

or change your way of working for the creation of bpatchers.

how do you do it currently? step by step, and then make a copy

when i work with many bpatchers i script them.

the basic code is always the same and one could make a simple

textfield where you type the arguments to bpatcher in right before

script-creating it, then it is almost as with other objects.

my "scriptor" abstraction for regular used bpatchers is a bpatcher

itself. it has a menu with all the name in it and selecting one creates

the bpatcher, it couldnt be easier to create something.

ah, i see what you mean: it is too much work to enter arguments to bpatchers
compared to regular object boxes, of course.

depending on what you do with these arguments i would just enter
them from outside. loadbang 1 2 3 4 5 6 7 8 9 and inside the bpatcher
unpack 0 0 0 0 0 0 0 0 0.

or change your way of working for the creation of bpatchers.
how do you do it currently? step by step, and then make a copy
when you need another instance?

when i work with many bpatchers i script them.
the basic code is always the same and one could make a simple
textfield where you type the arguments to bpatcher in right before
script-creating it, then it is almost as with other objects.

my "scriptor" abstraction for regular used bpatchers is a bpatcher
itself. it has a menu with all the name in it and selecting one creates
the bpatcher, it couldnt be easier to create something.

or what about a little pop-up text entry in your

bpatchers GUI? it must not even be graphically

visible.. you click in the right top corder and

something opens where you can enter arguments.

when you close it, they get "load"banged.

they will go to nirvana when you create another

copy of the bpatcher, but as i understand thats

or what about a little pop-up text entry in your
bpatchers GUI? it must not even be graphically
visible.. you click in the right top corder and
something opens where you can enter arguments.

they will go to nirvana when you create another
copy of the bpatcher, but as i understand thats
not a problem in your case.

Yeah, this is not an ideal solution, but it looks to be my best one.

For anyone else looking at this, the solution I went with was embedding the bpatchers in the parent, thus giving each one its own identity and the values can be saved with the parent with the following scheme:

Each UI item's output is connected to the right inlet of a message box, to change the contents with the new value. each of these has a loadbang connected to its left inlet, and the output goes to the UI item. In this way, the values are saved and loaded on patch startup.

Also, the fact that they are separate entities, not linking back to a single external file is not a problem for my purposes. It's basically what I wanted anyway.

Each UI item's output is connected to the right inlet of a message box, to change the contents with the new value.  each of these has a loadbang connected to its left inlet, and the output goes to the UI item.  In this way, the values are saved and loaded on patch startup.

Also, the fact that they are separate entities, not linking back to a single external file is not a problem for my purposes.  It's basically what I wanted anyway.


Hi, EasyMac can you please post your patch? (I should have the same problem to solve).. Thank you so much

Hi, EasyMac can you please post your patch? (I should have the same problem to solve).. Thank you so much
J


If the [bpatchers] are indeed unique by being embedded in the main patcher, you can then use [preset] for all your UI elements and just "store 1" on [closebang], and [loadmess 1] to recover the values. only if the [bpatchers] aren't embedded will you have a shared [preset].

Also you can use [i] or [f] to store the values rather than a message box, apparently this is a bit faster (even if the message boxes are hidden).

Interesting concept, to recall all the states on startup without [pattr], and through many [bpatchers]. I might have it load defaults, but have a button to load the previously-saved settings. Depends on the patch and what you want to do with it.

To enter arguments to a bpatcher on creation, use the @args attribute when creating the bpatcher.

[bpatcher @name my_abstraction @args these are 5 arguments passed]

Ex:
[bpatcher @name my_abstraction @args these are 5 arguments passed]

bpatcher changing its own arguments?