Just a dump of random text file notes - please don't judge :)

understanding usb:
https://www.beyondlogic.org/usbnutshell/usb1.shtml

teensy midi stuff
https://www.pjrc.com/teensy/td_midi.html

arduino pro micro would be way cheaper, or maybe this guy's v-usb solution would work:
https://www.arduino.cc/en/Reference/MIDIUSB
https://github.com/arduino-libraries/MIDIUSB
https://www.musiconerd.com/single-post/arduino-pro-micro-as-a-usb-midi-device

notes on v-usb:
think recent changes in windows make it necessary to use a 16MHz crystal; RC oscillator not good enough
https://forums.obdev.at/viewtopic.php?f=8&t=9959
crystal osc seems to let windows enumerate pretty consistently; so not a driver problem

v-usb using arduino IDE?
https://mitxela.com/projects/midi_on_the_attiny
https://github.com/TechFactoryHU/vusb-arduino

various foot pedal designs (3d Printed)
https://www.myminifactory.com/object/3d-print-foot-pedal-for-sewing-machine-or-other-electronic-products-72847
https://remoteqth.com/3d-ptt-foot-switch.php
https://pinshape.com/items/41515-3d-printed-throttle-pedal
https://www.instamorph.com/ideas/electronics/midi-foot-controller <-- hand-shaped thermoplastic

velocity sensitive keys:
http://www.openmusiclabs.com/learning/digital/input-matrix-scanning/keyboard/
http://www.codetinkerhack.com/2013/01/how-to-add-velocity-aftertouch-midi.html
https://lastminuteengineers.com/fsr-arduino-tutorial/

2020.10.13
got a modified version of 1-key keyboard working on an attiny85
had to steal osccal calibration routine from codeandlife easylogger mod
works fine (mostly) when connected to linux box (A+ gave me trouble, maybe because OTG port?)
on windows, had to use inf wizard bundled with libusb-win32 .. actually not sure if that actually helped or if it was just plugging it into random usb ports until it worked. Maybe the crystal oscillator is needed...  could try another 1-key using crystal as clock source

2020.10.14
okay - windows (multiple different machines!) seems to recognize just fine with a 16 kHz crystal - even came up as "1-key keyboard" somehow. response of 1-key keyboard is a bit slow, but that might be some issue with the debounce routine. also look into what crystal is best - most example seem to use a 12kHz crystal, ns why

2020.10.21
learned a lot from reading comments/doc in usbconfig.h etc
got a somewhat working version - recognized by windows (usually), shows up in midi-ox but drops lots of messages and loses connection
check out this example: https://github.com/wzab/midi-expression-pedal
https://web.archive.org/web/20190910125700/http://wzab.cba.pl:80/STARE/MIDI/pedal/index.html

2020.10.22
fuses low, high:
latest attempt: df, de -- crystal, pwr/reset 16K + 0ms, bod 1.8v
vusbmidi: 9f, c1 -- crystal, pwr/reset 16K + 0ms, bod 4.3v, preserve eeprom, wtdon
phi-T: ef, d9 -- crystal, pwr/reset 16K + 4.1ms, bod 4.3v
latest attempt: ef, dc -- crystal, pwr/reset 16K + 4.1ms, bod 4.3v, wdton
maybe steal digispark bootloader and use this:
https://github.com/heartscrytech/DigisparkMIDI
latest attempt: ef, dd -- crystal, pwr/reset 16K + 4.1ms, bod 2.7v

2020.10.25
nothing works or is recognized by usb at all any more
first attiny85 seems to be dead- can't program any more
messed up a second one by trying to program fuses with ground disconnected
third one messed up when I switched d+ and d-
got fourth to work once on Windows, seems to work ok on linux but trying to check if MIDI is received
this is not going well
I think the programming fuse got reset on all my attiny85s somehow, can't talk to any of them
I have one that is recognized as a midi device by windows and linux, but can't reprogram it
butts
maybe I'll give up and do this on an arduino pro micro, but for now let's try on atmega328p and work on getting the code right - need proper debounce and vusbmidi code could be cleaned up..
for timers : https://exploreembedded.com/wiki/AVR_Timer_programming

2020.11.24
debouncing:
https://embeddedthoughts.com/2016/06/10/attiny85-debounce-your-pushbuttons/

2020.11.28
did a simple debounce button toggle LED on and off and it works
- next try flashing it on the "dead" attiny's? just to see if they're dead
- try to incorporate the debounce into the MIDI button code
- test vusb in arduino -- techfactory's v-usb port to arduino
  - doesn't seem to work on attiny85 or atmega328p - not recognized and disconnects and reconnects endlessly, not seen at all on linux

2020.12.02
ok swear it's working for real now
carefully rewrote the code with a timer interrupt for button debounce
added 10uF capacitor from 5V to ground, plus 10k from reset to 5V - not sure if needed, found a hookup wire with a loose pin was causing a lot of problems
connection isn't 100%, but I think that's b/c USB is sensitive to wiggles from breadboard components - PCB/perfboard should be fine

2020.12.23
PCB seems to be working, but had to re-flash attiny for some reason
note: when connected through USB hub (perixx keyboard at least), device enumerates but MIDI messages are not received

2020.12.27
got it all working, batch messages and everything:
Ch1 CC 64 (hold pedal) momentary
Ch10 Note 36 (kickdrum)
Ch15 CC 16 momentary
Ch15 CC 17 toggles
Ch15 4-note pattern: 36 (kick), 46 (open hihat), 38 (snare), 51 (ride)

2020.12.30
seems to hang once in a while on raspberry pi - I think this is something to do with the Pi handles some of the USB stuff in software b/c it's actually using the USB-OTG on the BCM chip. When it hangs dmesg gives an urb error -32 which is EPIPE - broken pipe. Implemented watchdog on the attiny85 but it doesn't seem to fix the problem, which makes me think the stall is on the Pi's side and I can't do too much about that afik - not going to worry about it for now as it seems to not occur too often and you can just replug the USB
wonder if this happens with teensy pedal or arduino pro micro?
note as of 26 feb 2022 my teensy pedal is acting crazy..

2022.02.25
yes still working on this
it's a linux problem - not just raspberry pi. something kernel-related maybe, so unlikely to be fixed soon if ever. would have to dig into USB to really understand it.
going to try sending just one message per button press/release
just send hold cc (64), with different values that can be mapped to toggle, pattern, etc.:
70, 0, 100, 30, 85, 15, 115, 45, 75, 5, 105, 35, 80, 10, 110, 40
also will try not using timer interrupt
https://github.com/raspberrypi/linux/issues/4597
https://stackoverflow.com/questions/14312988/why-is-my-kernel-module-throwing-broken-pipe-errors-when-i-try-to-write-to-a-d

2022.02.26
brown-out detector and new single message scheme seem to help
links above seem to point to a power issue exacerbated by kernel, i definitely hear a power glitch sometimes when it stops working
if user gets lots of disconnects recommend connect via usb hub - should probably test