Using sprintf for multiple outlets in a Bpatcher
I'm trying to make an abstracted UI object in a bpatcher where one argument is the number of outlets. Since these will be created upon its instantiation, they also need to be addressed individually, so they're assigned scripting names as they're created.
Where I'm getting hung up is: using sprintf to try to send a message to any of these outlets. All I need is to send a bang through one of the outlets at random, but I'm getting an error message 'outlet does not understand "bang"' or 'outlet does not understand "int"', when I've tried using a 1 instead. I'm not sure what's causing this, since in my other experience, [outlet] generally just passes anything it receives.
As far as I can tell, sprintf is my best bet here bc it gives me the flexibility to create and address any number of outlets. Why doesn't sprintf want to let me send data to outlets?
two examples attached that recreate the error: one bpatcher, and one higher-level UI patcher.
i havent look at the patch, but it should not matter at all where a message is coming from and, as you say, outlet should forward "bang" fine as it does not have any own commands.
are you using "messages to max" with those named outlets? or why are they named?
you know that you can script-create connections to those outlets on init, too, just like creating them?
not using messages to max, using [sprintf script send...] to thispatcher.
I suspect the output of sprintf is somehow getting turned into something other than what it looks like..!
use [printit] to check if your messages are right.
i use [list] to collect data for script commands and similar things (i.e. sprintf or regexp only where needed and before the list object), so that you first layout the structure of the command.
as first your scripting is wrong,
because you create outlets after loading bpatcher,
and so 5 bang objects have no connection
Outlet object is not made to be addressed by messages but with wired stuff.
you will have to output that messages using something else,
there are too many options to mention all here.
best is to first patch it for a normal abstraction to see how and if it works (see "st.ools" for the possibly oldest example of abstractions with a dynamic number of outlets), and then try to load the result in a bpatcher object and see if it work there as well.
one may never forget that a bpatcher patcher is not a subpatcher but only pretends to be one.
there are various little differences that can appear between initialising something inside or in conjunction with a bpatcher as opposed to a regular patch.
I once did an abstraction with customizable number of outlets.
The best approach is probably to have the maximum number of outlets already created in your base patch, and then delete the ones not required at initialization. This way you also preserve connections when deleting-recreating the object.
The [jit.gl.textmult] abstraction works this way for its inlets, except that all the scripting is done in javascript.