Please help, need spreadable multiple sender

Hi, evvvveryone!

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.

Please help, thanks in advance!

Depending what datatype you need to send, OSC might be an option

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)

Something like this requested earlier:

If the node ‘S’ would be the parameter such as ‘index’, that would be cool. ‘S’ at the same time also could work as ‘cons’.

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.

picture is funny, I laughed, thank you))

depending on how many S you plan to use, you can fake it

R (Value spreadable) (3.6 kB)

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.

not sure what you mean “use 64 different slices while I use dozens of other values”
however, im sure you can paste a 128 slices version in 5 minutes

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.

…is there any news on spreadable S/R nodes?

it would be really handy… i would like it so i can convert my OSC messages and route them internally (all from 1 patch)

…thanks ggml, interesting (…but i need it the other way round)

Maybe this? message

surely wouldn’t be hard using the source from Vux’s Send and Receive Advanced nodes to make a version that served as a solution.

@d0this thanks, hadnt looked at that. bit too much for what i need.

i think i might be on the same page as the original poster so pls see attached. ('cos, as always, a patch is worth a billion words (give or take a few))

…just realised my patch doesnt work properly… but you will get the gist of it