Plugin Pin Connector

[Justinmac84]

Hi,

We've already spoken about this too but just thought I'd file it officially. Is there some way, either by talking to Cockos or something you can do on Osara's end, to make access to channel routing for effects plug-ins less laborious.

Right now you have to open and close the context menu every time you want to enable or disable a channel send or receive. It must take significantly longer than it takes sighted people and is easy to make mistakes.

Something like a tree view would be ideal, with collapsable channels and the ability to check and uncheck the ones you do and don't want.

Thanks a lot,

Justin

[jcsteh]

Can't see any current way to do this with the REAPER API, so this would definitely require some change from Cockos, whether that be fixing the accessibility of the dialog (preferred) or API to allow us to create our own.

[RDMurray]

Would it be feasible for Cockos to allow space to check/uncheck items in the menu without the menu closing? I haven't seen this anywhere else even though it would be useful, so I suppose it must be difficult or impossible.

I think there is enough API support for this now, but it would be a lot of work for minimal benefit.

[jcsteh]

Would it be feasible for Cockos to allow space to check/uncheck items in the menu without the menu closing?

These are Win32 menus and I'm pretty certain that as soon as you activate an item, it dismisses the menu with no way to prevent that.

[jcsteh]

I'm not sure whether this was added since this issue was filed or whether I just missed it, but either way, there is API to do this now (Take/TrackFX_GetIOSize, Take/TrackFX_Get/SetPinMappings, Take/TrackFX_GetNamedConfigParm in/out_pin_x).

Now that we have send/receive channels in the Track Parameters dialog, I was considering exposing input/output pins in a similar way in the FX Parameters dialog. However, it's possible to map the same pin to multiple channels and that doesn't fit well in that dialog.

The question is: how often do users map the same pin to multiple channels? I'm inclined to just not support it, but that obviously isn't going to work if it's a non-0 use case. I'm struggling to see a use case for it that isn't extremely obscure.

[ranetto]

Hi, it might often be useful to map to multiple channels when you want to put two different effects on a guitar, for example to distort a guitar with nativeinstruments or amplitube, or if you want an effect to be monitored on one out and not on a different out . The pins would be very useful as they allow us to exploit the multi-channeling of reaper. They can also often be used to combine multiple synthesizers into the same sound to magnify pads or octave strings.

[jcsteh]

Two different effects mapping to the same channel is fine. The question is about mapping the same pin on the same effect to multiple channels; e.g. mapping output pin 1 to channels 1 and 2. If that's something that is needed, then we won't be able to support this in the Parameters dialog.

[ranetto]

I don't think it's useful very often, one of the cases in which it could be useful is for example if we want to have an adaptation plugin for monitor speakers or headphones that travel on different channels with which to associate the various outputs or a plugin to ensure that all the levels are same on different pairs of speakers but it doesn't seem that important to me at the moment.

[Aleskis]

James, as you suggest, we could start with the most common use case, which would be integrated into the current simplified settings dialog. This would make 90% of the manipulations easier.

[jcsteh]

The thing to understand is that implementing support for plugin pins in the Parameters dialog is going to be a fair amount of work. If we go down this path, we most likely will not be able to support assigning a single pin to multiple channels. I don't want to do all of the work and then discover that there is a significant requirement to support assigning a single pin to multiple channels because that's going to mean starting from scratch with a completely different design and thus a lot of wasted work.

[Aleskis]

If, at a later date, you need to undo everything to add the sending of several channels to a single one, I mean if the old work can't be reused at all for merging to the new interface, then, indeed, it's a big risk and in that case you might as well start straight away on a new interface. However, I can't immediately see a scenario where I'd need to send 1-2 to 3 from another plugin. So, if the workload involved in creating a new interface is such that it takes several months to integrate this new possibility, I'm not sure it's worth it. Ultimately, it's a calculation that includes the time spent coding either option A in the current interface, VS option B in a new interface, bearing in mind that option A could be obsolete within a few months. In this case, how much cumulative time does it take to work on option A and its update, VS how much time does it take to work on option B. Sorry, this is almost philosophical...