Works well here too 
Well done 
Thank you very much !
Getting better and better... However, a few things :
- As i was trying to understand your code, i saw this
var lengthCheck = charFromStart + trackName.lenth
Tell me if i'm wrong, there's a small typo thing i guess...
As i gave back his "g" to trackName.length, now i have this :
And buttons don't update. Seems to be related to var bufferTrackName
- If i don't change 'lenth', then i have this problem :
I think i finally understood this "gif issue" : despite the ".lenth" problem, your code works perfectly... when switching tracks makes the tracknames.length increases. When tracknames.length decreases, articulations won't update. Here, i don't know if it's your code, or my CM... Any idea ?
Again, big thank you
It’s probably my code. I’ll have a look at it over the weekend - it took me ages to figure out how the MCU sends and amends the names and then the logic functions to capture the various permutations- I’ve probably missed a scenario.
This problem is due to how the code re-initialises after you’ve made a change and resaved it while OSC is open. It’s using the undeclared variable text value to add to the string. I’ll work out a way to fix that but in the mean time to “reset” this if you select a track which a name longer then MCU sends them you’ll be back working.
Do you use your track names to find the articulations? If you are check that you’re searching for the right string. MCU sends blank characters or spaces when it want to remove part of the display so for example if you had
“Track 1 is this long now”
Being amended to
“Track 2 is less”
MCU actually sends
“2 is less######”
Where # is a space
Thank you for all these answers
I do use "trackNameJoined" to find articulations. Both tracks and expression maps share the same name.
Looking at your gif the banner at the top seems to update with the correct track name so that suggests that trackNameJoined is building correctly - maybe it’s something in the way the search string works for the articulations?
Well, maybe we have to find a way to get rid of blank spaces returned at the end of trackNameJoined when we're switching to a short-named track.
To display tracknames, i use a text widget and this code from @gcat :
if (trackNameJoined) {receive('/EDIT', 'text_1', {value: trackNameJoined})}
Now, when i switch tracks short name > long name, it returns this :
And when i switch tracks long name > short name :
So we can see here that trackname is ok. But maybe this remaining space causes the bug ?
My plan is to use a map reference in the track name - and search by that - searching by track name will mean a revisit to the custom module every time you add a new track - if you search by map ref then you just need to add this to the rack names when you add a track name.
What do you mean by "revisiting the custom module" ? I'm trying hard, but i really don't understand the difference between searching by trackname vs searching by map ref (are you talking here about the const trackID ?). I'm missing something... somewhere... and can't figure out what it is...
EDIT : ok... finally understood... using tracknames won't be helpfull if i need to have "Guitar Right", "Guitar Left" and so on... got it, make sense now...
try:
trackNameJoined.trim()
1 Like
@gcat : Yeeeeeeeeeeeeeepie Yeaaaaaaaah ! 
As Michael would say: THIS IS IT !
@gcat, @Sub3OneDay : thank you very very very much !
So with this at the beginning of the "building map" part :
const trackID=trackNameJoined.trim();
async function ConstruisTaMap()
{
mesArticulations = []
mesCouleurs = []
{
for(const uneMap of toutesmesMaps)
if(uneMap.includes(trackID))
{
It works...
great! finally!
yesssss
Okayyyyyyy...
So, i changed some little things :
const trackID=trackNameJoined.split('#')[1];
async function ConstruisTaMap()
{
mesArticulations = []
mesCouleurs = []
{
for(const uneMap of toutesmesMaps)
if(uneMap.includes(trackID.trim()))
And now, i can use keywords to select my maps. Got it. I believe... 
1 Like
This is great!
A peculiarity I have noticed is if you have midi tracks - not instrument tracks and the name is shorter that 29 characters you will get (MIDI) sent with the character name.
Here's how to fix that:
var posMidiTag = trackNameJoined.search("\\(M");
var trackNameJoinedTrim = ""
if (posMidiTag > -1) {
trackNameJoinedTrim = trackNameJoined.substring(0, (posMidiTag - 1))
console.log("trackNameJoinedTrim " + trackNameJoinedTrim)
trackNameJoined = trackNameJoinedTrim
}
You need to put it in the function after all the main if statements, and the only limitation is that you can't use (M as a character string in your track names anymore.
Done, thank you !
Well, here is something weird (again ) : switching tracks type comes with a small issue.
Switching from VST tracks to Audio tracks doesn't make any problem (except a small offset on trackname position at first).
Switching from VST / Audio to MIDI : on first selection, trackname appears and disappears...
Switching from MIDI tracks to Audio tracks makes the whole thing looses trackname...
Small little MCU secrets...
Ahh, that’s because I think you need to resend to the MCU in cubase to switch it back to display mode from eq.
send('midi', 'MCU_From_OSC', '/note', 1, 44, 127);
Get the incoming sysex message to console.log to find out what it is then use an if statement to choose to send the command back to cubase. I think that will then also trigger the track name to be resent.
If I’ve got time tomorrow I’ll have a look at it
Not sure, that's already in the CM.
Meanwhile, i made some little changes to go back to HUI, as i had already set the whole Mackie thing in my o-s-c session. So now i can have both articulation stuff and mackie commands / LCD working independently. Question is : will i ever use all of this ?...