Pressing the “Move Up More” / “Move Down More” buttons on the transpose palette move the selected notes by 12 lanes rather than 12 semitones. So, if some lanes are hidden (e.g. filtered to the selected scale, as in the image below) the notes will be transposed more than one octave.
I can confirm this. The red Notes became the green ones after transposing.
Can you mark this post with an issue tag.
Added to the Issues Wiki.
I’m checking this out but I can’t manage to reproduce the issue. What did you do exactly ? What are the exact steps and scale assistant settings ?
Ouuuu, was not expecting a pop quiz today.
However after playing with this a bit more to make the pictures, I think (set your cliche detectors off) this really is more of a feature than a bug.
This behavior lets us “transpose” (not sure of the proper word for this) between modes of the scale. In the example we go from C Major to A Minor. But if instead of going up +12 it had been +1 then it would have become D Dorian, +2 E Phrygian, +3 F Lydian, etc.
Also the names of Transpose Palette buttons are Up and Up More not up a half-step or up an octave so it makes sense that the unit of movement is whatever you are currently seeing. Both the Logical Editor and the Key Commands to go up and down by octaves work as expected.
I’d never seen much use for making only the scale steps visible before since it would mostly confuse me having multiple layouts. Plus many times accidentally dragging a note onto the ‘wrong’ pitch ends up sounding real interesting (always listen to your mistakes before correcting them) - and scale filtering kinda gets rid of that possibility. But this is pretty intriguing. And what about the more exotic scales…?
Must sound like some light jazz 
Okay I see it now, the Transpose Palette in the Editor makes the notes to move by 1 or 12 lines when we are in the scale view. It doesn’t take the note pitch into consideration for the octave transpose.
For me this is a bug. Even if we are in the scale view, transposing C3 up an octave should result in C4, and not A4, even if the jump is only 7 lines on the grid. This really is a coding issue, well no, it isn’t really one, but maybe they just preferred coding it the most easiest way so the transpose buttons act like 1 or 12 steps jump on the grid instead of considering the notes values. That’s really lazy of them…
Because the function itself is not an octave transpose - it isn’t even named that. Lot’s of things in Cubase are context sensitive. Seems this is too. Under any circumstances the issue has been flagged and the devs can sort out their intentions for this if they are so inclined.
Actually the key command (Shift+Up/Down) is moving the notes by one octave, so is this a design flaw or a real coding issue ?
The user manual clearly states how the Transpose buttons are supposed to operate :
Clearly a coding issue to me.
“This has not been developed”, as they will say.
If the code is working fine for the key commands, then why can’t they just copy it for these buttons ?
Fixing this would take a few minutes, literally.
The way I see it, the button’s job was to move the event 12 notches up. But with pitch visibility, it still moves the event by 12 (currently visible) notches. So… from a lawyer’s point of view, it still works. 
Unless I am missing something here, I am wondering why it is different code in the first place…
But yes, seems to me like that transpose button works by counting twelve “lines” on the grid, and then later on when the pitch visibility agent was introduced, it was forgotten to update the code. Definitely a bug.
We can’t know for sure how it works, we’re just speculating based on our expectations. I too agree that the button should always transpose an octave up or down. By introducing the pitch visibility agent, a “new” situation was encountered, where the hidden “data” (pitches of the keyboard on the left), should be count as data even when hidden. I see how this is easy to NOT foresee, especially when up to that moment there wasn’t a need to handle a subset of the pitches. All pitches were always present, so it was safe to assume the button would transpose 12 “entries of the pitch list” up or down. But now, with pitch visibility, it needs to be done differently. (For example if each pitch had its own note number as a primary key, we could still use that for visibility purposes and transposition. It’s very possible that this seemingly logical solution would create problems that I haven’t foreseen yet. )
