GithubHelp home page GithubHelp logo

digigurdy-baz's Introduction

  • 👋 Hi, I’m @bazmonk
  • 👀 I’m interested in the Digi-Gurdy (https://digigurdy.com). What started with making a few simple edits of its code has turned into a complete reimagining of the code, which is now what runs on them! Everything here pertains to that.
  • 📫 How to reach me: post an issue in a repo

digigurdy-baz's People

Contributors

bazmonk avatar bdlalli avatar salusasecondus avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

digigurdy-baz's Issues

Bigbutton

I know it is a big button but perhaps it's time to call it something more relevant like crank toggle ? I know there's already a mycrank so maybe mycranktoggle or mycrankswitch ?

Feature: digiharpa support

@Gubbledenut, this is for you.

Now that I know digiharpas also use digigurdy code, I'm keeping that in mind with the rewrite.

Supporting them requires:

  • Extra keybox buttons
  • Digiharpa-specific tuning options

I'll work on tuning options when it gets to that stage, but in order to support extra buttons, KeyboxButton objects in the code (which represent the pin assingment and how high that button raises a string's note) will be created from an array, that eventually I'll put in a separate configuration file. From https://github.com/bazmonk/digigurdy-baz/tree/rewrite:

int pin_array[] = {-1, 2, 24, 3, 25, 26, 4, 27, 5, 28, 29, 6, 30,
                   7, 31, 8, 32, 33, 18, 34, 19, 35, 20, 36, 37};

