When selecting multiple clips in consecutive tracks manually there are three ways.
See screengrab:
Track Range Selection Manually 480p.mov (1.97 MiB)
-
Select the topmost clip -> shift + click the track name of the bottommost clip
-
Select the topmost clip -> shift + semicolon down until you reach the bottommost clip
-
Select the topmost clip -> shift + click the bottommost clip -> shift + semicolon down until you reach the bottommost clip
What I would like to do is:
- Select the topmost clip -> shift + cmd + click the track name of the bottommost clip
This should then select the entire range of tracks. Not just add the one on the bottom.
I normally work with the Smart Tool and "Link Track and Edit Selection" on.
So for me it would be only nessesary to work in these cases.
Can anyone help me out with this one?
Christian Scheuer @chrscheuer2020-11-03 17:45:23.518ZHi Jascha,
You can use the action "Select Tracks by Name" in a macro to select specific tracks in SoundFlow. This works in its own way, not using any of the methods you mention in your post, since we're using a method that lends itself better to automation.
Christian Scheuer @chrscheuer2020-11-03 17:46:08.307ZHere's an example:
- Christian Scheuer @chrscheuer2020-11-03 17:47:33.271Z
Perhaps what you need is more of a "please change how Pro Tools works" kind of feature...
In that case, perhaps what you'd need would be a script that selects all tracks between the two outer-most selected tracks.
So, if you have tracks A, B, C, and D, and A and D are selected, the script should ensure B and C are selected, too.
Would that fit better with what you're asking for?- Christian Scheuer @chrscheuer2020-11-03 17:50:46.633Z
This script will select all tracks between (and including) the first and last selected visible track:
let selectedTrackNames = sf.ui.proTools.selectedTrackNames.slice(); //We need at least 2 tracks selected for this function to make sense if (selectedTrackNames.length < 2) throw 0; //Get the first and last names let firstSelectedTrackName = selectedTrackNames[0]; let lastSelectedTrackName = selectedTrackNames.slice(-1)[0]; //Find the visible track indices of first and last selected track let visibleTrackNames = sf.ui.proTools.visibleTrackNames; let firstVisibleIndex = visibleTrackNames.findIndex(n => n === firstSelectedTrackName); let lastVisibleIndex = visibleTrackNames.findIndex(n => n === lastSelectedTrackName); if (firstVisibleIndex < 0 || lastVisibleIndex < 0) throw 'First or last selected track is not visible'; let trackNamesToSelect = visibleTrackNames.slice(firstVisibleIndex, lastVisibleIndex + 1); sf.ui.proTools.trackSelectByName({ names: trackNamesToSelect, });- JJascha Viehl @Jascha_Viehl
Hi Christian,
thanks for the fast response.
You got it right, I want to change the behaviour of Pro Tools there.The script works but extremly slow (see screengrab)
Track Range Selection Script 201103.mov (3.06 MiB)
Action in Pro Tools only starts 20 seconds after I fire the Command on the Stream Deck.
I testet it in a Session with 226 Tracks.
Is there a way of not having to readout all track names, as I understand it does, right?Also, it is very slow when it starts, selecting the tracks one by one.
As it is it would be faster for me doing it manually. Any chance to speed it up?And is there any possiblity of it fireing with cmd + shift + click?
I don't see a mouse trigger.
Can the script always run and wait for this shortcut?- Christian Scheuer @chrscheuer2020-11-04 10:52:47.055Z
Hm, that's odd. It works instantly here...
- Christian Scheuer @chrscheuer2020-11-04 10:56:37.466Z
I've never seen a SoundFlow command work that slowly anywhere. It indicates something else weird is going on.
Perhaps help us by clicking here to send us your log files (best to send right after having used the script):
Please click here to send us the information we needHere's a video of the command working on my end:
It's not possible to overwrite mouse clicks with SoundFlow unfortunately. You could overwrite with the 3rd mouse button, but let's cross that road once we actually have the script working for you.
- JJascha Viehl @Jascha_Viehl
I sent the log file via mail.
I tested the command again in a session containing fewer audio and video files. It is faster there.
In an almost empty session (with still a lot of tracks) it is as fast as in your example.- Christian Scheuer @chrscheuer2020-11-04 11:24:45.829Z
That's very weird. Thank you for the log. Unfortunately, it doesn't reveal anything that could indicate why this would be slow.
My best bet would be that it's simply the CPU being overburdened... What does your Activity Monitor say when you have your large session open?
I have never seen anything run that slow though, so there may still be something else going on that I just can't see from the log.- JJascha Viehl @Jascha_Viehl
There is no CPU spike when the script is running.
Btw. I'm on a Mac Pro 5,1 :
- Christian Scheuer @chrscheuer2020-11-04 13:51:57.616Z
Hm.. Can you try to attach a test session that shows off the behavior?
- JJascha Viehl @Jascha_Viehl
The session contains 40 GB of Video and 15 GB of audio.
But also smaller sessions schow this behaviour, altough not to that extend.I can't share the material, so I would have to create a multiple GB session with test signals (white noise, test tones).
Do you have a session with more material, than in your example where it runs fast?
That might be easier and more realistic.- Christian Scheuer @chrscheuer2020-11-04 18:01:57.315Z
Yes, it runs equally fast in all sessions here. And, as mentioned, I've never seen any SF script run that slow, so there's something really weird going on. The commands I'm showing above are heavily cached and should not be slower due to session size. What I was looking for was more if there's anything in your session's setup that could influence it - not looking for media.
I just took a large session with 220+ GB media and hundreds of tracks - works just a fast as in my video.Note that the actions used above are used in thousands of scripts by SoundFlow users that also don't have these issues. So there is something that's conflicting in your setup. Having a copy of any session where you see this (without media) would be helpful. It may also be a good idea to try to disable other keyboard automation software to see if it may be interfering.
- Christian Scheuer @chrscheuer2020-11-10 18:54:05.868Z
Hi Jascha,
Thank you so much for your session. I was able to reproduce the problem thanks to it!
Here's a script that tries to do the same thing in a little more direct manner:
let selectedTracks = sf.ui.proTools.selectedTrackHeaders; let firstTrack = selectedTracks[0]; let lastTrack = selectedTracks[1]; firstTrack.trackSelect(); lastTrack.titleButton.mouseClickElement({ isShift: true });- Christian Scheuer @chrscheuer2020-11-10 18:58:09.490Z2020-11-10 19:10:59.512Z
It also seems that I can make the original script work better though, through a small change in the session - which can help us narrow down the source issue.
Your session had a lot of AudioSuite plugins open visually at the same time (at least when I opened it here). If you close them all, the behavior much more closely matches what I was seeing in my own tests, where it worked fine.
This actually fits with another observation I've made in the past - namely, that AudioSuite plugins have things going on on the main thread of Pro Tools that slows down Pro Tools' event handling (of user input like keyboard and mouse, and apparently also UI automation events). Totally unrelated to SoundFlow, in the past I've had issues on certain, older computers, where having many AudioSuite plugins open at the same time would mean my automation drawing would be lagging, and sometimes Pro Tools would even skip mouse events.
In this case, it appears, that our call to get the visible tracks was being very slow, due to a large number of calls having to be made to PT on the UI/main thread, which was being partially blocked by all the AudioSuite plugins competing for the same CPU time.
Edit: I called it CPU time, but more likely, it's congestion on the same queue, which Pro Tools apparently is not draining very efficiently. That explains why you're not necessarily seeing it as a spike in the System Usage window or Activity Monitor. So it's still due to the competition of different things having to work on the same thread, but it's not limited by CPU but rather by poor implementation on Avid's side.
- Christian Scheuer @chrscheuer2020-11-10 19:01:11.903Z
And by the way, forgot to mention here - thank you so much for taking the time to make the repro session. This definitely pleases me, that we now have a deeper understanding of potential performance issues and how to mitigate them.
- JJascha Viehl @Jascha_Viehl
Thank you very much for the fix. That is much faster.
I could minimize the open AudioSuite windows a bit but I prefer to leave at least RX 8 Connect, De-click, Mouth De-click open for faster access.
With the new script that is fast enough.