I need one feature, but i guess it’s not implemented. I need ‘S’ node, but when create one more, i need spread as output. Maybe there is trick? I’m looking for an answer for a long time. I invented few tricks for resolve this, but it’s looks awful, not scalable and not useful.
everyoneishappy, you mean, send many different messages via udp/tcp? Looks like nice trick. I thought about it.
But this is not the most elegant solution =) I will try to explain the task.
I have monome’s clone and it’s originally works via osc. And i can’t send many messages, i need to send one bundle for one frame. The result is that I collect through osc messages, and then forwards it through osc again? There is also a problem of synchronization.
upd: I forgot to say the most important thing. I need to store the matrix of values and messages LEDs separately (for example, to blink LEDs with different frequency)
People often equate osc with udp/tcp but keep in mind they are two very different things. Osc is a protocol and udp/tcp is a transport layer. So if you had a message in Greek sent via carrier pigeon, they would be the osc and udp respectively. If you have a look at the OSC avanced help patch for example you’ll see there is no udp in sight.
Without knowing what exactly you want to do in your patch perhaps you could:
Put the full osc bundle into a single S node
use multiple R nodes (all set to the same S)
Parse the osc independently in each spot where it’s needed
If you made a small module wrapping the R node and the osc decode stuff letting you pick which address space to pick up then I think it would stay pretty clean.
Just an idea, I’m sure there are lots of other ways to go about it. What I really hate is when this situation come up with DX Layers.
everyoneishappy, my English is not so good =) I understand the difference, but I never thought in this way. It’s very good idea, i like this. All that you say is correct, although not the solution.
The output of the ‘R’ is not a problem. The problem is to send many different messages (such as "the tenth lamp on / off ') from different parts of the patch, from the different patches, and at different frequency and, most importantly, at the same time. It is important to maintain the logic of the patch is not bogged down in memorizing and patching.
By the way, the problem of the creation of layers of the same kind, and it could be solved with the proposed functional, I think.
ggml, thanks, looks nice. But I need to use 64 different slices while I use dozens of other values. In general, I like the wireless organization in the patch, and then to make the fake from the 64 values need a lot of patching.
ggml, this is an option, but not in the case of my work.
In this example, as a result, a drop-down list (enumeration IOBox at “recive string” inlet of R node) will contain 64 different elements. Also, while all sixty four buttons are used, I do not create new “S” nodes for other purposes - they come into the same range. The indices of the node ‘S’ would solve these problems.
sorry for my English, i can’t explain my mind more clearly.