This is what the digigurdy uses. -1 is a bogus filler value (it won't get a button object), but for the rest the value is the pin assignment, and the array index is how many half-steps it raises a note. So like, pin 25 is index 4 so it raises the string by two whole notes.

That way, digiharpa support is just a matter of providing a different array.

Feature: Documentation

In conjunction with #6, a lot of the commenting in the code describes the requirements and libraries it uses.

Let’s make a complete set of software requirements and installation instructions and put it in a better place.

Backward compatible capo and octave/transpose options

John did have key combos attached as well as he assigned the capo and octave on pins 21,22,23
This is required for older digi gurdies without the three buttons. Need to ensure the key combo is also in your codeimage

Feature: Legacy key-combo support

Popular demand has requested support for the key combos used to access functions before the capo/octave buttons existed.

John's provided me with what the old combos were.

Default Tunings

As Requested,
Please put the preset titles as well as the notes in the same sub file to make adjustments a bit easier.
Me and Sergio designed and allocated those presets, so my fault not John's , however the C drone is low and the trompette often C3 too but the G trompette is higher, dunno why.
Ideally the goto tuning ie no 1 should be the G Gg G one, it's the most versatile for beginners , while in G/C tuning C Gg C is ore "traditional" it's restricted to only being ab le to play in C, where the all G one lets you play in G or C without having to tune.

designating the tunings in the same sequence they are as you look down it's Trompette, Chanter Low, Chanter Hi, Drone ie C Gg C
just easier to visualise that way..
So keep the same 4 just alter to this perhaps, so the two unison tunings are first in each ??
1; G Gg G
2; C Gg C
3; D Dd D
4; G Dd G

Coup not possible

ver0991 the buzz seems to come on but it's not controllable as in being able to perform a coup correctly.
I have tried with setting from 7 to 60 and it does slightly alter the sensitivity but I cannot control it to obtain a coup/ beat??
at least I have the buzz working now.

I want to support alternative tunings

(Similar to my past issues, I expect that I'll develop this myself and so am putting an issue here to track it and let people yell at me 😁 )

I play with various instruments which are not modern western instruments and thus do not necessarily conform to A-440 equal temperament. I want to be able to:

  1. Change A to be a pitch other than 440. (Either by menu or specific selection.)
  2. Change temperament to something other than equal
  3. Support non-western tunings (specifically Arabic Maqam)

Ideally these properties will all be savable on a per-slot basis, but this needs to be investigated. (Especially since we only have limited storage.) We still need to figure out how to indicate these to the midi controller, how to safe them, and how much space we need.

Question thread to bs-16i developers: https://twitter.com/SalusaSecondus/status/1549886938118627328

Bounce looks deprecrated (see Bounce2)

I'm trying to set up my build environment and the Bounce library looks deprecated in favor of Bounce2. We should upgrade. (I cannot even find Bounce listed in the library manager anymore.)

screen ver 1.2

Je viens de regarder ton nouvel code 1.2,

quand on appuis avec le bouton "gaming" l'affichage de l'ecran, est ok

par contre

en tournant la manivelle en arriere, et doucement avec l'ancienne version moteur, l'ecran affiche "la note joué" puis l'ecran fixe ou il y a les "données de selection"

en tournant dans le bon sens l'ecran des notes jouées s'affiche normalement , mais le moindre rythme un peu plus lent, repasse sur l"ecran de "données selection", et parfois quand la vitesse est lente, les deux (note et selection s'affiche en meme temps, je pense que cet ecran de selecrion devrait etre temporisé de quelques seconde, pour eviter ce cumul, et d'avoir ce desagrement.

j'espere avoir eté clair???

Volume control

Works fine but perhaps instead of using the 0-127 nomination.can we have proportional 0-10 or 11 instead? Think it will be more user friendly...also will be more relevant to the slider settings on bs16i . I am okay Ng again with the RPi thing..and also will make the upcoming tsunami easier to set?

Save overwrite warning

that flows really well, both for the preset and advanced options, it also I think has amore logical flow to the menu structure and options too.
Just wondering do we need a warning if a tuning slot is already saved to eeprom, save overwriting it?

Originally posted by @Gubbledenut in #57 (reply in thread)

Crank Detected when no crank attached

Not sure how far back this goes, but 1.7.5 unto 1.8, currently have 1.7.8 all say Crank detected on startup with no crank module connected...perhaps this has become obsolete on start up?
Everything else works fine, ie crank connected works, along with crank button to play without..or not connecting crank and using crank button??

Feature: DoReMi, alternate notations

@Gubbledenut this is for you!

Set up the config flags (compile-time) and some alternate NoteNum and LongNoteNum arrays for displaying DoReMi-style notation on-screen.

Another suggestion was to possibly remove the octave number in an alternate display (if I read that correctly?). At any rate, with the re-write, I'm not sure... It might be really hard to work with the menus without displaying the octave somehow.

New possibility

Hello Basil,
I made a carbon hg, and I added to the standard keyboard, John's dg mechanism with switches, but it takes too much thickness, and above all I would like to be able to adapt it to the other hgs of other players , that's why I started but not yet finished the prototypes of the pcbs, with 25 and 31 keys.
For future use, knowing that I have no motor on the crank, so no detection, no knob needed.
Need:
-Possibility to play with the current DG like the version of John's software or your new software by pressing the gaming button, and thus having the open string active, and the choice of "with or without" drone (included in the software or on Bismark 16.i)
-Possibility by pressing a new button to be able to play without the drones or not (modifiable), and with an additional key on the key box which replaces the lowest note (open string), and thus to have the DG in accompaniment of the game of the HG, the open string will come from the HG, (or from the additional key) and the other notes played would come from the DG and the HG, and therefore to complete the music because with the DG have little add other instruments by other soundfonts.

I had bypassed John's software by lowering the open string to zero, and added a G4 key, on pin 38, it worked, we always want to do better, currently I have to change the software according to the use.

I hope to make myself understood, I am available for more information.
Greetings
Herve

Feature: Up/Down transposing

Multiple people requested up/down transposing on the digigurdy.

I’ll incorporate this into the tuning menus somehow for all kinds of digigurdy. Perhaps after the selection of strings, the summary screen would let you hit ok or go back, and additionally let you move everything up and down. I don’t see a reason to not go ahead and support moving up and down an octave total in half-steps to make basically make playing in any key possible (as opposed to just a couple whole steps up and down or something).

For digigurdies that have the octave down/up buttons, maybe this should be their on-the-fly option. Would want to re-think how the display works during play to not only show the note being played, but a little “status bar” showing where you’re at in terms of capo steps, listing of what that makes the strings currently.

I’m putting this down with the 1.5 milestone, but who knows… might bump it up.

Needs an "about" screen

suggest under the other options menu as option 2 for remove crank is option 1?
Needs to have the version number easily getable in case of any issues...and especially with the frequency of updates you're posting..I'm struggling to keep up today ;-) Awesome work thank you. I just need to find a better sample from a C1 drone

Feature: on-screen display of current settings

I mentioned this in another issue, but just to give it a spot...

Per-request, list the current tuning/setting being used on-screen during play.

This should be easy to include in the step that displays the on-screen note being played.

Since we will be using part of the display, I don't know yet if I can display a bitmap on part of the screen along with text. I think I'll have to either:

  • re-do all the bitmaps to fit in a smaller area (truth be told... I probably won't do this on my own, but I'll look into it if someone else wants to make the bitmaps)
  • Settle for all-text on the display during play.

Feature: Crank redetection?

Right now the setup() includes a step that samples the crank voltage for a few seconds, and calculated how much that voltage is wandering. An unconnected pin’s voltage will wander significantly more than the crank plugged in but at rest, and this is how digigurdy detects its crank at startup.

It’d be cool to find a strategy for 1) gracefully recognizing when the crank becomes unplugged, and 2) periodically check when the crank isn’t plugged in to see if it’s there now. In other words, support docking and un-docking with the crank on-the-fly.

