velocity monitor

[skeble]

I have idea. Could you add "velocity monitor"? I think - better for explain is example. The perfect velocity monitor is at Megadrum software - see at http://www.megadrum.info/configtool/. And if you add mark as velocity from midi for each played note in this monitor - it would be lovely.
Thanks.

[Nicholas]

Hmm, I just tried playing around with a few mock-ups of what that might look like (with a velocity meter added below the keyboard), but I couldn't find any good solutions. The black keys were causing trouble. You can't just line the bottom of the keyboard with meters because the black keys don't reach that far down. And I wouldn't want to put the meters at the top or they'd add more space between the keys and falling notes.

Do you have any suggestions on how to draw it / where to put something like that?

[skeble]

There is my idea

Spoiler:

[DanClark]

I like skeble's of displaying player and MIDI velocity, but I think translating a window on the side to a specific note to the right would be difficult.

Attached is a screenshot showing how Sibelius 7.5 handles velocity. Notice that the velocity bars are aligned with the notes. The blue bar could be player velocity and a horizontal red-bar could indicate MIDI velocity.

Regards,

Dan.

[Nicholas]

My worry with Sibelius' solution is that it's a lot of extra visual noise. It starts to cover up things like staccato dots and finger hints. Presumably that's a display you'd only turn on briefly in Sibelius, whereas it would be shown in Synthesia for much longer.

I hadn't really spent much time considering the same problem for sheet music. I wonder if you could just get away with different colors on the note heads. The colors are pretty well established in frequency spectrograms where black/blue might mean "low [velocity]" all the way up to orange/red meaning "high [velocity]".

For the falling notes... I wonder if -- assuming it's alright to lose color as a way to distinguish hands -- the same solution might work. I've heard other suggestions like note width and note opacity as a way to communicate velocity, but I'm not as convinced. Width is a really strong hint about whether you're playing a white or black key. I wouldn't want to weaken that. And I'm not sure opacity is much different than just going full-out and changing the color.

It'd be interesting to see the spectrum colors in a mock-up to show velocity.

[DanClark]

My worry with Sibelius' solution is that it's a lot of extra visual noise. It starts to cover up things like staccato dots and finger hints. Presumably that's a display you'd only turn on briefly in Sibelius, whereas it would be shown in Synthesia for much longer.

I hadn't really spent much time considering the same problem for sheet music. I wonder if you could just get away with different colors on the note heads. The colors are pretty well established in frequency spectrograms where black/blue might mean "low [velocity]" all the way up to orange/red meaning "high [velocity]".

For the falling notes... I wonder if -- assuming it's alright to lose color as a way to distinguish hands -- the same solution might work. I've heard other suggestions like note width and note opacity as a way to communicate velocity, but I'm not as convinced. Width is a really strong hint about whether you're playing a white or black key. I wouldn't want to weaken that. And I'm not sure opacity is much different than just going full-out and changing the color.

It'd be interesting to see the spectrum colors in a mock-up to show velocity.

Nicholas,

First, I agree about visual noise. That can be a challenge. Whatever solution you choose should be user selectable - at least a Boolean on/off.

When learning and practicing, I go though several stages. First is just learning the song (plink, plink, "damn", plink...). After that it's about musicality nuances - tempo, velocity, etc. The key for me is understanding the difference between how I play (Mr. Clumsy Hands) and how the song should be played (what's in the MIDI file).

Using different colors has several issues. Color intensity and shade is difficult to discriminate quickly. And some people are color blind. Color + physical size and shape is better in my professional opinion (see p.s. below).

After thinking about this issue, it occurs to me that there may be multiple needs/requirements here:

1. Before playing - User needs to evaluate the music to see how it should be played. A bit of clutter in the UI may be reasonable even at the expense of some visual noise.

2. During playing - During playing user needs to see how it should be played, but may need a cleaner UI. I.e. less visual noise is important. Different colored note heads might work, but this may clash with any future plans you have for displaying multiple voices on one system. For example, Sibelius can display and up to four voice colors per system. For practice, I find this feature very useful.

3. After playing - After I'm finished playing, I try to determine what went well and what did not. This is the analysis phase. IMO, this would require:

- 3a) A "Teacher Review Mode" where the student can review how they did with "teacher" pointers. Essentially, this is a digital recording of the user's performance with visual indicators to allow the user to see their errors as they made them. This could include missed notes, tempo issues, and velocity mismatches.

- 3b) In "Teacher Review Mode" visual clutter would be of minimal importance as long as the user could quickly turn analysis indicators on and off with push buttons (or some other control) at the top of the "replay" page.

I these ideas are useful.

Regards,

Dan.

p.s I've been developing analytical systems since 1981. Clear data presentation is always a challenge that I continuously wrestle with even today. Each person wants their own customized view of the data. And what is clear to one person is "clear as mud" to someone else.

[Nicholas]

3a) A "Teacher Review Mode" where the student can review how they did with "teacher" pointers. Essentially, this is a digital recording of the user's performance with visual indicators to allow the user to see their errors as they made them. This could include missed notes, tempo issues, and velocity mismatches.

This is actually something that's been on the list for ages (billed as "Performance Analysis" on the old public feature list that hasn't been available for a few years now).

I agree that having rich on-screen information during that step is perfectly fine. Lots of toggles to overlay interesting things.

An upcoming stepping-stone feature is to start recording entire performances instead of just a handful of metrics. Just from a score/points viewpoint, TonE made an excellent point in this post that no matter how Synthesia decides to calculate scores in the future, so long as the raw performances are available, we can always reevaluate things again later. It also opens the doors to the types of overlays we're talking about here. Cool comparisons too, like a heatmap that shows all the mistakes you've made across all your performances.

p.s I've been developing analytical systems since 1981...

This is the first time something has made me feel young in a while... unfortunately at your expense. I was born in 1982.

[jimhenry]

This should make you feel like you are drowning in the fountain of youth: When I was learning to program, we had to punch cards.

[Nicholas]

I've heard of those; I think I may have seen one in a history book once!

[DanClark]

This should make you feel like you are drowning in the fountain of youth: When I was learning to program, we had to punch cards.

Yep. Been there; done that. Type up them punch cards very carefully. Hand them to the nice folks at the RJE center. 36 hours later you get the fruits of your labor: "Error at <blah>, <blah>, <blah>". So you add the comma you missed, and wait another 36 hours. It was a joy!

And then there was the handling of those punch cards... When I was a very raw newb, I didn't think that adding a red strip across the top of a card deck was necessary. Then one day, while walking down the hall with my unmarked punch card pack, I tripped!

Yep, those were the good ole days. NOT!!!

Dan.

[Pianotehead]

I'm almost old enough to have worked with the punch cards, but I've never seen one, except in pictures.

[jimhenry]

When I was a very raw newb, I didn't think that adding a red strip across the top of a card deck was necessary. Then one day, while walking down the hall with my unmarked punch card pack, I tripped!

It was quite amazing how a single marker line on a deck of punched card could prevent dropping the cards or tripping while you carried them.

Or at least I never heard of anyone dropping a marked deck.

Shall we get into early PDP-8 minicomputers where you had to enter a bootstrap program using toggle switches so you could load your program from punched paper tape on a teletype machine?

[DanClark]

When I was a very raw newb, I didn't think that adding a red strip across the top of a card deck was necessary. Then one day, while walking down the hall with my unmarked punch card pack, I tripped!

It was quite amazing how a single marker line on a deck of punched card could prevent dropping the cards or tripping while you carried them.

Or at least I never heard of anyone dropping a marked deck.

Shall we get into early PDP-8 minicomputers where you had to enter a bootstrap program using toggle switches so you could load your program from punched paper tape on a teletype machine?

I programmed Texas Instruments Programmable Terminals in the mid 1970's when I as a sales account manager for them. My customers were all engineers and developers so I had to walk-the-walk. The bootstrap was a series of toggle switches. Ah... "Fond" memories.

In the late '70's I became a sales account manager for DEC. My customers were three Western Electric plants and the Teletype corp. (Yep, that Teletype.) I sold them a lot of CNC controllers, PDP-11's and VAXes. That was long ago and far, far away. Seems like a century ago tech-wise and milliseconds ago memory wise.

Regards,

Dan.