Super cables

2 nodes: a send super cable and a receive super cable.

The role of the super cable is to allow the user to use a unique variable name: “foobar” so that all downstream “foobar” variables automatically connect together. Similar to spooky send and receive but an exact replication as opposed to connecting cables and then hiding. Very useful for use in subcompositions when you want to allow copies of nodes to access same data.

Obviously the super cable has to know not to connect 2 cables to 1 input- so only outputs can stream to multiple inputs. User would be warned not to proceed- (like feedback warning)

A simpler logic would be only 1 sender per variable name is allowed within a composition. While unlimited receivers are allowed.

I’ve opened this feature request for community voting.

there are definitely situations where you want to have multiple sender nodes sharing a channel using momentary pulses to send for example hit interrupts to other instances or iterations of a sub composition. speaking from experience in QC using Spooky patches.

I suppose @useful_design that that implementation would work with a “Fire Event” however I don’t think it would work with values. I think that it would work programmatically with values- however I suppose there would be no way to work out from our end when the variable was being updated.

I think @smokris is the best to comment - If it can be done he will let us know! But great addition @useful_design! I hope that gets put into this request if possible.

If the node is “generic” enabled then I suppose that if it was in “Fire Event” type then it could be allowed to spawn multiple instances.

Can’t you use lists and make a “multiplex” node? It will be with cables, but it should be a “cleaner” option for now. Make a new node with an “add to list” node, publish as many inputs you need/want, and publish the list output. Then make a deplex node to pick out the values and insert it in the nodes you need the data.

(I get the idea by the way, Reaktor Core uses something like that and it is convenient).

@MartinusMagneson,

Are you talking about a standard multiplexer - demultiplexer?

It currently couldn’t be list in list as that hasn’t been implemented yet.

What is the imagined UI for this functionality?

One version of this is a ‘Broadcast’ and ‘Receive’ Node.

Another would be right-clicking on a port, and choosing a ‘Broadcast Value’ option, ‘Listen for Value’ or similar.

It might look something like this:

Here’a another take, where it takes the form of compact node.

I like this version more, because it means there could be a node for ‘broadcast’ and ‘receive’ (or ‘listen’) that makes it easier for new users to discover.
However, when attached, this becomes one of these compact nodes, which is neater. I’d propose making the compact Send/Receive show the right-click menu on regular click as well.

This functionality can also be made available on right-click of a port, where the user can select correctly-typed variables. This would be the faster way to access this functionality.

In the case this order of flow produces an error, then it would be nice for the UI to prompt to insert Spin Off node. Or at least offer that helpful tip.

 

I like the idea of showing the variable name. As it would be confusing otherwise.

Dunno if it’s trying to pack too much into a port however. As we also need to be able to set the value type.

But that would be a question to Team Vuo.