I’m not sure how to periodically sample the crank without interrupting play. It’d have to be built into the loop() (i.e. sampling as it goes, not the loop with delay() that we have now).

A compromise that shouldn’t be as bad is a menu option to just tell the digigurdy to re-detect or disengage the crank when you want to dock/undock it.

No milestone for this one… still mulling over it. Right now the crank is annoying me in the rewrite code :-)

Menu options

Working through , so please leave this comment live, more to come!!
When I select a preset the go to turn off the drone and/or trompette the screen is cluttered, and the only way to continue appears to be save tuning, as the O button is toggling back the drone/ trompette ???
Think given that we have limited lines needs a little more ergonomic planning..
Also is there a way please that the preset tuning's "titles" as well as designated notes can all be in the default tunings subfile?
While it is very simple to change the preset , having to go back to main code to change it's displayed "title" seems a tad onerous??
More to come on this menu stuff, sorry
David

not playing or displaying correctly

ver 0.9 No matter which tuning I select, when I go to play it shows the open string as C#-1 and almost random tuning display
EG G/C **selection each time C Gg C tuning (Tromp, Low chanter, High Chanter, Drone) Shows
Tpose +67 Capo +7
hi melody F#0
low Melody #F-1
Trompette B5
Drone B2
I've tried other tunings with similar results
Works perfectly on parsed ver117

Looking forward… v2.0

V1.0 is coming up soon, time to start thinking about where to take it from here…

  • Code improvement: In re-writing the code I created classes like a good boy for many of the gurdy functions, but a lot of the logic is still bare in the loop() and setup(). Some things appear in odd places in the code for the sake of being defined in the right order. This can all be a little better. I’d like to extend what the HurdyGurdy() class does to manage more of the playing logic. Before it gets out of hand I wanna tighten it up some more.
  • More strings: We’ve got two more channels. I want them to be optional drones OR chanters. I’ve done more playing around with scale tuning on bs-16i and I think they can be useful.
  • Improved menu interface: Besides tuning, the menu could be more sophisticated. Multiple save slots. String on/off functions. MIDI volume adjustment. It could handle a lot more with some planning.
  • “Official” Teensy 4.1 support. 4.1 should be able to work as a drop-in replacement on DigiGurdies for the 3.5 they’re normally built with. I’ve got one report that this code works on it, and I ordered my own unit to test. This will not only give makers more flexibility, but users can more easily replace their units, and in the future the improved speed and power of the 4.1 may come in handy.

