Just for fun…
When I was working on my SirSound project, I had to create my own implementation of the Extended Color BASIC “PLAY” command. I did this by going through the Extended BASIC Unravelled book and looking at the 6809 assembly for the command.
I made a workalike function in C for the Arduino:
…and while doing so, discovered an interesting thing about the PLAY parser and how it handled the notes.
The PLAY command operates by reading a command followed by an option modifying. For instance, “V10” is the command “V” for volume, and a modifier “10” for volume level 10. “T8” is command “T” for tempo and “8” for the speed.
When it comes to playing musical notes, PLAY understands the standard scale notes of C, D, E, F, G, A and B. When it parses a command letter, it then looks to see if a modifier is after it. The modifiers include “#” and “+” for sharp, and “-” for flat.
This allows you to play the full 12 note scale:
Using sharps: C C# D D# E F F# G G# A A# B (or C C+ D D+ E F F+ G G+ A A+ B)
Using flats: C D- D E- E F G- G A- A B- B
These notes correspond to the notes found on a piano keyboard:
I don’t understand music theory, but I know enough to say the white keys are the natural notes (CDEFGAB) and the black keys are a half step in between and are either sharps of the note before it (C# D# F# G# A#) or flats of the notes after it (Db Eb Gb Ab Bb). There is no E# or Fb or B# or Cb on a keyboard.
But, the BASIC PLAY parser does not add any code to prevent you from playing them anyway :-)
- PLAY “E# F” (E sharp and F natural) will play the same note.
- PLAY “E F-” (E natural and F flat) will play the same note.
- But you can’t PLAY “C-” (C flat) or “B#” (B sharp) because it knows to reject those modifiers from the notes at each end of the scale.
To me, this seems like a bug, but I implemented in my PLAY PARSER code anyway, just in case anyone used it. But since I lack any music theory background, I am probably wrong, as I have been told there is a reason for this.
For for someone like me with limited music background, it seemed like an odd thing to stumble upon in the code. I even documented in my SirSound documentation:
N (optional) followed by a letter from “A” to “G” or a number from 1 to 12.
When using letters, they can be optionally followed by “#” or “+” to make it
as sharp, or “-” to make it flat. When using numbers, they must be separated
by a “;” (semicolon).
C C# D D# E F F# G G# A A# B (sharps)
1 2 3 4 5 6 7 8 9 10 11 12
C D- D E- E F G- G A- A B- B (flats)
Due to how the original PLAY command was coded by Microsoft, it also allowsSirSound documentation.
sharps and flats that would normally not be allowed. For instance, E# is the
same as F, and F- is the same a E. Since notes are numbered 1-12, the code
did not allow C- or B#. This quirk is replicated in this implementation.
Ah, the things that amuse those of us without the brainpower to understand them.
Until next time…
Well, in music theory, the natural notes as you call them each have a whole step between them — except between E and F, and B and C. Those are only half-step notes.
So E# and F, are in fact the very same note. As are B# and C
But I would say the bug is in not defining the endpoints in the list properly, since the jump from B to C changes the octave.
Yes, if it had been consistent through all notes on the scale, then I’d say it was intentional. I’m expecting it was more a “save ROM space” than a bug, though.