Message/Variable Args, splitting and [sel]?
I’m sending a message to a subpatch in the following format:
symbol, int, int, [int], [int], [int], [int], [int], [int]
The goal here, in order, is to tell the subpatch to do something based upon the command given (init, create, update, remove, connect), which will then determine what the list of integers to follow will do.
The problem? Well, the # of arguments to take in depend on the command.
Even ignoring this, it seems no matter how I arrange it, the [gate] won’t open for the proper command before the arguments are passed, resulting in improper execution.
Wondering if there’s a better way to do this?
In case anyone’s wondering why I’m doing this… I’m sending the results to a [js] script to dynamically create/remove/connect objects within the subpatch.
Anywho… After attaching bangs to each outlet of the [gate], I found out that it’s opening/closing properly. But the arguments still get "crossed" and I can’t figure out why. A good example of what I mean when I say "crossed", is by switching up the commands and looking at the resulting messages in the subpatch. The arguments "cross over" to the wrong command.
Does this have something to do with [unpack]?
You don’t want select, you want "route", as in:
route init create update remove connect
This will give five outlets each of which will have the relevant information for that particular command.
Only use select when you’re looking for an exact value, or trying to remove a value from a stream (taking output from rightmost outlet)
Thanks for your time!
I changed it to route, and it appears to function exactly the same.
I had [sel] cause I was looking for exact symbols (init create update etc).
If you look at the way I have it patched, the first [route] swaps the elements given via [listfunnel], preserving the contents and placing the symbol (init create etc) to be output first. Then the [sel] opens the gate to whatever command # has been given (numbered 1-5), and is supposed to allow the argument list to pass through to the correct handler.
At first glance, it seems to work properly. But try hitting the init button, then the create button, then the connect button, and you’ll see that the "connect" handler in the subpatch holds the command "connect voice0 3 filter0 0" when it’s supposed to say "connect voice0 0 filter0 0". Then if you click the connect button again, the arguments change to the correct values…
So that means that the arguments are somehow getting crossed.
Here’s an updated patch, describing everything step-by-step:
I just noticed that the arguments which output from [pack] are wrong.
So it must be the way I’m handling it before there?
Fixed it!!
I replaced "[listfunnel] -> [route]" with a "[zl rev] -> [zl ecils 1]", then ran the argument slice (A) through another [zl rev] while the command slice (B) went into the [route init create etc], properly setting off the gate and passing the correct parameters *on the first click* of any sent message.
*PHEW*! =P
Thanks again for your help, Peter.