I’ll flesh this out more later, just getting thoughts down on “paper”.

Use non-deprecated method of declaring screen size

The SD1306 header currently requires the user to edit it to select the correct 128x64 screen size. By default the header uses 128x32.

I should mention this in the install notes... but the header also specifies that this is the deprecated way of doing it.

I want to find the "right" way to do it and do that.

MIDI over Serial ..little confused on declaration in code

Just putting serial midi ability into another of my projects and noticed an anomaly in the digigurdy code.

you call these two lines as an example
usbMIDI.sendNoteOn(note_being_played, midi_volume, midi_channel);
this is one you appear to have declared, as you say teensy doesn't recognise MIDI...it does see below
MIDI_obj->sendNoteOn(note_being_played, midi_volume, midi_channel);

This is how I added the serial command to John's code so we could use a 5 pin midi and BT dongle, it works ????
MIDI.sendNoteOn(note_being_played, midi_volume, midi_channel);

Teensy 4.1 -- crank/buzz acts strange

Got a Teensy4.1 to try out.

DigiGurdies have been Teensy3.5 so far, but those units are currently in extremely short supply due to the chip shortage and it's unclear when they'll be available again. Since Teensy4.1 is not much more expensive, faster, available, and the same form-factor, it'd be nice if they could be both supported.

