Two keyboard shortcuts per note?

Comments and questions about Chordhopper.
MattV
Posts: 89
Joined: Sun May 21, 2006 5:19 pm

Two keyboard shortcuts per note?

Postby MattV » Sun Dec 09, 2007 6:18 pm

I would like to be able to assign two keyboard shortcuts per note. That way I can fit about an octave and a half of the piano keyboard on the computer keyboard, and inversions of chords will look/feel more like they do on a piano.

Edit: Ah, this would work beautifully if I could do it! According to Chris's post in the 'how many chords' thread, the notes of the chords range from A3 to F5, which is just enough to fit from Q to backslash!

Edit #2: Oops---I guess the range of the chords extends from Ab3 to F#5, not A3 to F5. If I used the 1 key for Ab3 and the Backspace key for F#5, the layout I have in mind could still work.

aruffo
Site Admin
Posts: 1696
Joined: Tue Dec 14, 2004 12:09 pm
Location: Evanston, IL

Postby aruffo » Sun Dec 09, 2007 11:52 pm

My immediate reaction was hey, that would be cool to have it actually resemble the piano keyboard. Then it occurred to me that it may be more helpful for people to realize that these are the same pitches in a different order. I find that the single-pitch part of it has forced me to start thinking "circle means root tone on top... diamond means root in the middle... square means root first."

MattV
Posts: 89
Joined: Sun May 21, 2006 5:19 pm

Postby MattV » Mon Dec 10, 2007 12:31 am

Chris,

That's why it should be an option rather than a default setting. :D

aruffo
Site Admin
Posts: 1696
Joined: Tue Dec 14, 2004 12:09 pm
Location: Evanston, IL

Postby aruffo » Mon Dec 10, 2007 12:48 am

The reason my first reaction to your suggestion was positive is that the game initially felt a bit odd in having the "wrap-around" chord components. I wondered then if there might be some way to play the tones in the "correct order" and not lose the sense that these were the same tones regardless of octave. I'm surprised that I didn't even think of expanding the keyboard shortcuts (I was thinking more along the lines of shifting the shortcuts left or right, which seemed far more confusing than anything else) but I'm still not sure how having two different keys available for a single pitch could directly reinforce the sameness of the tones across octaves in the way that I believe the single-key shortcuts do...?

MattV
Posts: 89
Joined: Sun May 21, 2006 5:19 pm

Postby MattV » Mon Dec 10, 2007 1:07 am

Well, on a real piano keyboard, the sameness across octaves is reinforced by the repeating pattern of white and black keys. Every C is a white key just to the left of a group of two black keys, etc. This pattern would not be as clear on a computer keyboard, but I'll take what I can get.

With the current system, I feel like I'm playing a first-inversion G chord by arpeggiating a second-inversion G chord. It's very odd and I have to fight my piano 'instincts'.

If you want to, you can make the piano keyboard layout an Easter egg and provide the secret only to carefully screened individuals. :lol:

MattV
Posts: 89
Joined: Sun May 21, 2006 5:19 pm

Postby MattV » Sun Dec 16, 2007 1:24 am

Chris,

You have said that you would like to add support to ETC for MIDI input. This would eliminate the need to use the computer keyboard as a poor substitute for a piano keyboard.

Have you looked at the PortMidi classes of MonkeyBread Software's Audio plug-in for REALbasic? The documentation says that these classes support both Windows and Mac OS X.

http://www.monkeybreadsoftware.de/realb ... udio.shtml

MattV
Posts: 89
Joined: Sun May 21, 2006 5:19 pm

Postby MattV » Mon Dec 17, 2007 1:10 am

After further thought, I've realized that I have a deeper disagreement with the chord-spelling interface: because the pitches in each chord are heard simultaneously, and have no order as heard, the user should not be required to input the pitches in a specific order.

