Tony: a tool for melody transcription

Made a few changes. As of 378028e6765f we should have the behaviour I described above.

One remaining problem (this is a problem in DAW software etc as well) is how to handle play head tracking during playback.

Usually, you want the program to track the play head -- that is, if you're playing the file and the play head goes off the right edge of the window, you want the window to flip across to follow it so you can see what's playing.

But this isn't universally true. If, while the file is playing, you drag the pane so as to look at a different part of the file, you don't want the program to keep trying to pull you back to where the playhead is while you're dragging.

(Previous SV/Tony code avoided this problem by simply having the playhead always move with you when you drag the pane.)

I've handled this for now by having Tony stop tracking the pointer if you drag away while playback is happening. Then if the pointer happens to wander back into the window area, it starts tracking again.

But it still tracks the pointer if you drag away while playback is not happening -- so you can't currently go and inspect a different area of the file (leaving the play head behind) while playback is stopped, and then play from the play head location while continuing to look at the other bit of the file -- because when you hit play, the view will jump to the play head.

Sometimes that's annoying, and I have a suspicion the use case that Justin was explaining on our phone call the other day might have been one case where you don't want that to happen.

On the other hand, sometimes it's what you want and the opposite behaviour would be annoying. So I'm not sure whether to try to do anything else about that.

Anyway please test this revision and let me know how you find the current behaviour.

Re playhead position as start of selection: sounds intuitive to me. That is: for keyboard based selection, I guess.

But it still tracks the pointer if you drag away while playback is not happening -- so you can't currently go and inspect a different area of the file (leaving the play head behind) while playback is stopped, and then play from the play head location while continuing to look at the other bit of the file -- because when you hit play, the view will jump to the play head.

Sometimes that's annoying, and I have a suspicion the use case that Justin was explaining on our phone call the other day might have been one case where you don't want that to happen.

Hm, we would have to see. The behaviour has changed so much otherwise that we could maybe defer the investigation of the annoyingness to version 1.5. Shall we?

Anyway please test this revision and let me know how you find the current behaviour.

Will do, pulling now.

Well, it seems to work.

I had been thinking of a different kind of change in which you do not control panning directly, but only through the movement of the play head.
That is: using the left and right key would change the playhead, and if the playhead gets to the edge of the visible area it pans. In analogy to up/down movement in mainstream text editors. To me, that would be most natural. I'd be quite happy to have panning control only via the overview.

Ah, so you're primarily navigating using the keyboard?

Then I think your problem is that left and right cursors are bound to "scroll left" and "scroll right" actions rather than to "move playhead left" and "move playhead right", which I think would do what you want?

That is, assuming you want left and right cursor to move the play position even during playback.

Is that the same as what Ctrl+left/right do now? I guess not, because you want them to work even if there are no notes. And perhaps you want them to go at a fixed "speed" rather than (effectively) faster or slower depending on how long the notes are.

You'd better confirm whether that's what you want, before I try to implement it. I almost universally navigate by dragging the main pane with the mouse (or touchscreen), rather than using the keyboard, so I'm not totally clear on how keyboard interactions should best work.

[edited to clarify]

Chris Cannam wrote:

Ah, so you're primarily navigating using the keyboard?

I probably have to admit to that. Sorry for actually noticing late that we were thinking of different things.

Then I think your problem is that left and right cursors are bound to "scroll left" and "scroll right" actions rather than to "move playhead left" and "move playhead right", which I think would do what you want?

I think that's exactly right.

That is, assuming you want left and right cursor to move the play position even during playback.

I think it'd be rare for me to want to look at something completely different to what's playing, so I guess I'd want either

• exactly what you said (left/right curser moves playhead even during playback) or
• left/right curser does nothing during playback

You'd better confirm whether that's what you want, before I try to implement it. I almost universally navigate by dragging the main pane with the mouse, rather than using the keyboard, so I'm not totally clear on how keyboard interactions should best work.

Well, I have not been able to think through chess-master-style what the changes might lead to in terms of other interactions, but my impression is: yeah, that's what I want.

OK. I think I added another question back there, while you were typing:

Is that the same as what Ctrl+left/right do now? I guess not, because you want them to work even if there are no notes. And perhaps you want them to go at a fixed "speed" rather than (effectively) faster or slower depending on how long the notes are.

And:

Sorry for actually noticing late that we were thinking of different things.

That's quite OK -- I'm pretty sure that this change was necessary and that it corresponds with much of what we discussed on the phone. You're not actually asking for something different, you're just asking for something additional.

Chris Cannam wrote:

OK. I think I added another question back there, while you were typing:

Is that the same as what Ctrl+left/right do now? I guess not, because you want them to work even if there are no notes. And perhaps you want them to go at a fixed "speed" rather than (effectively) faster or slower depending on how long the notes are.

Yeah, so Ctrl+left/right go by note.

I was imagining that simply left/right would go by the amount you would move the panning, which is not fixed, but depends solely on the zoom level, not the existence of notes.

Try again now (38a5663f773f). I've reshuffled the menus and keyboard shortcuts:

• Left/Right now move the play head in one-second increments. It does the same thing regardless of whether playback is happening or not. The view may scroll, but only when the play head reaches the edge of it.
• Ctrl+Left/Right do the same thing as they already did: move the play head note by note.
• Alt+Left/Right scroll the view without moving the playhead (I've now named these commands "peek left" and "peek right").

I've no idea what (if anything) Alt+Left/Right map to on the Mac. (I chose those shortcuts because the user will naturally be familiar with them from strafe left/right in DOOM.) If you've a better suggestion, go ahead!

I love being able to move the cursor!! This is really, really nice.

Is it possible to move by, say 10% of the visible width rather than always the same realtime amount?

I've no idea what (if anything) Alt+Left/Right map to on the Mac. (I chose those shortcuts because the user will naturally be familiar with them from strafe left/right in DOOM.) If you've a better suggestion, go ahead!

In this case it appears to be just Alt+Left/Right. A miracle.

Is it possible to move by, say 10% of the visible width rather than always the same realtime amount?

Ah, I found out that it is!

I'm going to try and make a new rewind() and forward() function in MainWindow to replace the one from MainWindowBase. I've made a little attempt to see whether it's possible (yes), but need to go back and do properly.