You should see the Blokas logo after doing Burn Bootloader. Uploading sketches via the bootloader & USB should keep it there.
This does show though that the issue lies somewhere else than the chip itself. I have double checked your photo of components again and I still can’t spot anything wrong there. Of course inspecting photos is not the same as the real board itself. 
Could you post another photo of circled area at an angle, both sides of the board?
Here are the close-up photos:
Also, not sure if this is relevant, but when I upload the Midiboy bootloader using the UNO ISP I get some avrdude warnings in the log that seem to be related to fuses. For example:
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: reading input file “0xFF”
avrdude: writing lock (1 bytes):
*Writing | ***failed; *
################################################## | 100% 0.07s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xFF:
avrdude: load data lock data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lock data:
*C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v1 -PCOM6 -b19200 -Uflash:w:C:\Users\Stephen\AppData\Local\Arduino15\packages\Blokas\hardware\avr\1.0.6/bootloaders/Midiboy-Bootloader/Midiboy-Bootloader.hex:i -Ulock:w:0xFF:m *
Reading | ################################################## | 100% 0.01s
avrdude: verifying …
avrdude: WARNING: invalid value for unused bits in fuse “lock”, should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0x3f instead of 0xff (double check with your datasheet first).
avrdude: 1 bytes of lock verified
avrdude: reading input file “0xFD”
However avrdude still finishes the bootloader upload process with the message “avrdude done. Thank you.” and no errors are reported.
I’ve been playing around with a sketch located here (Gammon Forum : Electronics : Microprocessors : Sketch to detect Atmega chip types) that returns info on the bootloader and fuses etc. It seems that when I upload the Midimon sketch the Midiboy bootloader gets wiped. But when I re-flash the Midiboy bootloader, the Midimon sketch gets wiped. I can’t seem to get both the bootloader and the sketch on the chip at the same time using the UNO ISP! (note that when the Midiboy bootloader has been flashed, I get the Blokas logo on the Midiboy screen but still get the “Unknown USB device” when directly connecting the Midiboy via USB to Windows)
Perhaps this has something to do with it?
Here is the output from the Gammon sketch after flashing the Midiboy bootloader:
Atmega chip detector.
Written by Nick Gammon.
Version 1.20
Compiled on Mar 10 2021 at 10:31:16 with Arduino IDE 10813.
Attempting to enter ICSP programming mode …
Entered programming mode OK.
Signature = 0x1E 0x95 0x0F
Processor = ATmega328P
Flash memory size = 32768 bytes.
LFuse = 0xCE
HFuse = 0xD8
EFuse = 0xFD
Lock byte = 0xFF
Clock calibration = 0xAB
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 4096 bytes starting at 7000
Bootloader:
7000: 0xB3 0xC0 0x00 0x00 0xF0 0xC0 0x00 0x00 0xCA 0xC0 0x00 0x00 0xC8 0xC0 0x00 0x00
7010: 0xC6 0xC0 0x00 0x00 0xC4 0xC0 0x00 0x00 0xC2 0xC0 0x00 0x00 0xC0 0xC0 0x00 0x00
7020: 0xBE 0xC0 0x00 0x00 0xBC 0xC0 0x00 0x00 0xBA 0xC0 0x00 0x00 0xB8 0xC0 0x00 0x00
7030: 0xB6 0xC0 0x00 0x00 0xB4 0xC0 0x00 0x00 0xB2 0xC0 0x00 0x00 0xB0 0xC0 0x00 0x00
7040: 0xAE 0xC0 0x00 0x00 0xAC 0xC0 0x00 0x00 0xAA 0xC0 0x00 0x00 0xA8 0xC0 0x00 0x00
7050: 0xA6 0xC0 0x00 0x00 0xA4 0xC0 0x00 0x00 0xA2 0xC0 0x00 0x00 0xA0 0xC0 0x00 0x00
7060: 0x9E 0xC0 0x00 0x00 0x9C 0xC0 0x00 0x00 0x7E 0x3F 0xF9 0xF7 0x6A 0x39 0xF9 0xF7
7070: 0x56 0x35 0xF9 0xF7 0x40 0x38 0xF9 0xF7 0xEC 0x2D 0xFD 0x2D 0xB7 0xB6 0xB0 0xFC
7080: 0xFD 0xCF 0x27 0xBF 0xE8 0x95 0xB7 0xB6 0xB0 0xFC 0xFD 0xCF 0x21 0xE1 0xB7 0xB6
7090: 0xB6 0xFC 0xF4 0xCF 0x08 0x95 0x04 0x03 0x09 0x04 0x1C 0x03 0x77 0x00 0x77 0x00
70A0: 0x77 0x00 0x2E 0x00 0x66 0x00 0x69 0x00 0x73 0x00 0x63 0x00 0x68 0x00 0x6C 0x00
70B0: 0x2E 0x00 0x64 0x00 0x65 0x00 0x0E 0x03 0x55 0x00 0x53 0x00 0x42 0x00 0x61 0x00
70C0: 0x73 0x00 0x70 0x00 0x12 0x01 0x10 0x01 0xFF 0x00 0x00 0x08 0xC0 0x16 0xDC 0x05
70D0: 0x02 0x01 0x01 0x02 0x00 0x01 0x09 0x02 0x12 0x00 0x01 0x01 0x00 0x80 0x32 0x09
70E0: 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1F 0x07 0x03 0x01 0x01 0x00 0x00 0x00
70F0: 0x00 0x00 0x01 0x01 0x03 0x07 0x1F 0xFF 0xFF 0x1F 0x07 0x03 0x01 0x01 0x00 0x00
7A70: 0x0F 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
…etc…
7FF0: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
MD5 sum of bootloader = 0x88 0x8A 0xBA 0xB4 0xAD 0xC5 0x22 0xF3 0x1F 0xEA 0x81 0x26 0xFE 0x71 0x7C 0xA2
Bootloader MD5 sum not known.
First 256 bytes of program memory:
00: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
…etc…
F0: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Programming mode off.
This is expected - the default state normally would be for the bootloader to be in the chip’s memory, further flashing is supposed to occur via the USB, bootloader would write the incoming program at the correct location in order not to write over itself. 
I’ve looked through the new pictures and I don’t think I can see anything wrong there. Maybe there’s a little bit more than necessary solder on the diodes, but I doubt it’s easy to damage these components.
Do you have a multimeter with continuity test?
Yes, I’ve got a Fluke 106 multimeter
Okay, so I finally got everything working!
It seems the USB device is only recognised on a USB 2.0 port (or below?). All the USB ports on my 2 Windows PC’s must be USB 3.0. So I dug out a very old USB 2.0 hub I had lying around and connected the Midiboy via the USB 2.0 hub. Uploading sketches via the Arduino IDE using USBasp failed, so I then had to install the Zadig USBasp driver to get Windows 10 to “see it” properly, and hey presto, it worked! 
Good to hear it finally gets recognized at least with a hub in between!
It does work with USB 3 ports on my computer though, so the underlying issue why it doesn’t get recognized by your computer directly must be something else…
Built my MIDIboy today and I had the same problem with a not properly recognized USB device on Linux. The port showed up, but with loads of kernel errors. The described solution of using a USB 2.0 port solved my problem. I actually just put a cheap (unpowered) USB 2.0 hub between the MIDIboy and the computer, and everything works. As USB connectivity problems seem to be common with this otherwise awesome kit, I think it might be good to have an “official” USB troubleshooting page / link somewhere, that lists possible solutions to this problem. Maybe the “Midiboy Software” section would be a good place for this ?
We don’t yet know well enough how often such issues occur, and whether the same solution(s) apply, so currently we’d prefer users contacting us directly or posting here, so we can help troubleshoot, and at the same time get a clearer picture of the situation.
I’m having this problem with my new Midiboy on MacOS (Ventura). Compile works fine for midimon, for example, but upload has the following error. I’ve tried USB 3 and USB 2 hubs. This is Arduino IDE 2, but the same error on the legacy IDE. No USB port shows up when turn the midiboy on. Any ideas?
Using Port : USB
Using Programmer : usbasp
Overriding Baud Rate : 115200
avrdude: error: could not find USB device with vid=0x16c0 pid=0x5dc vendor=‘www.fischl.de’ product=‘USBasp’
avrdude done. Thank you.
Failed uploading: uploading error: exit status 1
Does the Blokas logo appear in Midiboy when it’s powered on? Usually these USB connection issues are caused by some physical fault in the electronics, please double check all the areas marked in this post: USB Device Not Recognised - #5 by Giedrius
You may post photos of your board here for inspection.
Thanks for your quick reply! Here are photos. The Blokas logo appears with a short blink when I turn Midiboy on. When I hold the “B” button down, when I power on, the logo comes on without the blink.
I searched the forum and saw that it’s usually a physical problem. I’ve tried everything I can think of, but I’m famous for overlooking the obvious! So far I’ve:
All with the same results.
I looked at trying to slow down the speed of the USBasp transmission, but Arduino hides this pretty well and I haven’t found the right place to adjust it.
So, if you can see my problem or have any other ideas, it might keep me from going crazy today!
OK. Today is not the day I go crazy, apparently. I just tried another USB 2.0 hub and I’m finally able to upload sketches!
One very small thing that now comes up is that I just tried flappy ball and the sound is barely audible, is that normal? (not that games are my priority, but just thought I’d check )
Good to hear you got it working. Yeah, the USB communication is implemented in software via GPIO pin bit banging, as the ATmega328P does not have a peripheral dedicated to USB communication, so it can be a bit sensitive to some USB setups.
The buzzer is sort of dimmed a bit by design, we chose a preset value that’s not too loud, so it doesn’t become annoying too quickly.
Thanks! Yeah. The USB can be a challenge until you figure out what works with your system, but using software, it’s pretty amazing what you’ve been able to do with a relatively simple (and inexpensive) product!
