[done 2.5] Parameter Cross-track Routing

I propose this method of parameter routing.

Mockups:
or

As you can see there is little T button in the destination row. The button when pressed displays a little menu (similar to Renoise menubar menus) with list of tracks with devices on them and a selection “Current” which is checked by default. When the “Current” is selected the devices behave like before. When the T is set to something else than Current you can choose destination device from the selected track and the button changes colour to indicate that the device destination is routed to another channel.

The little button implementation derives from the fact that the other two destination parameters are ALWAYS obligatory. The device doesn’t do anything unless both of them are set. The track destination doesn’t need to be set as it defaults to current track. We can consider this to be exception when it is routed to other track, and thus the destination track selector doesn’t have to be displayed as prominently.

When track is routed the button changes colour:

Benefits of this implementation:

  1. The little T button saves space and is not as intrusive on normal use (destination is on the same track)
  2. Having the destination track selection in the same device, as opposed to having it in specialized “Cross Track Routing Device” saves lots of rack space when you want to send to multiple devices with hydra.

Issues: Small T button doesn’t make it very clear on glance where the destination goes.

The purpose and uses for cross-track parameter routing doesn’t need any explanation, does it?

Perhaps it could be displayed “greyed out” where the destinations on the same track are normally displayed?

not bad of an idea. :)

I like this idea too, a big +1 from me :)

IMO cross-track routing is breaking the nice encapsulation of fxs per track - it can be a nasty spaghetti track creator. But I guess for future cross-track functionalities (like sidechaining), we’ll need it. So if we need it, we’ll have to do it proper to control the spaghetti :). I think Suva’s idea is quite good but only explaining the outgoing side of the routing. On the incoming side, to prevent f.e. clicking all tracks to determine who is changing your flying slider, we’ll need something like an source device. So sending parameter changes to other tracks can be done with this “bridge” only:
A: you place the destination device in the controlling track - copying any settable effect value from other effects.
B: you place the source device in the controlled track and let it control any other parameter.

But instead of the lit up T, when you change it to another track perhaps it should change to that track number, so at a quick glance you can see where you’re linking to.

Maybe also on that track that you’re linking to, the DSP effect can change in color or have something that notifies you that something is linked from another channel to it (to prevent you from deleting that DSP in the future).

another dream which became true with Renoise 2.5