After installing on the 4.1, everything looks ok in terms of the pin assignments and core functions. However, the crank/buzz is off. I notice that it seems to get "stuck" for a few seconds after cranking sometimes. This behavior in turn affects how the buzz behaves (it doesn't work during this sticking event).

I've noticed more minor behavior like this on the 3.5, that I initially wrote off as motor funkiness, so hopefully I'm killing two birds here.

There's a few things to explore here:

  • I'm running the teensy4.1 at full speed, which is over 4x faster than the 3.5. If I ramp this down to 3.5 speeds, I wonder if that affects anything.
  • I need to make some debugging messages to see what exactly gets stuck during these events. I'm not sure if the motor wigs out, if my "spin" algorithm gets stuck somehow, or what.

I'll try to debug and find what's happening and then fiddle around with fixing it.

@Gubbledenut is this the sort of crank behavior you're getting or something else on your 4.1 unit?

new idea

Hi,

This night a new idea.

-possibility to change on fly with little delay, or not ( as it's possible) to change one slot of the 4 previous slot save before ( possible or not)

in my project i see the possibilty to add note, thanks Basil, can you add just a button to have "on open string" and "off open string" in hard by comment or uncomment or "on fly" by button alwaws in choise ( the better for me), sorry to have some need, i can do lot of thing,

Sorry (David), or Gubbledenut, i am not a professionnal luthier, i am a noob in this way, i do lot of things for my pleasure, old car, built house, workshop, cnc, 3d printer, i prefer to built than use, i am poor man to be a creator, but i can help for other tings.......i do my hurdy gurdy with the help by Seb Tourny Luthier in La Chatre 36400.

do you thinks if we use male pogo pin for connect under teensy, good idea or not, in this case easy to connect, and easy because removable, no soldering.....

like this
image

0.9.8 Button 6 issue

Button/option 6 doesn't seem to be working in the trompette selection screen
Everywhere else it seems fine, and it's playing so not my hardware!
Very much like the new display by the way...

Feature: More strings!

Teensy3.5 should support 16 MIDI channels, 8 in, 8 out.

Digigurdy has four string channels, one for the keyclick, and one for the trompette buzz.

Little math here...

  • 4 + 1 + 1 = 6
  • 8 - 6 = 2
  • 2/6 * 100 == 33%

Therefore it looks like it could be up to a third more awesome if we made use of those channels :-)

Adding the extra string and using another channel shouldn't be too hard. What will be hard is how to handle tuning options for it without it becoming a mess. Other questions...

  • Does the fact that the notes are perfectly in tune detract from the extra presence that multiple strings make? Would more just get lost in the harmonics or really sound like more strings? I think MIDI notes can be microtuned... would intentionally making the tuning slightly imperfect yield a more realistic-sounding result?
  • Beyond what's possible in a 2-2-2 setup, how are more elaborate gurdies set up? Research into how they are used may lead to refinements in how to use four drone channels together.

This issue might stick around for a while but it's on my mind.

Support Program Change to indicate saved tunings

As bs-16i supports changing scenes based on a Program Change message sent via midi, I would like to have changing the saved tuning on my gurdy automatically change the scene in bs-16i.

This would be a new top-level option (saved to the EEPROM). When set, the index of the saved tuning (probably 0-3 for presets 1-4 and 4-7 for user slots 1-4) would be sent along midi channel 1 as a program control message.

(My intention is to write this feature myself, but I'm cutting an issue to track the request and let people comment on it.)

BUG: EEPROM needs to be cleared before use on many digigurdies

Two different issues were ultimately solved by clearing the EEPROM:

#23
#21

I don't know exactly where this is causing problems, but it's clear that it's doing something. I am using the EEPROM to store different values than John did, but I thought that mine would simply overwrite them, and that they wouldn't lead to these bizarre things.

I think I could fix the actual problem of funky EEPROM messing up digigurdy-baz, but at the same I noticed two other issues:

  • I am writing int to EEPROM. These are 16-bit values. They should be bytes, 8-bit values. Gotta fix that, and it could be part of this whole issue.
  • The logic forces you to save when you choose a new setting, so it's faulty in how it works.

I'm going to create an eeprom.h header and a rough structure to hold several sets of tunings, in anticipation of supporting multiple saved tunings.

In addition, I'm going to re-work the save scheme to support it, and support tuning without saving.

And finally, I'm going to create an option to clear the EEPROM--which fixed things in both these cases.

TODO: reformat

Code contains a lot of blank lines and funky indentation. I’d like to get it consistent for readability.

option 1 not working on note selection screen

I selected option 2 Big note on the Playing screen,
It now won't let me select option 1 Big note and Staff
It seems just to be button one wrong there, everywhere else button one works.
Ver 1.2.6

just a tiny bit of moving around please

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 <Adafruit_GFX.h>
14 // https://www.pjrc.com/teensy/td_libs_Bounce.html
15 #include <Bounce.h>
16 #include <EEPROM.h>
17 // https://www.pjrc.com/teensy/td_midi.html
18 // https://www.pjrc.com/teensy/td_libs_MIDI.html
19 #include <MIDI.h>
20 #include
21 #include <ADC.h>
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 <Adafruit_SSD1306.h>
38 #endif
39 #ifdef BLUE_OLED
40 #include <Adafruit_SH1106.h>
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

Some digigurdies hang after crank detection

John Dingley is running into an issue on his digigurdy where the code is getting stuck after the crank detection.

Need to investigate what's happening here, as it doesn't match what my (John-made) digigurdy does. But John provided me with a video that gives some clues as to where the hiccup is.

Also pointed out that I should probably include a screen informing the user of crank detection results.

Including with the v1.0 stuff as it's critical: if one of John's digigurdies behaves this way, others may, too.

BS16i Scenes issues

Tried to load run your two BS16i plists, they look for sf2 files apart from ViennaAlto.11 which most will not have..so I have odified the plist to remove all but viennaAlto 11..loads fine now
...I do have the raw Wav files for the French 2 , ViennaSoprano and Keyclicks but not the SF2 files , so if you want to upload those here too that would be wonderfu
Screen Shot 2022-03-12 at 14 07 42
l

Pseudocode digigurdy

In order to plan out the rewrite better, it would be good to sketch out the basic logic of the entire thing.

Feature: Crank redetection?

Discussed in #48

Originally posted by bazmonk March 1, 2022
Right now the setup() includes a step that samples the crank voltage for a few seconds, and calculated how much that voltage is wandering. An unconnected pin’s voltage will wander significantly more than the crank plugged in but at rest, and this is how digigurdy detects its crank at startup.

It’d be cool to find a strategy for 1) gracefully recognizing when the crank becomes unplugged, and 2) periodically check when the crank isn’t plugged in to see if it’s there now. In other words, support docking and un-docking with the crank on-the-fly.