With a MIDI keyboard, you could simply require the user to play whole chords at once. Despite the fact that this kind of interface is not possible with the mouse (because the cursor can't be in 3-4 places at the same time) nor with the computer keyboard (because the hardware is not designed to register 'chords' except with modifier keys), it is the ideal interface, in my view. Chords should be the input because chords are the output.

I grant that even if (when?) MIDI keyboards are supported, not everyone will have one, so there has to be a fallback interface for the mouse/keyboard. That means entering the notes of the chords one at a time---but the user should be allowed to enter the notes in any order. Yes, it's true that if you have only one button for each pitch class, then all inversions of a given chord can be entered the same way. That's fine. It reinforces the 'sameness' you were talking about. If you want to reinforce the differences, then allow multiple octaves of input, because that's what the real difference is.

aruffo
Site Admin
Posts: 1696
Joined: Tue Dec 14, 2004 12:09 pm
Location: Evanston, IL

Postby aruffo » Mon Dec 17, 2007 2:11 am

What you observe about the "order" is definitely a question I wrestled with-- a question appearing, of course, the moment I attempted to play and realized that all inversions could be entered the same way.

The question answered itself, though, by considering that the purpose of pitch "spelling" cannot be to indicate an order of pitches as heard, because the order, as you rightly point out, is not heard. (In fact, for some reason I still don't understand, I continue to hear Chordhopper's "circle" inversions as though the two bottom notes were arpeggiated high-to-low. The effect persists when I play the same chords on a piano.) The order of pitches in a chord is an order as seen, not heard; when "spelling" a chord, the visible note-dots must be arranged in some order, and bottom-to-top is as logical as any other.

MattV
Posts: 89
Joined: Sun May 21, 2006 5:19 pm

Postby MattV » Mon Dec 17, 2007 2:47 am

What gets me is that if the note buttons represent pitch classes, then there is no "bottom" or "top". If you want the user to recognize what octave a note is in, then I think you should represent that explicitly, visually, in the interface.

The A in a 'tulip' chord is not the same A as in a 'basketball' chord, but the game does not show the difference. There is only one button for an A, the lock. It plays one A if you're spelling a 'tulip' chord, and a different A if you're spelling a 'basketball' chord. That makes no sense.

Either the note buttons represent pitch classes, in which case the concepts of 'bottom' and 'top' don't apply and any order of input should be acceptable, or the note buttons represent particular pitches, in which case you need more of them to be able to spell all the chords in the game.

Edit: lock not ladybug---shows how much I look at the screen when I play!

Edit #2: If you added more note buttons, you could make it easier to see that certain icons appeared more than once by adopting a piano-like button layout:

Code: Select all

Le Te   Di Me    Fi Le Te    Di Me    Fi
 La Ti Do Re Mi Fa So La Ti Do Re Mi Fa

Edit #3: And on the note-entry screen, you could disable any button representing a note that was not used by any of the chords currently available to the user. I would suggest the same thing for the existing 12-button screen, actually.

TS
Posts: 168
Joined: Sun May 07, 2006 4:58 am

Postby TS » Mon Dec 17, 2007 9:51 am

MattV wrote:What gets me is that if the note buttons represent pitch classes, then there is no "bottom" or "top". If you want the user to recognize what octave a note is in, then I think you should represent that explicitly, visually, in the interface.

I remember that there was some time ago on the front page a description of a music teacher who taught octaves to children by saying that the pitch was the same in all octaves, but in the low octaves the pitch was "big" and in the high octaves the pitch was "small", so maybe you could represent different octaves by making the icons big or small. For three octaves there could be for example three lines of icons on top of each other, large icons in the bottom and small icons on top. This way the same pitch would always be in the same column, and the octave would be clearly represented.

MattV
Posts: 89
Joined: Sun May 21, 2006 5:19 pm

Postby MattV » Mon Dec 17, 2007 10:41 am

TS,

Good idea! Other advantages of your suggested layout are:
  • unlike my suggested layout, it isn't biased toward pianists
  • it matches the real-world pattern that large objects usually make low sounds and small objects usually make high sounds
Of course, if the range of the buttons matched the range of pitches used in the game, you wouldn't have three full octaves---instead, the layout would look something like this:

Code: Select all

do di re me mi fa fi
Do Di Re Me Mi Fa Fi So Le La Te Ti
                        LE LA TE TI

Edit: I'm not necessarily against three full rows of buttons, though. It wouldn't be any different from using a MIDI keyboard and thereby having the ability to enter pitches outside the range of the game.

Edit #2: Another really neat thing about using different-sized buttons is that it leaves open the possibility of a circular layout. (Just thinking out loud here.) You could have three concentric rings of buttons, with the largest buttons in the outer ring and the smallest ones in the inner ring. The buttons could be arranged chromatically, or they could be in a circle-of-fifths arrangement, which would group all the notes of the major scale in the same sector of the circle.

I think I would always want to have the option of a linear button layout, even if a circular layout were supported.

aruffo
Site Admin
Posts: 1696
Joined: Tue Dec 14, 2004 12:09 pm
Location: Evanston, IL

Postby aruffo » Mon Dec 17, 2007 11:45 am

Love it. Now I gotta think how to implement it. My biggest problem is screen real estate. I think I'll ask a question about that in another thread.

aruffo
Site Admin
Posts: 1696
Joined: Tue Dec 14, 2004 12:09 pm
Location: Evanston, IL

Postby aruffo » Mon Dec 17, 2007 12:05 pm

Oh.. wait a minute..

I want to avoid making it possible for "higher" and "lower" to be used as the more useful cue. The point of having the bottom-to-top orientation is so that there is an orientation; so that players can realize that the pitches are in a different configuration, not learn that some are "low" and others are "high", and certainly not to accomplish the game-tasks based on the fact that some dots are larger or smaller than others (as opposed to the image or color on the dots).

The bigger/smaller will very likely find a place somewhere, though, whenever I find a task where higher/lower would otherwise be applicable and important besides.

MattV
Posts: 89
Joined: Sun May 21, 2006 5:19 pm

Postby MattV » Mon Dec 17, 2007 12:53 pm

Chris,

I don't see how it's possible to distinguish between inversions of a chord without bringing in some form of the low/high, big/small, dark/bright distinction. Whatever words we use to describe it, you're asking the user to distinguish between notes that are of the same pitch class, but in different octaves. The user has to do that to determine the bottom-to-top order in which the notes would be written.

In my opinion, the octave distinction needs a visual metaphor in the interface.

Could you please elaborate on how a user could 'cheat' if there were different-sized buttons?

Another interface idea: Rather than concentric rings, the buttons could be arranged in a spiral so that each button would be slightly larger/smaller than the next. I think the buttons of each pitch class could still be lined up radially. Order of pitches would have to be chromatic. The spiral would eliminate any confusion about where the 'jump' from one ring to another is located.

aruffo
Site Admin
Posts: 1696
Joined: Tue Dec 14, 2004 12:09 pm
Location: Evanston, IL

Postby aruffo » Mon Dec 17, 2007 1:20 pm

I don't see how it's possible to distinguish between inversions of a chord without bringing in some form of the low/high, big/small, dark/bright distinction.

I see it all the time... CEG, EGC, GCE. In this culture at least, we read from right to left, and when I've seen people use this form in this forum, left to right is assumed to be bottom to top. I agree that the Chordhopper wraparound may not be ideal, but after having played with it for a while it doesn't seem harmful to me.

Could you please elaborate on how a user could 'cheat' if there were different-sized buttons?

I don't know if I'm thinking "cheat" so much as drawing attention to an attribute I'd rather downplay. Right now, I distinguish between the sock and trash can because the trash can seems to be "looking down" where the sock feels like it's "sitting calmly". In my mind the height attribute is associated with the chord, not the pitch. One chord is ACE and the other CEA, yes, but it doesn't seem necessary to try to introduce the idea that there are "multiple A's" when the height difference is already explained by the sound of the chord. It makes sense to me that when you put the pitches in a different order you get a chord that sounds different, and I wouldn't want to additionally explain that you need "higher" or "lower" pitches to create inversions. Although I can see that down the line it will be come useful to know octave distinctions, I would prefer in the short term that "height" and "pitch" become as dissociated as possible.


Return to “Chordhopper”

Who is online

Users browsing this forum: No registered users and 1 guest