DP 10.01 - Tracks window divider bug

[npj]

Hi all,

Just starting working with DP10.01... Ran into this very unhelpful bug...

Every time I open the Tracks window the divider in the middle of the window moves itself to a position that's most of the way to the left. I'm using the consolidated window.

More detail: If I move the divider where I want it (or trigger my window set to move it)... I then switch to another window (MIDI, Sequence, Mixer, Meter Bridge, etc)... Then I switch back to the Tracks Window - the divider has moved itself further to the left. All I see is the first couple of columns. The track names, comments are all hidden, until I drag it back out to the right again... Hope that makes sense...

This only happens when using the consolidated window. If I pop the Tracks window out of the consolidated window, close it, and reopen it - the divider maintains it's position correctly.

I tested with a new project and it happens there too (with a consolidated window).

Anybody other consolidated window users seeing this behaviour?

Thanks,
Nick.

[MIDI Life Crisis]

I've seen that in 10.0 but haven't needed to worry about it much on the current project since it's for playback to transcribe to notation in Finale. But yes, I have seen that as well.

[npj]

I never saw it in 10.0. I do a lot of of jumping between Tracks and MIDI windows so it's quite a problem for me.

I've seen that in 10.0 but haven't needed to worry about it much on the current project since it's for playback to transcribe to notation in Finale. But yes, I have seen that as well.

[MIDI Life Crisis]

I've not spent a lot of time in DP 10 yet, but I did notice that windows sometimes were a little flaky. I'm not in there enough to decipher it yet. It's only a reference for a larger work on paper. Sorry I can't be more specific.

[magicd]

Hmm. Just tested here. Opened a project, opened the Tracks window in the Consolidated window. Moved the divider bar. Switched to Sequence Editor window. Back to Tracks window. Divider maintains position.

I've set the divider all over and switched between windows and it maintains position.

Can you reproduce this with a new file?

Dave

[bayswater]

I would have noticed this. I'm pretty fussy about the Track Window setup because I can't usually see the tiny text in the column headers. I can't reproduce the problem in 10.0.1.

Even tried unselecting almost everything in the Track List Preferences, and the divider still stays where I put it, even when there is nothing to display on the left.

[cuttime]

I've noticed this as well. It only seems to happen if I'm using a scaled up window. If I use the original default small scaling everything stays in place as expected.

[MIDI Life Crisis]

I've noticed this as well. It only seems to happen if I'm using a scaled up window. If I use the original default small scaling everything stays in place as expected.

Yes! I was also using scaled windows, now that you mention it!

[cuttime]

Yep, the more I mess with it the more annoying it becomes. My current solution is to use a window set with my preferred spacing. It saves that, but there's still an extra key command I have to invoke. I'm reporting this right now.

[npj]

I've noticed this as well. It only seems to happen if I'm using a scaled up window. If I use the original default small scaling everything stays in place as expected.

Yep, I have since discovered this too. I had used the new scaling feature to zoom in a notch or two.

If I reset the scaling, the divider maintains it's position correctly.

I'll have to squint at the smaller text for now... or adjust my display resolution as a temporary fix...

Hopefully 10.02 isn't far away... or maybe we'll get a new build of 10.01...

[npj]

Yep, the more I mess with it the more annoying it becomes. My current solution is to use a window set with my preferred spacing. It saves that, but there's still an extra key command I have to invoke. I'm reporting this right now.

I don't follow... If you reset the scaling that will bypass the bug. You can then trigger window sets and the divider position will be maintained correctly. Why do you need an extra key command?

[cuttime]

Yep, the more I mess with it the more annoying it becomes. My current solution is to use a window set with my preferred spacing. It saves that, but there's still an extra key command I have to invoke. I'm reporting this right now.

I don't follow... If you reset the scaling that will bypass the bug. You can then trigger window sets and the divider position will be maintained correctly. Why do you need an extra key command?

That is, if one prefers to maintain the larger scaling, then the Window Set is the only solution I've found.

[labman]

Oh boy. Every one of our 9.52, or 10.0 files are also now opening with that bug. Fortunately we can reset with our normal window sets. But that tosses the current saved state if differing of course.

Has this been reported in a tech note by anyone? I just did. Join the party.

[cuttime]

Confirmed as a bug by MOTU today.