fabio m

looking for showing the playhead position in minutes and seconds outside Live (Android tablet + TouchOSC) I found the Time Display 1.0 object that is perfect... almost. The format it shows is: 

 and I would like to strip away the hours - first three characters and the ":" , and the milliseconds, last three and the [:] before, so I opened the device in Max editor and in the end I managed to open the "soubroutine" called "Time" in which I tried to add a regexp filtering like this: "regexp .*[:](.*) with no luck: any help?

In the Time patcher I added an udpsend to broadcast the time through OSC. The sending works and I can get the time into my TouchOSC layout but I'd like to strip away the outer characters. 

I would also like not to send OSC data continuosly but only when the last message is different then the previous one.

Another thing is that when I try to open the "Time" patcher window with "Original" nothing happens and I have to use the "New window" instead. Now I have a few small windows floating around and I don't know how to turn them off.

I watched many videos and read many papers and downloaded a lot of examples or snippets but I couldn't find a solution that works.

Any good link about M4L programming and tutorials?

Hi,
looking for showing the playhead position in minutes and seconds outside Live (Android tablet + TouchOSC) I found the Time Display 1.0 object that is perfect... almost. The format it shows is: hhh:mm:ss:msmsms and I would like to strip away the hours - first three characters and the ":" , and the milliseconds, last three and the [:] before, so I opened the device in Max editor and in the end I managed to open the "soubroutine" called "Time" in which I tried to add a regexp filtering like this: "regexp .*[:](.*) with no luck: any help?

In the Time patcher I added an udpsend to broadcast the time through OSC. The sending works and I can get the time into my TouchOSC layout but I'd like to strip away the outer characters. 
I would also like not to send OSC data continuosly but only when the last message is different then the previous one.

Any good link about M4L programming and tutorials?
Thanks.
fabio

Hi,
looking for showing the playhead position in minutes and seconds outside Live (Android tablet + TouchOSC) I found the Time Display 1.0 o

two-problems-getting-a-subset-of-a-string-and-can't-close-panels-window

upload the patch, otherwise one can't understand what that original

it should be possibe to output time without hours and ms in first place,

than add zl change to send only when seconds progress. 

image.png

we route items 2 & 3 from the HH:MM:SS.MS list

If that timer patch is programmed correctly, there should be no need for zl.change,

but I would not expect it to be the case.

P.S. if I remember correctly , Live is not capable to report real time

correctly, if there are any tempo changes involved.

upload the patch, otherwise one can't understand what that original
or new  floating windows are...
it should be possibe to output time without hours and ms in first place,
without a need for regexp.
than add zl change to send only when seconds progress. 
------
otherwise try this


regexp outputs only numeric items,
we route items 2 & 3 from the HH:MM:SS.MS list
to sprintf to form MM:SS messages.
If that timer patch is programmed correctly, there should be no need for zl.change,
but I would not expect it to be the case.

P.S. if I remember correctly , Live is not capable to report real time
correctly, if there are any tempo changes involved.



Thank you for taking the time to reply to my post and try to help me.

Before I go on to other things, let me share the patch so you see what is like.

Now let me ask a little question on a thing that's bugging me a little, please.

Yesterday, every time I wanted to edit the popup window I had to choose "new window" because "original" was not available or it didn't work. Now, when Max is opened I'm left with all the popups, and I can't see how I can get rid of them: any help on this too, please?

Many windows.jpg

About the way to get only h:mm:ss I tried your suggestion but it didn't work.

After a few trial and error, and a lot of frustration with Max documentation - both the help and the reference show quite a few things but explain very little and there is almost no CLEAR examples of how to setup a function to work, I managed to make it work almost perfectly. Here is how I did it, taking into account that I needed to send all the values as a single string, in order for a label into a TouchOSC to show the time correctly.

