Discuss limitations of bi-directional bindings

The manual states the following:
Bi-directional bindings have certain limitations, including:

  • The source must be a MIDI source (ie: a MIDI input port)
  • The source and target objects must have the same (or similar, see below) name
  • The target must not be a MIDI target
  • Not all MIDI event types are supported. Specifically, events that trigger an action (eg: Controller - Button) are not supported.
  • The source side of the binding must have a specific channel selected (ie: Omni channel bindings aren’t supported)

I am currently battling with sync’ing, what I hoped would be, a simple bi-directional application; to have a button on an X-Touch Mini address the status of a Controller Bar button, while simultaneously switching the Suspend status of a plug in.
Starting with applying the X-Touch to the Suspend. Bi-directional control is not available.
If it were Gain being addressed, no problem. The Cantabile fader flips the XT light, as expected.
I suspect all other issues I have beyond that are due to not quite understanding why one parameter is available and the other not.
I’m ending up with several lines of binding and, invariably, sync issues appear when I’m trying to get plugin suspend, Controller Bar status (including color) and the X-Touch to fully interact.
@Brad, could you help me understand what limits the Controller Bar vs Gain in respect of bi-diectional control?
Thanks as ever!

Hi Ade,

A failed bi-directional binding should show the reason in the binding window.

Probably easiest to send me a screenshot or song/rack of the bindings and I’ll take a look and see if there’s an easier/better way to set it up.

Brad

HI Brad,
I think there may be a few of us who have not delved deeply into the kind of data string required to produce a given result.
Dave Dore has been such an invaluable help when a problem requires a specific understanding of what is, to all intents and purposes, another language. Something that has really just come to light, for me, is the importance of the Onscreen Keyboard (OK from hereon) as a gateway for issuing data via Controller Bar Buttons. I admit, I’m still not completely clear on the need for this intercessionary, if the button itself can perform MIDI duty, but I suspect it will all come clear.

Looking back over previous discussions, I was able to glean enough info to have text switch when applied to a Controller Bar button. Getting that to behave correctly when two sources, a MIDI controller or mouse click, required Dave’s assistance, and the realization that the OK was a vital component. (The uncertainty of guaranteeing enabled/disabled status is a separate conversation.)

I was able to get halfway there from previous forum discussions, and now know:

Input > 1 ? “Lower”:“Upper”

is the syntax required to have the CB button switch text accordingly, but I would have no idea (and maybe still misguided) that the " character tells the program to expect text.
If there is a directory of how all these various species of expression operate, I’ve missed it, and I would really love to know the ins and outs.
I may as well use my current question as the starting point.

The objective is to have a plugin parameter bi-directionally controlled, and simultaneously have that value displayed on a Controller Bar slider, and to have state load also input the parameter value to the X-Touch and the CB slider.
The basic operation was reasonably easy to set up. and an X-Touch mini, a CB slider and the plugin parameter now interact perfectly.
State load is a different matter however.
I would have expected the loading of a state to magically jump the stored value to the X-Touch and CB Slider, after all, moving the plugin parameter does exactly that.
That’s where I tried to see if there was a binding that could issue the parameter value on state load - and hit a brick wall.
I guess I’d like to stop asking questions and just acquire the understanding of what makes this relationship between the various aspects of control tick - beyond the rudimentary.
Thanks for your ear’ole mate. :slight_smile:

Hi @Ade,

Cantabile’s expression engine basically follows the syntax of C/C++/C#/JavaScript type languages and yes, strings (as opposed to variable or function names) are quotes in double quotes.

To break down the above expression:

  • Input > 1 is a conditional expression that evaluates to 1 if the condition is true otherwise 0.

  • The ternary or conditional operator ? and : select a value depending on the left-hand side. The syntax is condition ? trueValue : falseValue. So in the above example if the Input > 1 condition it evaluates to the value after the question mark ?, otherwise the value after the colon :.

There is an expression reference here which is for the lower level expression engine used for gain control curves is basically the same syntax.

This should be possible by having all bindings directly to/from the parameter and not via any intermediate value (this is where sync issues might happen).

With the recent addition of controller bar bindings you shouldn’t need to use the onscreen keyboard at all. This used to be necessary because the only way to control the controller bar was via the on-screen keyboard MIDI device, but that’s no longer the case.

If moving the parameter works then loading a state that adjusts the parameter should also work - unless there’s an issue somewhere. It could be a Cantabile issue, but last time I checked this was working. The other possibility is the plugin isn’t sending a parameter change notification when it should.

Question: if you open the plugin’s parameter editor (right click “Plugin Parameters”) does the parameter slider update when loading the state?

Brad

1 Like

Back when I learned BASIC and COBOL we all believed that programming languages of the future would be readable English. OO languages have blown that out of the water completely. What a ridiculous way to have to code an expression!

Thank you for the explanation, Brad. I would never have grasped that from intuition alone.

1 Like

That does seem more straightforward. @dave_dore provided a solution which required the OK, and it worked.
I’ll certainly have a go at understanding how to apply the syntax and, of course, there’s always the fallback of the forum. It’s not unreasonable that sophisticated functionality requires effort from the end user. Sometimes it’s possible to wrap that into a more accessible format, but given the depth to which these expressions can be applied, I guess the only solution is to RTM and learn.
Thanks Brad

The parameter list does update correctly, so perhaps there is a problem?

Well, not exactly. I used the Onscreen Keyboard (Device) as well. If I am not mistaken the addition of the Onscreen Keyboard as a device was part of bypassing the old MIDI input ports. Is that right @brad ? In this use case the onscreen controller bar button that held the labels also needed to send and retrieve a value so you couldn’t avoid using the MIDI ports for the onscreen keyboard. If there were another way I would like to know how based on what I posted. Thanks. :slight_smile:

Dave

OK. Are you able to put together a simple example that demonstrates the problem? From what you’ve described it sounds like a plugin parameter value is getting changed but a binding from that parameter is not firing - is that correct?

The controller bar buttons are now directly accessible from bindings if you give the button a name (right click button → Customize → Binding Name). This should remove the need to use the onscreen keyboard/MIDI to listen/update controller bar buttons.

DM’d you

Hi Ade,

Thanks for that. Reproduced it and made a fix for the next build.

To explain… the plugin wasn’t firing parameter change notifications when loading the preset/bank, but was firing a display update notification. This was causing the parameter editor to update, but the parameter bindings not to fire.

I’ve made a fix so that whenever programs are loaded, the current parameter set is tracked and the appropriate events raised for any changed parameters.

This will be in the next build.

Also, not that it really matters, but rather than binding MIDI → Controller Bar → Parameter, I’d lean more towards having two direct bidi bindings to the parameter itself.

Brad

1 Like

I did consider either possibility. What I liked about using the CB was that it’s right there at at all times, and whatever gets plumbed into it is reflected at the parameter, with any modifications to the parameter range/curve, etc carried through.
Even if hardware changed, aliases can immediately keep things together, at least in theory.
What would be the advantage of the two direct binding?

Ade

As mentioned, it doesn’t really matter so whichever way works better is fine…

It’s just that the way you have it you’ve got a deeper dependency rather than 2 direct dependencies.