bazmonk / digigurdy-baz

DigiGurdy Teensy Code
MIT License
15 stars 10 forks source link

just a tiny bit of moving around please #74

Closed Gubbledenut closed 1 year ago

Gubbledenut commented 2 years ago

can you put lines 23 -73, the note names at the end of the config section , so all the include files are in one place...maeks it far easier to see what we're meant ato have in the folder....Like this????

1 // Digigurdy-Baz 2 // VERSION: v1.4.0 (testing)] 3 4 // AUTHOR: Basil Lalli 5 // DESCRIPTION: Digigurdy-Baz is a fork of the Digigurdy code by John Dingley. See his page: 6 // https://hackaday.io/project/165251-the-digi-gurdy-and-diginerdygurdy 7 // REPOSITORY: https://github.com/bazmonk/digigurdy-baz 8 9 // ############################################################# 10 // CONFIG SECTION HAS MOVED: see the config.h for those options. 11 // ############################################################# 12 13 #include 14 // https://www.pjrc.com/teensy/td_libs_Bounce.html 15 #include 16 #include 17 // https://www.pjrc.com/teensy/td_midi.html 18 // https://www.pjrc.com/teensy/td_libs_MIDI.html 19 #include 20 #include 21 #include 22 23 // These are found in the digigurdy-baz repository 24 #include "bitmaps.h" // Pretty pictures 25 #include "eeprom_values.h" // Save-slot memory addresses 26 #include "default_tunings.h" // Preset tunings. 27 #include "note_bitmaps.h" // Note (ABC) bitmaps 28 #include "staff_bitmaps.h" // Staff bitmaps 29 #include "config.h" // Configuration variables 30 31 // The "white OLED" uses these now. The not-quite-standard blue version doesn't. 32 #define SCREEN_WIDTH 128 // OLED display width, in pixels 33 #define SCREEN_HEIGHT 64 34 35 // The white OLED uses Adafruit SSD1306. Blue uses SH1106. 36 #ifdef WHITE_OLED 37 #include 38 #endif 39 #ifdef BLUE_OLED 40 #include 41 #endif 42 43 // These are the Teensy pins wired up for the OLED. 44 #define OLED_MOSI 9 45 #define OLED_CLK 10 46 #define OLED_DC 11 47 #define OLED_CS 12 48 #define OLED_RESET 13 49 50 // Initiate the correct kind of display object based on OLED type 51 #ifdef WHITE_OLED 52 Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, OLED_MOSI, OLED_CLK, OLED_DC, OLED_RESET, OLED_CS); 53 #endif 54 #ifdef BLUE_OLED 55 Adafruit_SH1106 display(OLED_MOSI, OLED_CLK, OLED_DC, OLED_RESET, OLED_CS); 56 #endif 57 58 // Right now not using the std namespace is just impacting strings. That's ok... 59 using namespace MIDI_NAMESPACE; 60 61 // enum Note maps absolute note names to MIDI note numbers (middle C4 = 60), 62 // which range from 0 to 127. 63 // 64 // This lets us specify MIDI notes by their name instead of having to refer to a table. 65 enum Note { 66 c_1, c_1s, d_1, d_1s, e_1, f_1, f_1s, g_1, g_1s, a_1, a_1s, b_1, 67 c0, c0s, d0, d0s, e0, f0, f0s, g0, g0s, a0, a0s, b0, 68 c1, c1s, d1, d1s, e1, f1, f1s, g1, g1s, a1, a1s, b1, 69 c2, c2s, d2, d2s, e2, f2, f2s, g2, g2s, a2, a2s, b2, 70 c3, c3s, d3, d3s, e3, f3, f3s, g3, g3s, a3, a3s, b3, 71 c4, c4s, d4, d4s, e4, f4, f4s, g4, g4s, a4, a4s, b4, 72 c5, c5s, d5, d5s, e5, f5, f5s, g5, g5s, a5, a5s, b5, 73 c6, c6s, d6, d6s, e6, f6, f6s, g6, g6s, a6, a6s, b6, 74 c7, c7s, d7, d7s, e7, f7, f7s, g7, g7s, a7, a7s, b7, 75 c8, c8s, d8, d8s, e8, f8, f8s, g8, g8s, a8, a8s, b8, 76 c9, c9s, d9, d9s, e9, f9, f9s, g9 77 }; 78 79 // string array NoteNum is the reverse of the above Note enum. It maps MIDI note numbers to 80 // screen-friendly note names. 81 // 82 // This lets us recall string names for printing on the screen without having to refer to a table. 83 std::string NoteNum[] = { 84 "C-1", "C#-1", "D-1", "D#-1", "E-1", "F-1", "#F-1", "G-1", "G#-1", "A-1", "#A-1", "B-1", 85 "C0", "C#0", "D0", "D#0", "E0", "F0", "F#0", "G0", "G#0", "A0", "A#0", "B0", 86 "C1", "C#1", "D1", "D#1", "E1", "F1", "F#1", "G1", "G#1", "A1", "A#1", "B1", 87 "C2", "C#2", "D2", "D#2", "E2", "F2", "F#2", "G2", "G#2", "A2", "A#2", "B2", 88 "C3", "C#3", "D3", "D#3", "E3", "F3", "F#3", "G3", "G#3", "A3", "A#3", "B3", 89 "C4", "C#4", "D4", "D#4", "E4", "F4", "F#4", "G4", "G#4", "A4", "A#4", "B4", 90 "C5", "C#5", "D5", "D#5", "E5", "F5", "F#5", "G5", "G#5", "A5", "A#5", "B5", 91 "C6", "C#6", "D6", "D#6", "E6", "F6", "F#6", "G6", "G#6", "A6", "A#6", "B6", 92 "C7", "C#7", "D7", "D#7", "E7", "F7", "F#7", "G7", "G#7", "A7", "A#7", "B7", 93 "C8", "C#8", "D8", "D#8", "E8", "F8", "F#8", "G8", "G#8", "A8", "A#8", "B8", 94 "C9", "C#9", "D9", "D#9", "E9", "F9", "F#9", "G9" 95 }; 96 97 // This is a version of the above but with flats listed as well. 98 std::string LongNoteNum[] = { 99 " EMPTY ", "C#-1/Db-1", " D-1 ", "D#-1/Eb-1", " E-1 ", " F-1 ", "F#-1/Gb-1", " G-1 ", "G#-1/Ab-1", " A-1 ", "A#-1/Bb-1", " B-1 ", 100 " C0 ", "C#0/Db0", " D0 ", "D#0/Eb0", " E0 ", " F0 ", "F#0/Gb0", " G0 ", "G#0/Ab0", " A0 ", "A#0/Bb0", " B0 ", 101 " C1 ", "C#1/Db1", " D1 ", "D#1/Eb1", " E1 ", " F1 ", "F#1/Gb1", " G1 ", "G#1/Ab1", " A1 ", "A#1/Bb1", " B1 ", 102 " C2 ", "C#2/Db2", " D2 ", "D#2/Eb2", " E2 ", " F2 ", "F#2/Gb2", " G2 ", "G#2/Ab2", " A2 ", "A#2/Bb2", " B2 ", 103 " C3 ", "C#3/Db3", " D3 ", "D#3/Eb3", " E3 ", " F3 ", "F#3/Gb3", " G3 ", "G#3/Ab3", " A3 ", "A#3/Bb3", " B3 ", 104 " C4 ", "C#4/Db4", " D4 ", "D#4/Eb4", " E4 ", " F4 ", "F#4/Gb4", " G4 ", "G#4/Ab4", " A4 ", "A#4/Bb4", " B4 ", 105 " C5 ", "C#5/Db5", " D5 ", "D#5/Eb5", " E5 ", " F5 ", "F#5/Gb5", " G5 ", "G#5/Ab5", " A5 ", "A#5/Bb5", " B5 ", 106 " C6 ", "C#6/Db6", " D6 ", "D#6/Eb6", " E6 ", " F6 ", "F#6/Gb6", " G6 ", "G#6/Ab6", " A6 ", "A#6/Bb6", " B6 ", 107 " C7 ", "C#7/Db7", " D7 ", "D#7/Eb7", " E7 ", " F7 ", "F#7/Gb7", " G7 ", "G#7/Ab7", " A7 ", "A#7/Bb7", " B7 ", 108 " C8 ", "C#8/Db8", " D8 ", "D#8/Eb8", " E8 ", " F8 ", "F#8/Gb8", " G8 ", "G#8/Ab8", " A8 ", "A#8/Bb8", " B8 ", 109 " C9 ", "C#9/Db9", " D9 ", "D#9/Eb9", " E9 ", " F9 ", "F#9/Gb9", " G9 " 110 }; 111

bazmonk commented 2 years ago

I would if I could... those two arrays are used in some of the header files. They need to exist beforehand in the code before I #include my headers. I also don't like where they are in the code.

I can, however, look into putting them into a header themselves, which would make that part more tidy.

What I really want to do is break up the entire code file into more logical chunks (all the class definitions in one file, all the screen functions in another file). The main .ino file should never be this big, and finding stuff is becoming challenging if you don't know where to look :-) But I'm scared people are going to interpret that as "more complicated".

Gubbledenut commented 2 years ago

Smaller and manageable makes sense to me…but then who will be likely to upload the code themselves? It makes no difference if we do it for others.

bazmonk commented 2 years ago

Just filing this in the after-v1.5 section.

bazmonk commented 1 year ago

I'm closing this: so much has changed the lines being requested don't exist there anymore :-)