Focused and selected

Sioux

I create a new discussion to avoid the "build 40 script isn't firing" one .
I'm sorry if some of my words are wrong : I can understand and speak English , but it is not my native language.
As you said, "selected" is the track that has white box around. Only one track can be selected at a time
But with build 28 and before I believe that "focused" is the track that is highlighted in red. So you can focus more than one track at a time and then, select another one !

So let me explain briefly how i use Mobius
I was a RC 600 user the RC 600 was driven by a midi player on my PC (sending PC and CC to RC600 and over pedals and Beatbuddy to configure them for each song ) I was in a French Facebook group about RC600 and they told me I was an expert as I helped a lot of users to correctly use it. I made docs, videos, as I thought that 90% of the musicians used it at 10% of its potential
But my pedalboard was so big and so heavy , and I was frustrated that the RC 600 couldn't do everything I wanted to
(for exemple record 2 tracks at trhe same time) Then I discovered Mobius (Thank you so much again !!!)

So I decided to put everything on my PC : I am still using my Midi player that sends PC and CC to a VST host (BC Patchwork) . In Patchwork, there is a channel for the guitar patches, another for the vocal patches , another for the audio backing tracks and each channel is sent to Mobius (using 3 Tracks : guitars , Vocals and Backing tracks)

And it works pretty fine with build 28 : I'm using only 8 scripts : Some of them can be converted from mos to msl , but I was unable to convert the others in msl . This is an hybrid situation : -) but I built more tha, 250 very small midi files to perform live all the the songs I can perform, changing guitar patches during the song , looping the vocals, and so on.

Of course , to upgrade to build 41 or 42, I can rewrite those scripts , but I don't want to modify my 250 midi files !
So, here is my problem : In the beginning, I wrote a Recplay script to emulate the RC 600. And I can trigger it 4 different ways .

Here are my midi bindings :

Recplay 6:CC72 scope Global
Recplay 6: CC94 scope 1
Recplay 6:CC93 scope 2
Recplay 6:CC101 scope 3
And here is the Recplay.mos script
!focuslock
if mode = reset
record
elseif mode = play
overdub
else
play
endif
end

Of course I can re-write it in msl but the behaviour is not the same especially with build 41,42 ...

What the global "Recplay" does :
If no track is focused (in red), It wil be sent to the selected track.
But if one or more tracks are focused, the script will run in those tracks AND the selected track ,if different.
So that I can record mutitiple tracks at the same time
That's why I think that the "Goblal" property in build 28 is not the same as the "Focused" property in build 42
If I upgrade to 42 , because of the !focuslock , nothing happens if no track is focused (highlighted in red)

And if I delete this line it cannot record multiple tracks !
Of course I could rewrite multiples scripts :
1 to record track 1+2
1 to record track 1+3
1 to record 2+3
etc..
But my midi files would have to be modified :-(

I experiment other problems with "set bindings" no longer working even in mos !
Thank you so much for reading and helping me !

jeff

Ah, I see. What you are using is called "focus lock". So yes, you can cause other tracks besides the one with the white box around it to be focused. The way this works changed, and it broke MOS scripts I'm working on a fix for that. I also fixed "set bindings". You won't need to modify any of the midi files.

I'm traveling for the holidays right now so I won't have another build out until the middle of next week.

Sioux

Well ! I thought I became senile when I read your first answer :-) :-)
Nothing urgent for me , build 28 is very fine and it's enough . But I would like to run the new build and convert everything in msl
Thanks again !
Have a great vacation !

alexs1

Just to be clear, there is no #focuslock for scripts in build 42?

jeff

That is correct, I just added that a few days ago and it will be in build 43, along with a bunch of other changes related to bindings.

The MSL directive is #focused. This means "replicate this script for each of the possible destination tracks".

What "each of the possible" means will depend on the binding. If you set "Send To" (formerly Scope) in the binding to "Focused" this means the Active Track (white border) plus any other tracks that have Focus Lock turned on. If Send To is set to a group name, it will be replicated for each member of that group. There is also a new binding option SendTo=Active which means only the Active Track ignoring focus lock.

I agonized over the name of this (yes, I really did) because "focus" has become a fuzzy term that seems synonymous with "focus lock" but for scripts it really isn't. Fasten your seatbelts folks, because this is going to be another Typical Jeff Explanation....

From a script's perspective (talking MSL here, MOS is different), it isn't really running "in" a track. It runs in this amorphous "supervisory" space that exists above tracks and doesn't even have to do anything related to tracks. It can turn the transport on and off, twiddle things in the UI, load files. Scripts are are really always "global" and can touch any part of the application. When a script wants to do something to a particular track it can use the "in" statement to send things to tracks. When you think of a script running, don't think of it "running in a track" think of it "sending things to a track". They're more like the UI or parameter automation in the host.

