Leaderboard

Hello, Glad you liked the tutorial video! Peter deserves a lot of credit for these and he does a fantastic job. One of the pin headers is a bit too long. We are looking to replace 929834 with the 929700-01-36-RK part. If you've already ordered, no problems, but you may have to trim the pins a little shorter. It might also work with a standard single-row male pin header of about 6mm in length. Apart from that, I don't think there were too many changes in the last while. Agreed about your technique; I just put a blob of solder on there and cleaned it up after! (they are capacitors) The ribbon cable, IDCs, screws, nuts, washers etc. will be done as a separate "BOM" attached somewhere else, such as the case. Work in progress! Thanks again for the feedback and good job on the PCBs so far. Best, Andy

I figured I'd post this somewhere just in case it helps someone troubleshoot in the future. I built my SEQ V4 years ago. It always had an ongoing very minor issue with its rotary encoders - for example, if I turned them in an incrementing direction, maybe once every 10 ticks or so, the encoder would jump back a few increments... Like, if I was increasing velocity it would go 100-101-102-103-104-102-103-104-105-106-... A really minor issue - not a big interference with usability - but annoying. Over the years I tried to fix it and could never figure it out - I assumed it was an issue with the encoder types that were supported by MIOS - I played with the various DETENTED2, DETENTED3, etc. encoder type settings in my MBSEQ_HW.V4 file, but couldn't get the glitch to go away completely. Eventually I just gave up and figured that if this is the only real minor annoyance that I had to deal with, that's pretty great for a free and open source device. But I should have known that much like everything else MIDIbox, TK is a goddam genius and doesn't really screw much up, so there's probably a solution to any problem you might have, even if it's very hard or impossible to find in the documentation. I recently added CV/Gates to my SEQ with AOUT_NG/DOUT modules. While working on that, I noticed a reference in the docs for those modules that there is a limit to the length of certain cables joining the various modules to the Core - the docs said that if you use cables longer than 20cm to join the AOUT_NG/DOUT modules to your Core, you may have issues with the CV/Gate functions, and it might also result in glitchy readings on digital module components elsewhere in your SEQ (this is why the LINE DRIVER module exists). Shortening my AOUT/DOUT CV cables to under 20cm fixed an issue I was having while setting up the CV/Gates. Then it occurred to me that maybe my encoder problem might be due to slightly long cables as well. Mine weren't ridiculously long, but some were probably about 30cm. But I figured it was worth a shot, and I remade all of my cables. I made them as short as they could be while still reaching the Core jumpers. This fixed my encoder problem completely. Anyway, maybe this will help someone else in the future who's searching the forums for solutions to glitchy encoders - I didn't see any mention of cable length when I was trying to troubleshoot this myself until I noticed mention of length limits in the CV docs.