I’m not sure how to periodically sample the crank without interrupting play. It’d have to be built into the loop() (i.e. sampling as it goes, not the loop with delay() that we have now).

A compromise that shouldn’t be as bad is a menu option to just tell the digigurdy to re-detect or disengage the crank when you want to dock/undock it.

No milestone for this one… still mulling over it. Right now the crank is annoying me in the rewrite code :-)

fatal error (missing headers during compile)

today i try to upload on teensy 3.5 but fatal error
image

the error is

Arduino : 1.8.13 (Windows 10), TD: 1.56, Carte : "Teensy 3.5, Serial + MIDI, 120 MHz, Faster, French"

C:\Users\Hervé\AppData\Local\Temp\Temp1_digigurdy-baz-main (2).zip\digigurdy-baz-main\digigurdy-baz\digigurdy-baz.ino:123:46: fatal error: bitmaps.h: No such file or directory

compilation terminated.

Erreur de compilation pour la carte Teensy 3.5

Ce rapport pourrait être plus détaillé avec
l'option "Afficher les résultats détaillés de la compilation"
activée dans Fichier -> Préférences.

Menu display suggestion

Have one line along the top with the tuning showing in format C Cc C only as in trompette low hi chanter drone
If one or the other is muted , it can be designated "0" So it would read 0 Cc C if the trompette is muted
Could include the Midi pitch ie C3 C3c4 C2
Will try to see it transpose and capo stay will fit eg.
T-12 C3 C4c5 C2 C+1
The rest of the display can be used to show note being played ,either text or txt and bitmap???
I will do some testing on the code this weekend, to see how things fit

Bug: buzzing noise breaks down if trompette is low

Currently the root note of the buzzing sound/channel is kept in sync with the trompette channel. This makes sense, but if the trompette is set to a low note, the buzzing sound slowed down to that frequency breaks down and stops sounding like a buzz.

Since the buzz is otherwise independent of the "trompette" channel, that channel is sorta just a second drone. It would be nice to be able to use it as a drone lower than one may realistically use as a trompette string on a real gurdy.

So...

  • Research - I need to try out all the provided drone sounds and find the range they're usable. Determine a range that works for all of them.
  • Fix - Add logic that sets the buzz note to a higher octave or harmonic if the trompette is set below that range.

Getting occasional note stuck on, do we still have the MIDI-all-stop after crank stopped for >3s as in earlier versions?

I am seeing occasionally that the melody note on Channel 2 gets stuck on even when cranking has stopped and all other channels are silent (using a Teensy 3.5). In older code versions there was a MIDI-kill feature that turned off all 6 channels if cranking had stopped for more than 3 seconds (there is a MIDI cc command that has this function) which stopped this ever becoming really annoying. I wonder has that been taken out of this latest code version 1.4?

Small thing regarding display of channels to avoid any confusion:
Also when you select a preset, it lists them in the order melody, melody, drone, tromp and then once you have actually confirmed your selection, it lists the channels in slightly different order as melody, melody, tromp, drone. When you set up your iPad running the bs-16i app, you need to set up the first 4 channels as: Ch1 melody, Ch2 melody, Ch3 tromp, Ch4 drone, i.e. the same way they are listed in the final screen display after you have confirmed the preset you definitely want. It might be best to always list the channel settings in all the OLED screen displays in the order of melody, melody, tromp, drone to avoid any confusion when setting up the bs-16i channels, or even better if space allows Ch1mel, Ch2mel, Ch3Tromp, Ch4Drone or something along those lines.