But scripts don't always have to use in to send something to a track . When a script is launched it is given the number of the track that is active at that moment, so when it sees "Record" or some other function that needs to be sent to a track, and it isn't wrapped in an in statement, it will send it to that default track. Focus Lock isn't a concept for the script itself. But the script can choose to use focus lock by saying "in focused Mute" which means "send a Mute to every track that has focus lock turned on.

This is a little different than how MOS worked, and it does mean that scripts do not behave exactly the same as the built-in functions like Record and Overdub which really are "in" the track. There are cases though where you would like scripts to behave just like a normal Function that only operates on one track at a time. This makes them feel more natural when using Focus Lock and Group Bindings. In those cases the script can be replicated so that there are several copies of it, each one with a different default track number.

So...from a scripts perspective it is saying "I support replication" rather than "I support focus lock" since focus lock is just one mechanism that can cause replication. But no one wants to type #replicatable so I settled on #focused as in "this script is focused on one thing" rather than being unfocused and needing to touch everything.

It can't be prevented, but it is a best practice that if a script says it is #focused then it should not use "in" to touch other tracks since that kind of violates the meaning of #focused.

alexs1

jeff

I think I get it. Does #focused exclusively "send to" tracks with Focus Lock active then? Or will it behave the same as .mos !focuslock where it runs on the selected track when no tracks are Focus Locked? Basically, would a #focused script behave effectively the same as a default Button Function would in the UI?

jeff

alexs1 In a binding SendTo=Focused means the Active Track plus any others that have Focus Lock. It will always at minimum send to the Active Track with the white border around it.

The reason SendTo=Active was added is because by default all track-level functions were paying attention to Focus Lock.
There was no way to say I want Mute or Stop to use Focus Lock but not Record. I started down that road by adding function-specific options which were in the Configuration->Options table in a long column of Focus/Group checkboxes for every function. But abandoned that because it's much easier to deal with that in the binding, similar to the parameter overrides we were talking about.

jeff

Here are a few examples that may help show the consequences of #focused. Assume that track 1 is Active (white border) and tracks 2 and 3 have Focus Lock enabled.

  Mute

This will send Mute to track 1 only. I'll explain why this is the default in a minute.

  in focused Mute

This will send Mute to tracks 1, 2, and 3.

#focused
Mute

This will send Mute to tracks 1, 2, and 3. The difference between this and the previous example is that there are actually three copies of the script running. Each script is only sending to one track, but there are 3 of them pointed to different tracks.

Most of the time you can get the same behavior you get from #focused just by wrapping this around your script:

in focused {

     ...whatever the script does...

}

This results in slightly less overhead since we're not needing to create and manage three different instances of the script. But that overhead usually isn't noticeable.

The reason #focused is not on by default is this:

LoadSnapshot("someName")

LoadSnapshot is not a track-specific function. It reads potentially many files and does a lot of work in mrmory, then distributes the results to the tracks. If you did this:

#focused
LoadSnapshot("someName")

You would end up loading the snapshot 3 times, twice redundantly. It is because scripts can always contain a mixture of global and track-specific functions that the default is not to be #focused.

There is one case where using #focused would normally be required, it is any script that uses a wait. Consider this:

in 1,2,3 {wait loop Mute}

in is an iterator. It loops over the tracks in the list and does the things inside the {} block for each track. The first thing is "wait loop" which means to wait until the playback of this loop reaches the end. Then when that finishes, it does Mute. The important thing here is that track 2 won't be processed until track 1 finishes. While we're doing that "wait loop" for track 1, track 2 is still alive and moving, and it may have actually reached it's end first. When we finish with track 1 and move to track 2, we'll wait again before moving on to track 3, and and on. in works sequentially or in series not in parallel.

What you usually want in this situation is to have independent "wait loop"s for each of the tracks so they
Mute as soon as they reach their endpoint without waiting for any of the other tracks. To do that
you have to use what programmers think of as concurrent threads. And that is essentially what #focused does:

#focused
wait loop Mute

Note though that the decision about which tracks to do this to has moved out of the script and into
the binding using Focus Lock or Groups. There is currently no way to start parallel threads inside a script,
it has to be done from the outside with binding replication. There will be ways to address this in the future.

alexs1

jeff

That explanation helps, thanks. My application is for a controller with 8 triggers, each of which Focus/Unfocus Lock an individual track. Then, I have some scripts I want to run while x tracks are focused. #focused is what I think I’m looking for here, right? Or would “in focused” work the same with less overhead?

