Hi there, when using Cubase 13 midi editor new track visibility selector on the left, when i double click the name of the track (to solo select the track and all its events), the timeline/screen position automatically moves to the first relevant event of that track, which most of the time is not helpful as I have scroll back to the original spot. This happens as well as I check (tick) the track as well - the movement seems to be pretty random. Is there a setting somewhere to turn to auto scroll off?
Many thanks in advance.
1 Like
Thank you for posting this. IT’S DRIVING ME NUTS.
I really hope they fix this as it is really limiting the usefulness of the feature.
Thanks @madfloyd , it’s clearly a bug that severely reduces the usability of the new track visibility feature which is one of the heavily advertised features in C13. @Martin.Jirsak and Cubase team, are you able to response to this please?
1 Like
@Credole Try this and tell me what you experience:
- ensure all the tracks that you want to edit are in the same folder
Does the bug still occur?
For me, it was happening when I unchecked a track but I now notice it only seems to happen if that track is NOT in the same folder as my other tracks.
Thanks @madfloyd , saving in the same folder doesn’t always work for me unfortunately as not all tracks are in same folder logistically.
Paging @Martin.Jirsak and Cubase team, the latest up doesn’t correct this - perhaps a response on your plan to navigate this bug?
Hi,
This happens if no MIDI Part is selected. If you have any MIDI Part (of the given MIDI Track) selected, then the focus jumps to the selected MIDI Part.
Thanks Martin, the focus indeed jumped to the early part of the last selected midi track, which is not always (in my case never) the intended purposes. For example, if I first selected a violin track in bar 30, then select a viola track to view its harmony to the violin part in the same bar 30, the midi roll will moved to bar 5 because there’s an earlier part of the viola track. I then have to scroll all the way back to bar 30. Is there a way to deactivate this auto adjust to last selected midi part?
Hi,
There is a small trick to press the F key (Auto-Scroll) twice. Then the view jumps to the Cursor position.
Thanks Martin. The F key is handy - but you would need to make sure the cursor is indeed in the right position to begin with. Added with another step to enter F, this creates a total of 2 additional steps just to view more tracks, very awkward and goes again the original intent to improving workflow.
The ever shifting starting point forces me to abandon the visibiliy function altogether and use the old way to alternatiing between project window and piano roll. The Cubase team should seriously look at fixing this - or at least allow deactivating auto-positioning the start point based on the early events of the last selected track. I am curious of the basis of deciding this auto positioning - was it a feature request? There are other DAWs that does this smoothly for the longest time without this presumption (eg, Studio One).
Hi,
How should Cubase know then, which part of the project do you want to see, please?
Like most composers, the focus point is naturally on midi event that I double clicked on the project window to bring out the midi editor. This is the workflow is most composers, as demonstrated in their youtube live sessions.
But that is not the main point - Perhaps the question to you and team is: of all the many events selected in the track visibility in various order, why is Cubase presuming that the focus point should be moved to the early part of last selected track? Also, the same group of tracks can be selected in various orders, and the auto focus point will then be different even for this same group of tracks. Solution is simple - provide a choice of deactivating this auto focus based on some random last selected track.
2 Likes
Hi,
First of all, this is not a MIDI Event, this is a MIDI Part.
Second, Cubase works like this, if any MIDI Part is selected. We are talking about the scenario, if no MIDI Part is selected in the given MIDI track.
Martin.Jirsak:
“First of all, this is not a MIDI Event, this is a MIDI Part.”
Happy to stand corrected on this technicality - but, with respect, I don’t think what name Midi event or part is being called is acutely pertinent to the request that we are discussing here.
Martin.Jirsak:
“Second, Cubase works like this, if any MIDI Part is selected. We are talking about the scenario, if no MIDI Part is selected in the given MIDI track…”
We are talking about a new feature that is introduced i.e. the new visibility editor- With respect, it is not helpful to mention that Cubase works like this or like that. Cubase 12 and below doesn’t have track visibility feature on the side bar. Users toggle back and forth between Project Window and midi editor - this feature is introduced and it touted to speed up the workflow. New feature entails new capability, workflow and new issues - and hence being open to feedback is crucial. In my humble opinion, this is something where a solution is needed.
With respect, the pertinent question remains unanswered - i.e. with the newly introduced visibility editor, the same group of tracks can be selected/checked in various orders, and the auto focus point will likely be very different evenfor this same group of tracks.
Also, we are not only talking about the scenario where no midi part is selected. You can select 3 midi parts, but as soon you select the another midi track in the visibiliy editor, the focus point will move to the early part of the last midi track.
Hi,
You are absolutely correct. I just try to keep the correct terminology, so the community can understand each other better.
Again, I agree with you. But the scenario, you are talking about is, there is no MIDI Part selected. So the argument that Cubase should show the Selected MIDI Part data is not valid. Therefore I was asking, how should Cubase distinguish, which MIDI Part to show (if you ask it just: show me the MIDI track data), please?
Thanks Martin, I have attached a simple example Cubase project file with 3 tracks to demonstrate the point (with some random midi data in each track):
Double click the last Midi part of track 3 to open the midi editor. The midi editor will start at bar 33 because this is where this midi part starts. In the midi visibility list, then select/check track 2 - the midi editor automatically moves its starting point to bar 25 as that’s where the last midi part of track 2. Depending on the resolution of your midi editor, having the starting point moved to bar 25 might render bar 33 out of sight in your midi editor. Going by the same logic, depending on the resolution of your midi editor, the start point may start moving around once you select more and more tracks, depending on whether the last midi part is already in sight in the current midi editor. The final start point will eventually be based on the last track you’ve selected - this may vary for the same group of tracks, depending on the order you select the track.
Test C13.cpr (238.3 KB)
Hi @Martin.Jirsak , just following up if there’s any solution on this?
Hi,
Could you please make a video screen recording with your screen resolution?
Thanks Martin. Yes - screen resolution of course will make a difference - make it small enough on a 4K screen, most likely the starting position won’t change as the screen has enough capacity captured all selected tracks length. My intent was to state that everyone’s screen resolution is different, also everyone will zoom different on different track, further affecting this setting. The ask is for Cubase to stop deciding for me which track to jump to the start in any resolution. I don’t want the screen to move in whichever zoom or 4K screen. If there is a way to deactivate this Cubase making decision for me - that will be great. However, I suspect this decision by Cubase is already baked in, and it’s hard to untangle.
Hi,
This is, how is the function designed at the moment. The view jumps to the beginning of the shown MIDI Part.
The trick I’m using is to press the F key twice to jump to the cursor position.
Thanks Martin. I really hope Steinberg fixes this in an update, have to press alot of double Fs to always get back to the position I wanted (am also need to remember to insert the cursor in correct position in the first place so that double Fs could get back to it). I am sure this is a common hassle for everyone using this and detracts the good work done by Steinberg on the visibility editor.