BUG: Crank detection works, doesn't treat it right

The crank detection algorithm works fine, but the logic of what to do in the event of not having one doesn't work as-is.

It screws up when strings up in/out, as well as the buzz (with no crank it reports random buzzes).

Because I already know from testing that it works fine if the crank is installed but I simply never use it, what I can do to fix this is override the isSpinning() and whatnot functions to make them just report the crank being off and not buzzing when the crank is disconnected.

It's just too late to do it tonight and I'm sleepy...

Rewrite Digigurdy

Large portions of the codebase should be re-written in a more modular, object-oriented way in the interest of long-term maintainability and usefulness of the code.

I think this should happen before significant new features are added, as it will only make doing it later more difficult.

To that end, I'm considering these issues as basically build-up to that.

  • #8
  • #6 (comment cleanup)
  • #5 (breaking the bitmaps off to a separate file)

Feature: break up code into multiple files

Digigurdy is over 11,000 lines of code.

For organization and readability I would like to split the codebase up into three files:

  • The initialization, crank detection, MIDI setup, icky details.
  • The main program logic, tuning menu (the user interface)
  • Data: bitmaps mainly

Recording

I think it would be useful for learning, to be able to record songs playing, to later accompany them with the crank while they play, or accompany playing with a string.

Raspberry pi synth concepts

The basic samperbox code doesn't support multi channel midi, but it does work using a simple 7 segment display and two buttons to switch samples, with no code or config changes. The advantage is that everything can be powered from a single usb source , multiple samples loaded and chosen, output through the inbuilt day to headphones or speaker.making it totally stand/play alone

More recent versions of Samperbox require config adjustments to run, which have so far eluded me to get working
Running Fluidsynth on a pi4 with a simple gui, maybe for testing using a second 1306 oled display and some buttons to allow to select and adjust the levels of the 6 channels as used in bs16i. it was the original setup on android devices, using it's fluidsynth front end version.
Alternatively this may be an option as a pi "hat" includes 4 buttons, an oled and a better DAC, I imagine bluetooth speaker capability would also be possible through the pi? https://shop.pimoroni.com/products/pirate-audio-line-out?variant=31189750546515

Feature: tweak/reorganize drone/trompette tuning choices

Suggestions below for menu orders...little more logic, Also suggest a 9. G2/D3 to replace current 9. G3/C4 very often used playing in G on a G/C gurdy
//Suggested G/C Menu Order
" Select Drone/Tromp: \n"
" 2. C2/C3 | 10.G3/G4 \n"
" 3. C2/C4 | 5.G2/G3 \n"
" 1. C2/G2 | 4.G2/C3 \n"
" 7. C3/G3 | 6 G2/C4 \n"
" 8. C3/G4 | 9.G3/C4 \n"

	  Sugggest 9 is changed to G2/D3
	  
	//Suggested D/G Menu Order
	 " Select Drone/Tromp: \n"
	 " 2. D2/D3 | 4. G2/D3 \n"
     " 8. D3/D4 | 6. G2/D4 \n"
	 " 1. D2/G2 | 5. G2/G3 \n"
	 " 3. D2/G4 | 9. G3/D4 \n"
	 " 7. D3/G3 | 10. G3/G4 \n"

Feature: Comment cleanup

Code has a lot of comments in it. A lot of this is valuable information. A lot of it are snippets of old/unused code, or works in progress (sometimes hard to tell).

I'd like to work through it and:

  • Move the valuable information to documentation pages.
  • Remove unused code. It will be preserved in the repo if it's needed later.
  • Rewrite/move/loosely-standardize the rest.

This should be done before #5 I think.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.