Hawkeye Posted July 12, 2020 Author Report Share Posted July 12, 2020 @j4ustin if some of the switches on the encoders and on the Matias pins work, it would be interesting to know which ones don't work, this will help localize the associated problematic input shift register (or associated resistor network) on the Plate PCB, which could then be checked for unwanted solder bridges between IC pins or missing contacts from the IC pins to the PCB. As your OLED works now, every encoder switch press or "simulated" Matias switch press with a jumper wire should output which button # was triggered. If all of your button presses are working, but only sometimes, it could also be a connectivity problem of the headers - you could use a DMM to check for proper uninterrupted top/bottom header connectivity, @latigid on should be able to tell you which pins you could best check to test the way back e.g. from the first 74HC165 in the chain to the Waveshare board. Best regards and good luck! Peter Quote Link to comment Share on other sites More sharing options...
j4ustin Posted July 12, 2020 Report Share Posted July 12, 2020 None of my buttons or encoders are registering. I validated that all of the headers are making contact from the bottom of the board to the top, and i can trigger a button press by bridging the top two pins on the j9a header so I know that the button presses can work. Nothing from the encoders though. I'm going to keep checking where the connections could be failing. Any pointers here would be excellent, feel like I'm one step away from this thing wrapping up. Quote Link to comment Share on other sites More sharing options...
latigid on Posted July 12, 2020 Report Share Posted July 12, 2020 Glad that the OLED issue is solved! Could I ask where/how the broken trace originated? For the DIN problem, you can recheck the soldering on Core IC1B especially pin 13 (RC2). Make sure that you get contact all the way through the header when the sandwich is assembled. Please reflow the joints to get "volcanoes" rather than "balls". You will have to be careful not to move the individual pins around because the plastic part that normally holds them together is gone. My approach to soldering the J89 pin header is different to Peter's. I found that you don't have to push the pins all the way to the bottom of the corresponding socket on the Core and there is no need to remove the plastic. The plastic prevents solder flowing through the holes and making blobs that might short out other pins. ----- if you have any spare 2.54mm pin sockets you can use this temporarily on the long end to hold them together. On the Plate PCB can you provide the part number of the resistor networks? If it is an isolated type the DINs will not work. The orientation is also important. Quote Link to comment Share on other sites More sharing options...
j4ustin Posted July 12, 2020 Report Share Posted July 12, 2020 Made a critical mistake during the build and missed soldering in the sockets on the core pcb and, instead, soldered in the actual pins from the top board. This led to having to remove the pins via de-soldering and I knicked (likely with my cutting tool) the board just above j15C header causing the issue. That was the only de-soldering I've had to do on the board at all, should have paid closer attention to the instructions at the beginning of the video. Didn't spot this broken trace as it was kind of hidden by the socket. I've double checked all the sockets for any other knicks that may have happened. I've tested for continuity from the bottom of base pcb socket pins to the connected plate pcb pins on top and there is connectivity between all the pins. I'll double check for any shorts between them. I'll go back through and fix the soldering on those pins This is the resistor network I've put in place on the plate PCB: https://www.mouser.com/ProductDetail/652-4816P-T2LF-10K. I'm sure aligned the dot correctly with what is on the silkscreen, and have verified by re-watching the video at that point to ensure I had the placement correct. Quote Link to comment Share on other sites More sharing options...
j4ustin Posted July 12, 2020 Report Share Posted July 12, 2020 Got it! That picture you posted had a busted trace as well. Must have cut that one when I was chopping off the plastic pieces that hold the pins together. Everything is working great now! Thanks for all your help @latigid on and @Hawkeye. Can't wait to box this thing up and get playing! Quote Link to comment Share on other sites More sharing options...
latigid on Posted July 12, 2020 Report Share Posted July 12, 2020 Awesome! Thanks for the positive and informative debug reports and have fun with the LoopA :-). Quote Link to comment Share on other sites More sharing options...
j4ustin Posted July 13, 2020 Report Share Posted July 13, 2020 Thanks again for the help, been learning the device today. Think it could become the heart of a live setup. Cheers guys! 1 Quote Link to comment Share on other sites More sharing options...
keelhauler Posted July 13, 2020 Report Share Posted July 13, 2020 Another Loopa appears! Wanted to drop by and thank everyone involved with this project! Was a really enjoyable build, especially thanks to Hawkeye's great video. Everything seems to be working fine and the QA team is already checking the results. 2 Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted July 13, 2020 Author Report Share Posted July 13, 2020 @j4ustin and @keelhauler - congratulations are in order, well done! Thanks for uploading pictures of your completed LoopAs! And very sweet QA! :) Working on firmware release v.207, which should be out in a week or two, if all goes according to plan - in addition to the new features from v.207pre1 (listed and linked above), it will finally support polyrhythmic sequences and about 30 more time signatures in addition to the standard 4/4 time :). Best regards and enjoy your new LoopAs! Peter Quote Link to comment Share on other sites More sharing options...
latigid on Posted July 13, 2020 Report Share Posted July 13, 2020 @keelhauler that's super cute! We do try to make designs cat-friendly :) Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted July 16, 2020 Author Report Share Posted July 16, 2020 And a very nice review of the LoopA on german amazona.de: https://www.amazona.de/test-midiphy-loopa-opensource-midi-looper/ Thanks a lot for your work on this, @momelq! Best regards, Peter Quote Link to comment Share on other sites More sharing options...
momelq Posted July 18, 2020 Report Share Posted July 18, 2020 Cosmetic issues, some small suggestions how to reduce the LED cross talk here: Use a black permanent maker to paint the transparent sides below the caps of the mute switches. Also paint the sides of the scene and live LEDs with the black pencil. This will improve the contrast significantly. However do this before you solder the parts in. Afterwards it is not possible any more and I tried to put some adhesive aluminium foil in between. This was a bit difficult. At least, when MatriX will appear, I will have paint the switches before soldering :-) The white LEDs will glare less, if you sanded the front a little bit. And finally the power LED of the MCU board will not interfere, if desolder it or put a piece of black tape on it. Quote Link to comment Share on other sites More sharing options...
latigid on Posted July 19, 2020 Report Share Posted July 19, 2020 (edited) Thanks for the feedback and ideas! We know there is a bit of LED stray light going on. Some people like it as it reminds them of their backlit mechanical keyboards. But for indicator LEDs it can be suboptimal. For the smaller 2x3x4/2x5x7 LEDs, a good technique we found was to use a piece of heatshrink tube. It's a great idea to roughen the top too if that is preferred. Sometimes you can also make the LED cloudy e.g. with acetone (nail polish remover) but needs to be tested. For blocking the light from adjacent Matias switches, we have another solution in the pipeline (more info soon) Edited July 19, 2020 by latigid on 2 Quote Link to comment Share on other sites More sharing options...
lp1977 Posted July 20, 2020 Report Share Posted July 20, 2020 On 7/19/2020 at 3:56 AM, latigid on said: For blocking the light from adjacent Matias switches, we have another solution in the pipeline (more info soon) Looks perfect. Definitely going to get these for my v4+ and LoopA when they become available. 1 Quote Link to comment Share on other sites More sharing options...
j4ustin Posted July 26, 2020 Report Share Posted July 26, 2020 Noticed some weird behavior today while sending a midi clock out via midi port 3 to a Norns device. The clock on Norns was showing a clock speed 3x the amount set by the loopa. When I turn off MCLK DIN OUT for all but one of the outputs it sets the clock correctly on the Norns. Perhaps it is sending 4x the midi clock signals. Possibly related is that the Loopa sends a midi clock out of port 3 even if that output turned off in the settings. IE: I currently have all MCLK DIN OUT set to OUT1 only, but my Norns is getting the correct clock settings even though it's attached to PORT 3. The USB clock out works OK as I am syncing Ableton via USB MIDI clock. Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted July 27, 2020 Author Report Share Posted July 27, 2020 @j4ustin thanks for the report! I'll look into it and report back to you, just working on the software anyways. Best regards! Peter Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted July 27, 2020 Author Report Share Posted July 27, 2020 @j4ustin ok, just tried to reproduce it over here and currently cannot do it. My test setup: I've used a phone charger USB power supply (no connection to a computer) and a MIDI Interface connected to the LoopA DIN outputs and measured the MIDI clock received on the MIDI interface via MIDI-OX (via MIDI Sync Transport) on a computer. Tested DIN OUT1-3 this way and can confirm that the clock is sent on every output port only once, i.e. setting to 100 BPM was shown as such in the MIDI-OX Sync Transport Screen. Then tested every port individually and finally removed MIDI clock being sent to the DIN ports, this resulted in no MIDI clock sent to OUT3, which is different than what you encountered. Therefore, more info would be required to be able to reproduce the problem: a) Which LoopA software version are you running? If you're not yet using v2.06, could you try that? b) did you connect anything to the DIN MIDI IN1/2 or the USB input of the LoopA? If something (e.g. a DAW via USB) is connected, that might either generate an own clock or echo back the original clock to the LoopA - this might then explain a multiplication of the clock. If anything is connected on any input, could you try to disconnect all inputs to the LoopA and test again and see if the clock still is multiplied? c) related: do you have any MIDI Router routes set up? Do you have any tracks with live forwarding set up? If so, can you try to disable the MIDI routes and the live forwarding to see if the problem stops? We should be able to narrow it down and find the problem, thanks a lot! Best regards, Peter Quote Link to comment Share on other sites More sharing options...
j4ustin Posted July 27, 2020 Report Share Posted July 27, 2020 Hey @Hawkeye, Figured it out thanks to your advice! I have an echo going from my Launchpad pro -> Norns. As you pointed out in (c) this is because I have a router turned on that passes Input 1 (my launchpad) out to the Norns. The clock signal being sent from the Loopa to the Launchpad is passing through and sent again to the Norns, and when the clock output for Norns is turned on I'm seeing the multiplication. Thanks for the help! 1 Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted July 28, 2020 Author Report Share Posted July 28, 2020 @j4ustin no problem - and good that you found it! Cheers! Best regards, Peter Quote Link to comment Share on other sites More sharing options...
Phatline Posted July 29, 2020 Report Share Posted July 29, 2020 it took me a long night ---but --- i finished my loopa now: some notes to the video, and build up: on the start of the video i saw on your video footage that you had stuffed PD11 --- i think on later video minutes it isnt stuffed anymore (and thats is correct, since with the jumper cable stuffed you are in bootloader mode forever) on the lcd capter - a bit confusing - it came to my mind - i saw that you solder the package together without removeable female headers... or at least it looked like it... i nearly did that... i hadnt that tiny m2 toax screwdriver at home... lukely i had fitting flat one... the fix solderd lcd i dont like (specially i got headaches when the lcd dident come up - because of bad PSU - i thought i had to de-solder the thing ) its much easy to put the white button caps into the button, when the button already sits in the pcbs! ( i scratched my finger with one of the Button-legs...) a good place for a Bootloader-switch is above the Reset Switch... the display has sharp edges that scraped my plexy window while mounting it and position it... so stick the plexi with tape on the top case bevore (i dont think the plexi part was in the video) most of the times the displays dont startup (stay black) when the loopa is connectet to my lenovo t440p --- on 2A usb wall Supplys it starts everytime... Missing parts: 8x Beilagscheiben (only 8 deliverd) - so i only stuffed them in the inside of the case (base pcb mount on metal case) 3x Nuts, where 1 was my fault (gone to floor...) so i think 2 where missing (to bad that i have thousends of m3 but not one m2 nut) its ease to destroy the winding of those m2 standoffs-outside windings... when you suddenly found a m2 nut - and its a stainles one.... i must say its not the easyest project... specialy this clever sandwitch... i had to assambly and disambly the things many times... next time it will be easyer... the video method i like, but on some points - i whish i had normal website and still pictures (aka assambly manual) --- specially when my internet connection is bad again... I like the look and feel of the device! i made a timelapse while building... so there will be a video some time... Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted July 30, 2020 Author Report Share Posted July 30, 2020 Thanks for the report, Mike! Very good yours is up and running now, cheers ! Regarding the missing parts: in theory, they should be all counted and correct, but you're absolutely right, when i filmed the video tutorial, i still had the preproduction/prototype metal case with large drill holes, thus i used M2 washers on the bottom of the case, which was unfortunately also documented like this in the video... These M2 washers at the case bottom are not really required for the final production metal case version and i've updated the video description and added a "youtube card" at the respective time to let builders know! Thanks a lot for the info! All other M2 small parts counts should be ok, i painstakingly compared the build video with the parts lists and had written down how many parts are needed for which case variants. E.g. for the M2 nuts, you should have received 9pcs in the LoopA PCB fastening hardware bundle - the parts counts are also visible here: https://www.midiphy.com/en/shop-details/0/68 Anyways: sorry for the inconvenience! Regarding the sandwich and that it's all sometimes a bit fiddly with the M2 screws: yes, you're right, but also that was intentional, we wanted to create a very small form factor triple-PCB-sandwich DIY project, that can compete with the case depth of commercial products (e.g. the LoopA is i think a bit "thinner" than a Machinedrum :)). Assembling it is also good for hand-eye coordination training :). Regarding the bootloader jumper JPA0 - it should not have mattered if you left the jumper on, this still needs resistors R101 and R102 to be operational - the idea was to solder in the jumper header in case of a bad app upload - then you could top-solder R101 and R102 (not so easy for the JPA0 headers, this would need uninstallation from the case) and stick in a jumper to be able to trigger the bootloader hold mode. We left out the resistors because they should normally not be needed, but we had the "leftover" jumper for JPA0 anyways and decided to mount it, even if it is normally not used (and needs further resistors to operate). Looking forward to your timelapse video, thanks a lot for your efforts there! Enjoy your new LoopA and best regards from hot south-of-Munich! Peter Quote Link to comment Share on other sites More sharing options...
Phatline Posted July 30, 2020 Report Share Posted July 30, 2020 (edited) what can that be?: * the loopa is totally unconnected... then plugin usb cable --- loopa and display boot up - normal * the loopa is tottaly unconnectet... then plug in midiIN1 or 2 ---then plugin in usb cable --- all ok * the loopa is totally unconnectet... then plug in MidiIN1 or 2 ---then plugin in MidiOUT1 or 2 or 3 - but without connecting a synth on the other end --- plugin in usb & loopa boots up - all ok * the loopa is totally unconnected... then plugin midi''IN1 or 2 --- then plugin in MidiOUT1 or 2 or 3 - connected to a NordRackII or Dipcore - plugin in usb & loopa dont boot up (power led blinks 7 times i think, then it stays on power) when i then disconnect the Midiout plug after a time it boots up the last case, isnt pysical stressed --- i connect on one of the midi outs with a loose cable (without a synth on the other end...) --- then it boots up normally. i tested it with a Nordrack III and DipCoreV2 (cc-looper) workaround for now is to connect the Midiouts every time new before booting up the LoopA ---- but i dont want to stress the MidiSockets for ever.... Edited July 30, 2020 by Phatline Quote Link to comment Share on other sites More sharing options...
latigid on Posted July 30, 2020 Report Share Posted July 30, 2020 Hard to say if that's a hardware issue or software. IMO best practice would be to make all connections before applying power and avoid hot-swapping... The LoopA shouldn't care what its outputs are connected to. For your case #4 above, what is connected to your MI1/2? Do you have a MIDI loop? MIDI outs have the 0V connected, so you should consider how the other parts are powered: maybe a so-called "ground loop"? 16 minutes ago, Phatline said: what can that be?: * the loopa is totally unconnected... then plugin usb cable --- loopa and display boot up - normal * the loopa is tottaly unconnectet... then plug in midiIN1 or 2 ---then plugin in usb cable --- all ok * the loopa is totally unconnectet... then plug in MidiIN1 or 2 ---then plugin in MidiOUT1 or 2 or 3 - but without connecting a synth on the other end --- loopa boots up - all ok * the loopa is totally unconnected... then plugin midi''IN1 or 2 --- then plugin in MidiOUT1 or 2 or 3 - connected to a NordRackII or Dipcore - loopa dont boot up (power led blinks 7 times i think, then it stays on power) when i then disconnect the Midiout plug after a time it boots up the last case, isnt pysical stressed --- i connect on one of the midi outs with a loose cable (without a synth on the other end...) --- then it boots up normally. i tested it with a Nordrack III and DipCoreV2 (cc-looper) workaround for now is to connect the Midiouts every time new before booting up the LoopA ---- but i dont want to stress the MidiSockets for ever.... Quote Link to comment Share on other sites More sharing options...
Phatline Posted July 30, 2020 Report Share Posted July 30, 2020 (edited) 2 minutes ago, latigid on said: Hard to say if that's a hardware issue or software. IMO best practice would be to make all connections before applying power and avoid hot-swapping.. i always connect midi first --- at last i give Power over USB.... i dont hot swap ( i do now because of workaround reasong - to get the loopa booting Quote The LoopA shouldn't care what its outputs are connected to. For your case #4 above, what is connected to your MI1/2? Do you have a MIDI loop? MIDI outs have the 0V connected, so you should consider how the other parts are powered: maybe a so-called "ground loop"? It doestn matter if a midi IN is Connected or not... so focus the Topic on this without connecting anything on MIDI IN: When there is a Midiconnection from any Loopa MidiOut (DInSocket) --- to a synthesizer --- then it dont boots up >>> no Midiloops because no Input Connected on the Loopa. Its not hardwarestress on the sockets or some Hair-Cut PCB Failure ... because - if the Midiconnection is pluged out on the Synth-side ... and the cable is still plugged into the loopa --- the loopa boots up! Ground loop: i rotated the 230V power 180° of my synth - doesnt matter I powered the loopa via a 2A USB PSU - doesnt matter I powerd the loopa via a Lenovo T440P laptop on Battery without connected a PSU (so its isolated from any loop!) - doesnt matter so no ground loop here. when connected to my laptop - and the loopa is not booting up - i dont see the loopa in mios studio (no bootloader mode or mios32 entry here) & it is not the cable itself: i have tested 3 different ones (one bought from thoman), and 2 i made myself (thick sommer cable, neutrik connectors...) & when i trickked the loopa to boot up (hot plug Midiout after booting) - it is running normal - it receives notes, and it sends notes . ( as far as i can say, since it is a new device for me) Edited July 30, 2020 by Phatline Quote Link to comment Share on other sites More sharing options...
latigid on Posted July 30, 2020 Report Share Posted July 30, 2020 Quote When there is a Midiconnection from any Loopa MidiOut (DInSocket) --- to a synthesizer --- then it dont boots up >>> now Midiloops because no Input Connected on the Loopa. Quote workaround for now is to connect the Midiouts every time new before booting up the LoopA ---- but i dont want to stress the MidiSockets for ever.... These statements contradict each other. Can you get a state where the LoopA is running and sending MIDI? Or do you mean "boot the LoopA and then afterwards connect the MIDI outs"? Curious whether you installed the scratch washer and hence grounded the case -- or not? Sometimes these sorts of peculiar things come back to grounding. We can't of course rule out hardware issues (e.g. we know of one dodgy Waveshare Core) or your build process e.g. stressed or overheated pins, shorts etc. Maybe there is flux residue on the MIDI sockets? Worth another look there. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.