Sioux

Hi everyone !
I have just upgraded to build 43.
-set bindings seems to work fine !
-But .. Some srcipts do not behave the same as in build 28
When a track is in stop mode and not empty , this .mos script

!focuslock
if mode = reset
record
elseif mode = play
overdub
else
play
endif
end

doesn't work the same .In build 28, it used to play the track , In build 43 it records the track ...

But l have fixed it using the msl

#focused
if mode == :reset
Record
else if mode == :play
Overdub
else if mode == :pause
Play
else
Play
end if
end

But this very simple script

Track 3
focuslock
Track 1
focuslock

does not work anymore (It used to set focus to track 1 and 3 then use the focused tracks in another script)
focuslock is really not the same as !focuslock
Perhaps it is very simple but i can't find how to rewrite it in msl ...
Is there an issue ?

Thanks again.

jeff

Gak, I hate "mode". Let me see what went wrong there, but it is related to difference between major and minor modes and what is displayed in the UI. What the actual value of "mode" is in a script isn't necessarily the same as what you see in the UI for .mos scripts. I tried to fix that in MSL but didn't think about MOS. I'll try to make MOS and MSL behave the same.

For this one:

Track 3
focuslock
Track 1
focuslock

Change focuslock to FocusLock

Function names are case sensitive.

I'm actually having a debate with myself right now about case sensitivity. The good news is, I'm winning.

For those that care, what are your opinions about case sensitivity. I like it because it helps reinforce the convention of function names being capitalized and parameter names being lowercase so you can more easily understand what the various names in a script are. But it's so easy to misspell something that way and the script breaks. This is especially true when testing string variables like "mode" which I get wrong all the time....Is it "if mode == :Pause" or "if mode == :pause" ?

The problem with case insensitivity is that once you open that door, you can't close it later, and I'm worried about the future.

alexs1

jeff For those that care, what are your opinions about case sensitivity.

What about keeping the door open and adding specific case-sensitivity warnings in the editor log?

Sioux

Oh, sorry I could have found this by myself ... but I didn't . FocusLock (and not focuslock) works pretty fine !
And now, I am able to keep build 43, everything seems to work.
I'm still keeping .mos scripts because of "set bindings" for example.
But I think in the future everything will be in ".msl" (?)
Thanks again !

jeff

Sioux

Good to hear. Starting in b43 it is now possible to change binding sets in MSL scripts.
Instead of this in MOS:

set bindings  xyz

You would do:

ActivateBindings("xyz")

Sioux

Cool ! Thank you !
I had a last (?) problem with this .mos script

globalreset
set bindings "CC113 Global"
Track 3

because "globalreset" in a script doesn't work fine with b43 (But it works with the button)

I was just trying to convert in msl but I did not find "ActivateBindings" !!

Now that I know, I wrote in msl
GlobalReset
SelectTrack (3)
ActivateBindings "CC113 Global"

And everything is OK !!!
Thanks again !

jeff

GlobalReset must now be written with capitalization, MOS may have allowed that in lower case but the function moved out of MOS so it needs a G and an R.

When in doubt, always capitalize the first letter of a function name, and if it has two words pushed together like GlobalReset, AutoRecord, FocusLock, etc. capitalize each word.

In MSL most functions require that you have ( ) around the things you are passing to the function. So: ActivateBindings("CC113 Global")

I'm in the process of changing this so that if a function only takes one argument the ( ) are optional. Some functions allow that but not all of them, so if something isn't working, add ( ) around the arguments and it may fix it.

Sioux

Of course, it works, now ! And I have converted every . mos in . msl !!!
Thanks again !

dani

How is the current method to read if a track is currently focused?
I have an old .mos script, where I used focus, but that does not seem to work anymore. Has the syntax changed for this?
Also, is there a way to monitor, which track is currently 'FocusLock'ed (similar to EventScripts?)

jeff

If you want to test whether a track has Focus Lock turned on, the name is now "focusLock" rather than just "focus".

If you want to test whether the track is the active/selected track, use....well, that seems to be broken in MOS.

In MSL it is "isActive" as in:

if isActive print("This track" trackNumber " is active")

Most of the time you don't need to test this because the default context for the script always is the active track.

Just in case there are other MOS bugs here, post the script you're using and I'll test it.

dani

Thank you! My use-case for monitoring isActive and focusLock is to have a midi-feedback for my controller - so I can see on which track a function will take effect. Currently my best solution was to rewrite every function which changes focusLock and is Active to give immediate feedback. Is there a possibility to always have a script active which is monitoring those variables continously and allowing to create a midi-out in case of a change, similar to the event scripts?