Hey @dave_dore 
I have one gaping hole in my understanding which is probably going to be a DOH moment when it’s pointed out to me, but while I can see the pressing of Controller Bar buttons creates a result, I cannot work out where to address those buttons via MIDI. I’m not seeing a binding destination. What’s the trick?
And once that is achieved, how would one approach apply a specific CC value to the button? In this case, I’m latching CC94 at these values: 11,22,33,44.
Every press advances and I would like the button text to produce a specific display: 2,4,8,16 in response.
Every push of the hardware button should sync the Controller Bar button accordingly. If I can get my head around the basic approach, I hope I’ll be off and running. Thanks, as ever!
Hi Adrian,
the Controller Bar buttons are, in a sense, “part of the Onscreen keyboard”. In order to make MIDI messages arrive to the button, you have to direct them to the Onscreen Keyboard.
Once you have done that, you can use the value of the CC as shown above by @dave_dore, to produce a caption (even using some logic statement to produce the desired output). See also this thread
Cheers,
Gabriel
Guys, I’ve got this going except for the syntax required to step through the values.
Can you suggest what might be required to have the button text reflect all 4 options?
Hi Adrian,
Can you post the bindings used to send the MIDI messages to the Controller Bar? I’m not sure what you are sending but an example of the syntax would be like below.
$(cc(104) == 0 ? "ONE" : cc(104) == 42 ? "TWO": cc(104) == 83 ? "Three" : cc(104) == 127 ? "Four":"")
This syntax assumes you are sending exact values for each increment of 128 / 3 rounded to the nearest one. You will probably need to fiddle with the TWO and THREE values but this way should work.
Also you don’t need the pop up slider for it to work. If you don’t need it set the button action to No Action.
Dave
Hi Dave,
This is where the latch is established, at the keyboard input 
That is then applied to 4 bindings each of which wraps around the general area of each latch value.
As the first value issued is 11, the first binding is limited from 10-12. The second is limited from 21-23 etc.
I’m not sure why hitting the required value on the nose doesn’t work, but I had to do it this way to get a result at the GX-80
All I’m sending to the Controller Bar is the CC94 latched output. It sees CC94 @11,22,33,44
That works! Great! I can now adapt that to other latched switches.
Just out of interest, where are these codes found in documentation?
Thanks, as ever!
Glad you worked it out Adrian! Here are the main areas of interest regarding the codes and syntax.
Cheers,
Dave
Dave, I did see that info on my previous trawls.
I was thrown by this:
Ternary (aka conditional) operator
<, <=, >, >=, ==, !=
Now I see a familiar code in there, ==, but not specificity as to what it does. That lot is all lumped together. What should I make of it?
Hi Adrian,
The == and != are called equality operators.
== means “equality” or “equal to”, != is “inequality” or “not equal to”.
<, >, <=, and >= are called relational operators.
< means “less than”, <= means “less than or equal to”, >= means “greater than or equal to”, > means “greater than”.
Dave
And this:
is greater than or less than equal to the greatest of the lessor:
Ah yes, the I forgot to include an explanation for the smooth operator … 
I had to fully hijack the thread before Corky did, sorry …
Thanks again!
Some standard fare in there - but some new learnin’. 
On a practical note, it seems that all the coding is placed into that one field. I used Word to put together the longer strings. Would that be a reasonable way to go about construction?
If one is introducing emoji codes and the like, is there a protocol for order of events?
Cheers m’dears.
Yes, I use a text editor
no, just paste the emoji in between the quotes like it was text or mix them in with the text. to open the emojis for Windows hit the Windows key + period key and the selection window will pop up.
I’ve been authoring and maintaining my Controller Bar formulas in a simple text file, edited with Notepad. Here’s an example of one of my Controller Bar buttons:
Mus1
Color: Green
Tip: Mus1
Caption: $(cc(4,16)<1 ? "🟥" : cc(98,16)<63?"L":cc(98,16)>64?"R":"🟢")$(cc(4,16)<1 ? "" : cc(98,16)==0 ? "f" : cc(98,16)==127 ? "t" : cc(98,16)<63 ? formatNumber((63-cc(98,16))*1.5873, "N0") :cc(98,16)>64? formatNumber((cc(98,16)-64)*1.5873, "N0") :"")$("\n")$(cc(5,16)>=104 ? "+": "‒")$(formatNumber(abs(cc(5,16) > 80.5698924731 ? (cc(5,16)*0.25845298751) - 26.8235294118 : (cc(5,16) * cc(5,16) * -0.00588098683) + (cc(5,16) * 1.20611394147) - 65),cc(5,16)<70?"N0":"N1"))$(cc(19,16)<1 ? "\n🟥" : cc(22,16)<1 ? "\n🔷" : "\n🟢")
Action: MIDI Note
Interaction Style: Momentary Button
MIDI Ch / Note: 5 / 2
MIDI Rel / Press Vel.: 0 / 127
Note that the Caption: line is long … and I’ve set Notepad to wrap the lines at 120 characters wide.
This is perhaps the worst way to implement programming - the entire expression crammed together on a single line, with no formatting, indentation, or comments. Unfortunately, if I put the Caption expression on multiple lines, cut-and-paste from Notepad into Cantabile will truncate everything after the first newline.
Improving the interface for Tip and Caption might be a good feature request, but I’m not sure how many folks get really fancy with these fields …
Hi Clint,
Well, having dipped my toe in the water, I can immediately see the value of being able to employ text formatting and have Cantabile deal with it usefully.
It’s quite difficult to keep your eyes from crossing once there’s more than a simple instruction.
Clint, thanks for those codes. I notice that when pasting from Windows Emoji or applying your codes, the result is always grayscale, even though it produces color when pasted into Cantabile. I see a few complaints about this lack of color dotted around the internet. Have you experienced this?
Cheers! 
Rendering of color for Unicode characters depends on a lotta things! The rendering system for Notepad is clearly different from Cantabile, even though they are sitting side-by-side on the same system and screen.
Some of it may be dues to arcane “Variation Selectors” available in Unicode that can specify whether a character is to be rendered graphically or as text.
I’m aware that these issues exist, although I have no clue as to how to predict what might be shown …
“Some Day, this will all be Easy”
Unicode behavior is certainly a little erratic.
I wonder what makes all the Key Cap emojis refuse to play ball, with the exception of 
?
and its other single digit buddies are rendered in Cantabile like this:
while they present well in Word.
Back on the color issue, 
is supposed to have a blue background like this
The only difference is that the duff one is produced by the Microsoft offering and the correct render is produced in the forum’s emoji implementation.
Other transport control type emojis render ok, like Play/Pause⏭.
I don’t get it. 
Hah! While writing this post, both the text editor and the page render to the right showed this without color. After posting, color kicked in.