Here is the working snippet (with some "probes" to see what's gettin along the signal path):

Works.jpg

And here's the TouchOSC lay out (sorry for the quality of the picture...) output:

Lay out.jpeg

Now I would like to format minutes and seconds so that they always show two digit values: where should I look?

And what if I would like to filter the millisecond to show only values at half a second (.0 or .5)?

Yesterday, every time I wanted to edit the popup window I had to choose "new window" because "original" was not available or it didn't work. Now, when Max is opened I'm left with all the popups,  and I can't see how I can get rid of them: any help on this too, please?

@source audio
About the way to get only h:mm:ss I tried your suggestion but it didn't work.
After a few trial and error, and a lot of frustration with Max documentation - both the help and the reference show quite a few things but explain very little and there is almost no CLEAR examples of how to setup a function to work, I managed to make it work almost perfectly. Here is how I did it, taking into account that I needed to send all the values as a single string, in order for a label into a TouchOSC to show the time correctly.

1- you did not use sprintf as on the screenshot.

3 - you messed with the patcher and added it again to parent patch,

Best would be to trash that device and start from scratch.

simpler way to get real time is get_current_song_time

or use ms and do the math using plain max objects.

Did I understand that correctly - you wrote

you don't need to display anything in Live, only send time to OSC.

1- you did not use sprintf as on the screenshot.
2- you stated you only want mm:ss ?
3 - you messed with the patcher and added it again to parent patch,
and have now duplicates of it.

Best would be to trash that device and start from scratch.
simpler way to get real time is get_current_song_time
or plugsync~ 
and translate ticks to HH:MM:SS
then regexp and sprintf
or use ms and do the math using plain max objects.

Did I understand that correctly - you wrote
you want ms to dislay as .0 or .5
that is what it would look like:
02:33.0
02:33.5
02:34.0
02:34.5
etc


you don't need to display anything in Live, only send time to OSC.
Can be all done with only few objects.



Time-OSC.amxd

I gave your hint another look and of course it works.

What was putting me off was that you wrote " we route items 2 & 3 ..." so I thought that the box where I saw "$2 $3" had to be a "route" instead of a standard message, even if I couldn't see the "route" word in your screen. But I thought that that didn't mean to be sintatically 100% respondent to the real objects. In fact, in the "zl change" box I can't see the dot between the two words but I learned that it is needed in the real one.

Yes, but along the way I thought that it would be better to show a single hour field too, just in case I would have to work with videos. I modified your patch consequently.

Forum hint 1 working.jpg

Here you are right again. In my frustration of not being able to open the popup window in edit mode, I tried things without knowing what I was doing... Now, how do I delete that tab in the parent window?

Yes, you got it right. It's a minor thing but I think that on the tablet layout it would feel better seeing that the time changes more frequently than once a second but not as fast as once every tenth of a second. Think of it as a sort of a "blinking led" telling you that te transport in running.

To do it easily I would need a sort of a "round for defect" function where I can define 0.5 as the weight of the rounding process...

Thank you very much, that's much simpler. I made a little adaptation to show the single hour digit and gere it is:

Time-OSC mod.amxd

I gave your hint  another look and of course it works.
What was putting me off was that you wrote " we route items 2 & 3 ..." so I thought that the box where I saw "$2 $3" had to be a "route" instead of a standard message, even if I couldn't see the "route" word in your screen. But I thought that that didn't mean to be sintatically 100% respondent to the real objects. In fact, in the "zl change" box I can't see the dot between the two words but I learned that it is needed in the real one.

3 - you messed with the patcher and added it again to parent patch,
and have now duplicates of it.

Here you are right again. In my frustration of not being able to open the popup window in edit mode, I tried things without knowing what I was doing...  Now, how do I delete that tab in the parent window?

Did I understand that correctly - you wrote
you want ms to dislay as .0 or .5
that is what it would look like:
02:33.0
02:33.5
02:34.0
02:34.5
etc

Yes, you got it right. It's a minor thing but I think that on the tablet layout it would feel better seeing that the time changes more frequently than once a second but not as fast as once every tenth of a second. Think of it as a sort of a "blinking led" telling you that te transport in running.
To do it easily I would need a sort of a "round for defect" function where I can define 0.5 as the weight of the rounding process...

you don't need to display anything in Live, only send time to OSC.
Can be all done with only few objects.
...
here one example using plugsync~

Thank you very much, that's much simpler. I made a little adaptation to show the single hour digit and gere it is:


Thank you again and have a nice day.
fabio

glad it worked for you, and that you got rid of that complicated device.

sprintf needs %02d etc only to add leading zeros,

if you prefer to have separation arround :

then comment would be better as it ignores quotas

touchOSC also ignores them, at least the old version

just a little hint :
sprintf needs %02d etc only to add leading zeros,
for single digit %d or %i is ok.
and 
if you leave space between HH: and MM
you get quotas at output


sprintf symout %d:%02d:%02d.%d
would produce


if you prefer to have separation arround :
then comment would be better as it ignores quotas


Thank you very much again for your explanation. That is gold for my attitude: "while you are at something, try to learn something general and not just how to solve your little need of the moment".

Going back to the OSC sending to TouchOSC (Mk1), to do it in Live I'm using the Live connection kit Max device "OSC Send" or the "Live Grabber sender", but with both I can't map directly to them the tracks ARM buttons. Searching around I found an M4L device called "Arm 8 tracks" that let me map the track ARM buttons to its buttons, which are mappable to the OSC senders. 

Now that I learned how to send to OSC directly from within a patch, I'm trying to mod the Arm 8 tracks putting directly into it's patch the sending functions via OSC. Here it is, with my modding in blu background.

The string I need to send should have this format: 

In my mod it should be in a form like this: 

For now I've "hard coded" them in the patcher but If it's not too time consuming to learn, I'd like to be able to get the address from a global list stored somewhere, or better a table or a db where each record have at least 3 fields: track number, track name, OSC address. 

In that way I should be able to get the track number and/or the OSC address knowing its track name (or even better, selecting it from a list), with some sort of a look up. In that way I would be sure to use the same track info across all the patches.

Where do you think I can I get the track number in that patch? And how?

As you can see, on the first track I "probed" some outlets to see what and when I am receiving and I see that in the leftmost "probe", the last piece of info it is the track number minus 1 (the list starts from 0).

Can you think of a way to get the track name?

Do you think it is better to use a single udpsend box as I did ( in fact, I used two of them) instead of having one for each button? 

Performancewise it seems to me that clicking on one of the buttons of the patcher, both in Max editor and in Live object, I get a faster feedback on TouchOSC than when I click directly on the arm button of a track: in the code, do you see any room for improvement on this?

Do you have an Idea on how to build that "global db" of tracks info and values?

Going back to the OSC sending to TouchOSC (Mk1), to do it in Live I'm using the Live connection kit Max device "OSC Send" or the "Live Grabber sender", but with both I can't map directly to them the tracks ARM buttons. Searching around I found an  M4L device called "Arm 8 tracks" that let me map the track ARM buttons to its buttons, which are mappable to the OSC senders. 
Now that I learned how to send to OSC directly from within a patch, I'm trying to mod the Arm 8 tracks putting directly into it's patch the sending functions via OSC.  Here it is, with my modding in blu background.


I have some questions, though.
The string I need to send should have this format:  OSC address | arm status (0/1)
In my mod it should be in a form like this:  /ViviARM 1 (when armed) and this:  /ViviARM 0 (when unarmed) 
For now I've "hard coded" them in the patcher but If it's not too time consuming to learn, I'd like to be able to get the address from a global list stored somewhere, or better a table or a db where each record have at least 3 fields: track number, track name, OSC address. 
In that way I should be able to get the track number and/or the OSC address knowing its track name (or even better, selecting it from a list), with some sort of a look up. In that way I would be sure to use the same track info across all the patches.
Now the questions:

1  
Where do you think I can I get the track number in that patch? And how?
As you can see, on the first track I "probed" some outlets to see what and when I am receiving and I see that in the leftmost "probe", the last piece of info it is the track number minus 1 (the list starts from 0).
Can you think of a way to get the track name?

2
Do you think it is better to use a single udpsend box as I did ( in fact, I used two of them) instead of having one for each button? 

3
Performancewise it seems to me that clicking on one of the buttons of the patcher, both in Max editor and in Live object, I get a faster feedback on TouchOSC than when I click directly on the arm button of a track: in the code, do you see any room for improvement on this?

4
Do you have an Idea on how to build that "global db" of tracks info and values?

I realized that I would need to be able to set an offset in seconds to compensate the gap between the projet start time (1.1.1) and the song start time (usually 12 seconds from 1.1.1.).

We need to subtract the offset time before the number gets unpacked and, if I understood correctly the top part of your patch, we have 640 tick per second : am I right ?

I thought that I should at first convert the offset seconds into ticks (offset seconds x 640) and then subtract the resulting ticks from the number before the translation into four pieces, so I thought to use an expression box like this: "expr $f1 - 640 * Sf2" where $f1 is the time in ticks and Sf2 is the offset time, in seconds.

Trouble is that, as you can see in the patch, if I use the $f2 operator the box doesn't evaluate the expression but if I put the seconds number directly into the expr box like this: "expr Sf1 - 640 * 12", it gets evaluated! I would like to understand why it works like that because I will need to "present" the offset field into Live so I need the $f2 version to works.

A useful thing would be to be able to programmatically get the time value of a locator named "Start", as I always have one at the exact beginning of the song. In that way I could use the Start time to set the offset device even if I move the locator around.

I'm really puzzled about the behaviour of the expr box... I'm curious to see what I'm doing wrong...

I realized that I would need to be able to set an offset in seconds to compensate the gap between the projet start time (1.1.1) and the song start time (usually 12 seconds from 1.1.1.).
We need to subtract the offset time before the number gets unpacked and, if I understood correctly the top part of your patch, we have 640 tick per second : am I right ?


I thought that I should at first convert the offset seconds into ticks (offset seconds x 640) and then subtract the resulting ticks from the number before the translation into four pieces, so I thought to use an expression box like this:  "expr $f1 - 640 * Sf2" where $f1 is the time in ticks and Sf2 is the offset time, in seconds.
Trouble is that, as you can see in the patch,  if I use the $f2 operator the box doesn't evaluate the expression but if I put the seconds number directly into the expr box like this:  "expr Sf1 - 640 * 12", it gets evaluated! I would like to understand why it works like that because I will need to "present" the offset field into Live so I need the $f2 version to works.

A useful thing would be to be able to programmatically get the time value of a locator named "Start", as I always have one at the exact beginning of the song.  In that way I could use the Start time to set the offset device even if I move the locator around.

Thank you.
PS.
I'm really puzzled about the behaviour of the expr box... I'm curious to see what I'm doing wrong...

I don't use Live, find it a crap and have no interest at all in it.

Only reason I ever come in touch with it is to help

For that reason I am wrong person to ask about armed tracks and the rest of it.

But once asked, I would say try to use only 1 Live device,

like that time display device and also use it to control arm state of that 8 tracks.

Make your life easier and place that 8 tracks to track slots 1 - 8

so you don't need to detect anything but talk plain text to tracks and touchOSC.

I have this idea that live set is static set for stage use or ? 

issuing track names and get/set their armed state should be easy thing to do in a single device

in case you insist on using names and placing tracks in any order,

but you need a good strategy - is TouchOSC in control of armed states ?

is song auto-arming the tracks in first place ?

single udpsend is a better choice, one can also control order and flow, speed etc of sent messages.

I see you used 192.168.0.255 - trying to broadcast ?

sorry I got this with IP wrong, a mistake - was a part of some other patch

plugsync~ outputs raw ticks in relation 1. = 480 ticks or 1 quarter note.

I don't know what that 640 you mention represents.

To be able to programm offset, you will need time signature

translated to ticks & multiplied by number of bars to offset.

Live has it with bars : beats : units and not real time, so I guess your offset is in bars.

plugsync has time signature outlet as list, unpack and

let's say TS is 7/8, 1/ 8 = 0.5 raw ticks (1. / 8 * 4)

if you want to offset 6 bars then multiply 3.5 * 6 = 21.

insert - 21. in rawticks output before * 480.

But if you want real time offset, like 12 seconds,

then you need to translate 12000 ms to ticks

60000 / 110 = 545.4545454545 = 1 quarter note length in ms

now 12000 / 545.4545454545 = 20 which is your offset in Live's

here a little presentation of both offset types

Screen shot 2022-08-03 at 10.28.05 AM.png

I don't use Live, find it a crap and have no interest at all in it.
Only reason I ever come in touch with it is to help
some students and customers.
For that reason I am wrong person to ask about armed tracks and the rest of it.
But once asked, I would say try to use only 1 Live device,
like that time display device and also use it to control arm state of that 8 tracks.
Make your life easier and place that 8 tracks to track slots 1 - 8
so you don't need to detect anything but talk plain text to tracks and touchOSC.
I have this idea that live set is static set for stage use or ? 
issuing track names and get/set their armed state should be easy thing to do in a single device
in case you insist on using names and placing tracks in any order,
but then have fun with it....
but you need a good strategy - is TouchOSC in control of armed states ?
is song auto-arming the tracks in first place ?

single udpsend is a better choice, one can also control order and flow, speed etc of sent messages.
I see you used 192.168.0.255 - trying to broadcast ?
instead of 192.168.0.99 ?
sometimes, broadcasting has speed issues
sorry I got this with IP wrong, a mistake - was a part of some other patch
------
To the offset :
plugsync~ outputs raw ticks in relation 1. = 480 ticks or 1 quarter note.
I don't know what that 640 you mention represents.
To be able to programm offset, you will need time signature
translated to ticks & multiplied by number of bars to offset.
than insert (- that much) in ticks flow.
Live has it with bars : beats : units and not real time, so I guess your offset is in bars.

plugsync has time signature outlet as list, unpack and
you multiply number of beats with beat (expr 1. / $f1 * 4)
let's say TS is 7/8,  1/ 8 = 0.5 raw ticks  (1. / 8 * 4)
7 * 0.5 = 3.5   = bar length in raw ticks.
if you want to offset 6 bars then multiply 3.5 * 6 = 21.
insert - 21. in rawticks output before * 480.

All clear ? 
---------
But if you want real time offset, like 12 seconds,
then you need to translate 12000 ms to ticks
in tempo xy
let's take tempo 110.
60000 / 110 = 545.4545454545 = 1 quarter note length in ms
now 12000 / 545.4545454545 = 20 which is your offset in Live's
representation of raw ticks.
here a little presentation of both offset types


P.S. I forgot to answer about "Start" locator.

It is possible to extract it's position, which is expressed in elapsed quarter notes.

in bar 6/8 and locator placed at bar 11, it will mean 3 * 10 = 30 quarter notes

It makes me wonder why you use realtime, and not bars and beats, which seem to be the only Live native time measuring units ...

It is possible to extract it's position, which is expressed in elapsed quarter notes.
in bar 6/8 and locator placed at bar 11, it will mean 3 * 10 = 30 quarter notes

It makes me wonder why you use realtime, and not bars and beats, which seem to be the only Live native time measuring units ...

Hi, ant thank you again for the time you are spending in helping me to solve my little problems and, above all, to learn new things.

No, there is no auto-arming. I'm just building a remote control for the most common needs while tracking.

Yes, in my TouchOSC layout I can control the ARM states sending a midi cc message to Live where in a Clyphx User settings file I put the scripts and they are triggered by the midi cc message coming in.

Some scripts are as simple as "track/Mute" or "track/ARM" but you can get a very good control of the most part of Live objects. Unfortunately Live "per se" doesn't give a lot of feedback directly and that is where OSC is unvaluable. Without that I couldn't get the state af the Mute or Arm buttons so I had to always check the PC window to be sure things were as expected and so I had to use two buttons for each function: "Mute on" and "Mute off", "Arm on" and "Arm off". But that was far from ideal so, thanks to OSC and to Max that let us use it within Live.

I'm relying heavily on track names because Clyphx let you use them as target of a few commands without being tied to the track position and without having to remember the position number.

But as my tracks are always in the same positions inside the patchers I can easily use the numbers.

I must search how are numbered the return tracks though...

Well, not really but I was considering that I could go with the offset indication made of beats or bars instead of realtime because my "Start" locator sits always on a line between bars or beats so I could use those values to define it. In any case, thanks to your new Time-OSC with automatic offset calculation I won't need to manually set a value for that.

So let me thank you very much again for that little gem. I will keep it like it is.

I need to show the playhead/cursor position in realtime because who sings, usually could have put on the lyrics some comments and some marks with the running time indication because they were listening with a player that gave only runtime values.

So, in these last few days, mainly for your help and your work I made giant steps on the path of building my remote control. Should you ever come to northern Italy send me a message and I'll be glad to take you to some nice place (my wife is from Bellagio... The real one, not the fake Vegas one...).

There is still one thing for what I couldn'f find a solutionand not even any info:

getting the state of the global recording or of the recording button

Now when I hit the "rec" button on my layout I have to check the tiny button on the PC window to be sure that recording in ON.

After hours of serching I'm still left with empty hands...

Hi, ant thank you again for the time you are spending in helping me to solve my little problems and, above all,  to learn new things.

but you need a good strategy - is TouchOSC in control of armed states ?
is song auto-arming the tracks in first place ?

Yes, in my TouchOSC layout I can control the ARM states sending a midi cc message to Live where in a Clyphx User settings file I put the scripts and they are triggered by the midi cc message coming in.
Some scripts are as simple as "track/Mute" or "track/ARM" but you can get a very good control of the most part of Live objects. Unfortunately Live "per se" doesn't give a lot of feedback directly and that is where OSC is unvaluable. Without that I couldn't get the state af the Mute or Arm buttons so I had to always check the PC window to be sure things were as expected and so I had to use two buttons for each function: "Mute on" and "Mute off", "Arm on" and "Arm off". But that was far from ideal so, thanks to OSC and to Max that let us use it within Live.

About track names vs track numbers
I'm relying heavily on track names because Clyphx let you use them as target of a few commands without being tied to the track position and without having to remember the position number.
But as my tracks are always in the same positions inside the patchers I can easily use the numbers.
I must search how are numbered the return tracks though...

About the offset

............ 
if you want to offset 6 bars then multiply 3.5 * 6 = 21.  
insert - 21. in rawticks output before * 480.   All clear ?

Well, not really but I was considering that I could go with the offset indication made of beats or bars instead of realtime because my "Start" locator sits always on a line between bars or beats so I could use those values to define it. In any case,   thanks to your new Time-OSC with automatic offset calculation I won't need to manually set a value for that.
So let me thank you very much again for that little gem. I will keep it like it is.

So, in these last few days, mainly for your help and your work I made giant steps on the path of building my remote control. Should you ever come to northern Italy send me a message and I'll be glad to take you to some nice place (my wife is from Bellagio... The real one, not the fake Vegas one...).

There is still one thing for what I couldn'f find a solutionand not even any info:
- getting the state of the global recording or of the recording button
Now when I hit the "rec" button on my layout I have to check the tiny button on the PC window to be sure that recording in ON.
After hours of serching I'm still left with empty hands...

For the feedback of muting and arming through OSC, I ended up modding the "Arm 8 tracks" patch.

Here is the one for the muting of the first 16 tracks:

Mute 16 Tracks 1-16 1.0.amxd

Arm 8 Tracks 1.0.amxd

For now I kept them as they were, with the interactive buttons, even if I'm not using them. I will think if it's better to remove everything but what is needed to send the status via OSC.

Now I need to understand how to apply the same functions to the return tracks...

For the feedback of muting and arming through OSC, I ended up modding the "Arm 8 tracks" patch.
Here is the one for the muting of the first 16 tracks:

For now I kept them as they were, with the interactive buttons, even if I'm not using them. I will think if it's better to remove everything but what is needed to send the status via OSC.
Maybe I will make that version too.

After some further research I managed to get the status of the global recording. In fact it's as easy as reading a property of the live_set class.

RecONoff.mp4

There is still one thing for what I couldn'f find a solutionand not even any info:
- getting the state of the global recording or of the recording button

After some further research I managed to get the status of the global recording. In fact it's as easy as reading a property of the live_set class.


that looks more complicated than I thought.

That arm and mute devices you posted have no idea what track names are.

track has slot number which is human visible by looking at the track activator number.

If you want to report arm state of the track named Guitar, you need it's id

which will remain same if you move the track to different slot.

So what is your link between track name and it's slot number and report of the arm or mute state ?

In order to do something like that, one has to build a list of track names and their id's

and to monitor them for any changes, and keep their states linked to what ?

what I am trying to say, either one builds remote control which is completely flexible,

which means it reflects complete Live set state,

or one uses fixed setup with set tracks, devices etc and programs static efficient control.

I am not sure to understand exactly what your concept is.

If you send arm and mute state of first 16 tracks to

touchosc, that will allways be related to track numbers, not names.

Here one option would be to check states of 16 tracks every time

that looks more complicated than I thought.
That arm and mute devices you posted have no idea what track names are.

track has slot number which is human visible by looking at the track activator number.
Track id has nothing to do with that.
If you want to report arm state of the track named Guitar,  you need it's id
which will remain same if you move the track to different slot.
So what is your link between track name and it's slot number and report of the arm or mute state ?
I don't see it.
In order to do something like that, one has to build a list of track names and their id's
and to monitor them for any changes, and keep their states linked to what ?
what I am trying to say, either one builds remote control which is completely flexible,
which means it reflects complete Live set state,
or one uses fixed setup with set tracks, devices etc and programs static efficient control.
I am not sure to understand exactly what your concept is.
If you send arm and mute state of first 16 tracks to
touchosc, that will allways be related to track numbers, not names.

Here one option would be to check states of 16 tracks every time
that Clyphx executes any script.
like this



-----

you can use return_tracks instead of tracks to get their ids, states etc.



That is the primary goal but to do that one must have a good knowledge of how to do it.

A few days ago I knew almost nothing about how to do it and it's only thanks to your patient help that I'm starting to understand something.

Time ago I decided in favour of a static template with the same tracks in the same positions to get a link between names and numbers. But sometimes I found it useful to be free to add or remove a track - even only temporarily, and that would break the link between name and number from that track on to the right of the set.

Now, as you say that the ID stays the same even if you move the track and I don't know nothing about how ID assignement work, let me ask you a couple of questions, please. 

Should I add a new audio track in position 5 and rename it to "Guitar", it will be given a certain ID:

1 - If I delete the track, save and close Live, reopen it and create the same track in the same position, will it get the same ID as before?

2 - And what if I create it in a different position but with the same name?

The answers to these two questions are key for the route I will decide to follow for the further development of my remote so forgive me if for now I send my reply even if it doesn't cover the rest of your post.

OK: inside the children "return_tracks", are they enumerated with numbers or letters?

one builds remote control which is completely flexible,

Two problems: getting a subset of a string and can't close panels window