Jump to content

borfo

Programmer
  • Posts

    299
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by borfo

  1. Hi - I have to get a pic programmer anyway to fix my MB SID... What would shipping to M6H1N2 in Toronto Canada cost? Are there any PIC18F4685's in there?
  2. Hm. If I don't get rid of the frontpanel PCB I shouldn't get rid of the parts either... I could still do the LPC17 core if you like though.
  3. I have a PCB for Wilba's Seq v4 frontpanel, new, nothing soldered to it yet. I have other parts as well that I could probably part with... I have a set of the rotary encoders and a set of the bicolor LEDs... A datawheel knob... I have an assembled LPC17 core that I could get rid of as well - it's a totally functional core for the time being, although as the SEQ forks off into the V4+ you'll miss out on some functionality down the road. You can always upgrade the core though. I could put together a set of knobs that would fit the encoders, but they're potentiometer knobs, so they've got that position indicator stripe on them, and I might have to mix up colors a bit, not sure if I have 16 of any one color... Anyway, not the prettiest knobs on the block, but they would work. I have an assembled STM32F4 core as well that isn't being used right now, but I think I want to keep it. What color are the OLEDs? Where are you located? Anyway, let me know if you're interested in any of that.
  4. Since the MBSEQV4+ is imminent, it would be great if all of the standard button functions on the SEQ and whatever new functions will be on the new V4+ were made accessible via MIDI, with LED feedback signals to allow fully functional MIDI interfaces to be built. Right now, a lot of SEQ functionality is accessible via CC, SYSEX, and NRPN, which is great - don't get rid of that stuff. But there is no LED feedback signalling which would allow illuminating buttons on MIDI devices just like the buttons on the standard SEQ. (Like the GP buttons, for example - on the SEQ, they light up in color - unless I'm mistaken, there's currently no way for a MIDI controller script to receive lighting signals for any of the buttons. Take a look at the picture attached to this post - two Novation Launchpad Minis line up perfectly with the 16 GP buttons and knobs on the current SEQ - the launchpad works as a BLM already - if there was midi access to the button functions and lighting, we could build SEQ V4+'s with just the 40x2 LCDs and one row of encoders - all the rest of the button functionality could be offloaded onto the Launchpads. (or onto any other midi controller, for that matter), and if LED feedback worked as well, MIDI devices would work just as well as DIY hardware SEQ interfaces... For those of us with midi controllers sitting around, this would allow some pretty neat designs at very low cost. It would be great if you could configure MIDI connectivity in the MBSEQ_HW.V4 file - so that all of the hardware buttons you can configure for DIY hardware could alternatively be mapped to MIDI right in the hardware config file (or maybe in a MBSEQ_MIDI.V4 file or something. Anyway, given the extra capacity on the V4+ core, I thought there might be room for this sort of functionality...
  5. I've printed a first batch of these boards, and have assembled a couple. Haven't had time to test them thoroughly, but I figure I may as well post the Gerbers anyway in case anyone wants to print some. Let me know if they work for you, or if you find any issues. mbhp_DINDOUT.zip
  6. I've built modules in Kicad from the schematics on Ucapps.de from scratch - just copying the schematics into Kicad. They're pretty straightforward, and the copying exercise has been a great way to learn Kicad. If you're interested in DIN or DOUT modules, I could send you my kicad files for this board if you want:
  7. I've got a bunch of prototypes of this combined DIN/DOUT module board that I made... Haven't tested it thoroughly yet, but it should work fine. If you want to try one of these boards I could mail you one. $5 +postage? Alternately, ucapps has board files and schematics.
  8. Wow - just found a pretty cool looking DIY pressure/velocity/position sensor design that looks like it could really work well for drums. Pretty inexpensive to build as well, by the looks of it. Check this thing out: http://madronalabs.com/DIY Definitely looks to be worth experimenting with.
  9. OK - I rerouted the board, it's laid out better now. All components are on top, traces are a bit less of a mess, I added a few 5v/ground headers on each board, and I connected S1/S0 properly so the boards will (or should at least) work in a single chain. Can someone please confirm it is ok for me to bridge (1) pin 7 to pin 8; and (2) pin 9 to pin 10 (the serial and latch clocks) on the J1/J2 headers? Looking at the MBHP_DIO_Matrix schematic, it looks like this should be ok.
  10. I'm developing a finger drum controller, like Future Man's kit (dude who plays drums for Bela Fleck), or like a Zendrum... I've been experimenting with piezo pickups in different casings, connected to a teensy 3.6, and those seem to be working pretty well in terms of registering the relative strength/velocity of different hits. My take was that MIOS wasn't really equipped to handle reading piezos right now, and that some amount of work would be required to add that capability, but also that designing a Teensy-based drum sensor wouldn't be too much work... And that my design was essentially for a standalone drum controller anyhow, which could be connected to a Midibox via MIDI anyhow, so figured I'd just do it standalone. Would be cool if MIOS got the ability to read piezos, but from my experiments the reading algorythms are pretty dependent on the physical configuration of the sensors (like, when you put the piezos in different casings, they read differently, and the algorythm has to compensate to avoid triggering from vibrations when you hit neighbouring sensors - would be possible to make a one-size fits all solution, but there would have to be some built-in calibration functionality). I might be into helping with an effort to incorporate piezo sensing into MIOS if that was a project that would be of interest to people though - would open up a bunch of neat options for MIOS based projects... But it may be too much purpose-specific code to throw into a codebase where most people wouldn't be using piezos... And a standalone Teensy based system makes some other neat options possible, like using capacitive touch to sense drumskin damping, motion sensor effects modifying drum sounds, etc. For casings, I've been experimenting with little foam-packed plastic and metal containers, with piezos mounted on the lids, and also with sandwiching piezos between hard rubber adhesive pads (sandwiches made of 3M adhesive hard rubber feet a few mm thick, clear rounded epoxy plastic stickers, and some various other materials). Both work well. Also playing with ways to mount lots of sensors on one instrument without having hits on one sensor affect others - vibration isolation by mounting all the sensors on rubber/foam pads, etc. Anyway, from what I've found so far, because of the nature of drum sensors and all the associated acoustics/vibrations, there are a lot of implementation-specific things that a one-size-fits-all algorythm would have to take into account - considerations that don't exist when you're reading tact switches, encoders and pots... A MIOS implementation would have to be pretty flexible in order to be useful. I've got a launchpad pro, which is velocity sensitive (force sensing resistors, I think), and I find it doesn't really give as good a "feel" for finger drumming as the piezo sensors do... That might be a calibration issue, I guess, but I think the piezos give a more accurate read of hits.
  11. ...So all I'd have to do to make this board work in one physical chain is connect the S1/S0 connections from J1 to J2 on each module? I wouldn't have to split the RC connections? (ie: it's ok to leave them bridged? How about the SC connections? Are they ok bridged as well? (looks like they're bridged at the CORE, so I imagine they're ok bridged in the chain as well...)) I'd like to be able to have the option of using the boards in one single chain (also would like to make it possible for the two modules on the PCB work in series) - the user could also choose to connect them in a Y if they wanted to. Thanks for the help. _________________________________ Just noticed your first comment - thanks, those points are totally useful, particularly the H traces on one side and V traces on the other thing... I guess 90 degree traces are bad because they're more likely to be screwed up in the board manufacturing process? I didn't use R networks because regular resistors are cheap and I always have lots around, whereas I generally wind up having to order R networks. I figure all of the parts on these boards are common enough that people often would have them at home already rather than always having to make a special order to make these boards.
  12. Thanks for the reply - could you explain a little more though? Do the SmashTV boards work in a chain with both DIN and DOUT modules connected in series? Looks to me as if they must not, since the S0/S1 connections would break (and the RC connections would get mixed up since they seem to be bridged on SmashTV's boards). By "force Y chaining", do you mean the SmashTV boards force users to split their chain into one physical DOUT chain and one DIN chain? I'm thinking that for my boards I'll split the RC signals from CORE J8/J9 and connect them through between J1 and J2, and complete the S0/S1 connections so that users could chain their DIN and DOUT boards in series in one single line rather than a Y... Would there be a problem with that?
  13. Hrm... I think I may have spotted an issue actually. I worked from the smashtv R5 MBHP_DOUT and MBHP_DIN module schematics. Those schematics show the S0 pin on the DIN module's J1 and J2 to be unconnected, and the S1 pin on the DOUT module's J1 and J2 to be unconnected... This must be wrong, otherwise the DIN/DOUT chain wouldn't work... I connected those pins on my board and schematic, but haven't bothered to re-upload the images, etc. in the post above. Are there any other errors in the SmashTV R5 schematics?
  14. I designed a PCB that combines a DIN x4 and a DOUT x4 on one small PCB. The modules are connected by traces, so they'll work together in series using the PCB connection, or the board can be split in half so the modules can be used separately. The board is less than 10x10cm, so it can be printed extremely cheaply at places like DirtyPCBs (~$16 for 10 boards) (I think SEED is offering even cheaper 10 packs of 10x10 boards as well now, but I haven't tried them yet.) Resistors are mounted on the back of the board. Ground planes on the front and back of the board, back of the board has a VCC plane zone as well. Mounting holes match, so modules can be mounted on top of each other if desired. Anyway, I haven't done much PCB designing, so if anyone happens to notice any errors in this thing before I get them printed, your comments or suggestions would be appreciated. Once I've done a print run and have tested them, I'll publish the gerbers/brd files, etc. for anyone to use. MBHP_DIN-DOUTx4-brd.svg MBHP_DIN-DOUTx4-schematic.pdf
  15. Yeah, I think many things are remote-controllable, but as far as I remember, the multifunction GP buttons aren't, and there's no easy LED feedback - you could script something, but it would be complex and would need a lot of sysex traffic. It would be ideal to just add a new mode to the core BLM implementation that would cause the top couple of rows of the BLM to behave like the standard control surface, with LED feedback - this would require no modifications on the BLM client side...
  16. How long are your cables between the control surface and the mainboard?
  17. Thanks - that's helpful. The cable length thing does have weird effects though - I initially had 20cm cables, and shortening to 10cm fixed a bunch of misbehaving switches and glitchy LEDs. The few that are still not cooperating are probably bad parts, or as you say, maybe not properly soldered. I'll start working them over on the weekend. Normally, I don't mind this kind of troubleshooting stuff with a new synth build, but I'm pretty impatient to get this one fully working so I can make crazy noises with it... Even in the "almost-fully-working" state it's in now it's pretty amazing.
  18. I'm troubleshooting a few misbehaving switches and LEDs on my recent MB_6582 build - there are still a few switches and LEDs that aren't working. Could just be bad switches/burnt out LEDs, but before I start desoldering and replacing stuff, I thought I'd ask about maximum cable length between the control surface and the mainboard. My cables are about 10cm long at this point - is that within acceptable range, or could that cable length be causing issues? The build guide says something around 4.5cm is "ideal", but is 10cm too long?
  19. Dude, I'm literally just saying (to nobody in particular) "These keyboard switches are neat. Hey, look at this site with a variety of open-licensed keyboard designs with gerber files." Nobody is criticizing you or asking you to change anything. Obviously, this thread isn't the place to post anything not directly related to your PCBs though, so my apologies for the intrusion.
  20. I can imagine lots of uses for button layouts that aren't identical to the SEQ's 16 columns - for NG controllers in particular. But I'm not at all suggesting that those boards are a replacement for anything anyone's doing here, just thought I'd share a link to a site with a lot of open-licensed keyboard designs with gerber files. In particular, I thought that the work he's done on making the key spacing as small as possible might be interesting to people here. Re: addressable LEDs - some of his designs have per-key addressable leds. Others have a few addressable LEDs somewhere on the keyboard, but not on each key, or backlighting LEDs on each key that can be addressed as a group, but not individually.
  21. I've been looking at these mechanical keyboard switches - there really are a lot of options with these things, and a lot of keyboard nerds working on various projects. And knockoff keys and caps can be had pretty cheap for those of use who like to cheap out on components a bit where possible. You may want tio take a look at some of the matrix keyboard (straight grid-style layout) designs out there. There are some PCBs available - often pinned to just add an Arduino pro micro as a controller - this guy has released schematics and gerbers for many of his designs. http://www.40percent.club/2017/03/ordering-pcb.html His designs may be of particular interest to us, since he uses cut down keycaps and makes extremely compact keyboards. The "Gherkin" http://www.40percent.club/2016/11/gherkin.html is a backlit 3x10 key matrix with 16mm key spacing - measuring about 5cm x 16cm. PCBs can be had very cheap - he says an order of 5 sets of the 3 PCBs that make up this keyboard cost about $55 including shipping. This "Gnap" keyboard is larger and has a more standard staggered keyboard layout, but it has individual LED control, and the gerbers are on github. It's 12x4. It's pinned out for two arduino Pro Micros, but the schematic looks like we might just be able to wire these pcbs directly up to DIN/DOUT modules. http://www.40percent.club/2016/10/gnap-20-plateless.html - https://github.com/di0ib/tmk_keyboard/tree/master/keyboard/gnap/pcb Here are 6x5 gamepad PCBs from another supplier for $8 - not sure how they're wired though, and I don't think they have LEDs. http://www.switchtop.com/product/gamepad-macropad-pcbs
  22. Take the Wilba MIDIbox SEQ CS for example. Would it be possible to use the same control surface and LCDs for two STM32f4 cores, one running MB SEQ and the other MB NG, with a hardware data switch in the middle? A switch like this: https://www.alibaba.com/product-detail/DB25-2Port-Data-Switch-6039-_344461771.html Is it possible to disconnect and reconnect (a) LCDs; (b) DINs/buttons/encoders; and (c) DOUTS/LEDs while MIOS is running without causing problems?
  23. Note for anyone it might help in the future: I had some control surface LED and button issues - glitchy buttons not activating what they are supposed to activate, LEDs not lighting, etc. Turned out to be the length of the cables between the control surface and the base PCB (was about 20cm). I made shorter cables, about 10cm, and the LED/button issues disappeared.
  24. "Hey you idiot, you forgot to flash the goddam firmware." Duh. Solved. I had assumed it was preflashed by smashtv, but I guess the PICs just had MIOS, not the SID app. Seems to be working now!
  25. After leaving the boards sitting unfinished for a couple of years, I've finally finished my MB_6582 build, with a classy case made of popsicle sticks and a Cohiba cigar box. Pairs of 6581 SIDs are installed in 1 and 3. Things seem to be relatively ok, but I'm at the "power on" stage, and all I'm getting on the LCD is the bootup sequence, showing the MIOS version installed, and then just "READY." The control surface LEDs flash briefly when power is turned on, then nothing, and turning the encoders/pressing buttons doesn't do anything. Now, a careful builder at this stage would go through the build instructions carefully and see if they've missed anything, but I am lazy, and would rather have someone else tell me "Hey, you idiot, you forgot the jumper at Jwhatever" or something. (I'm actually going through the instructions now, but figured I'd also post here and see if someone points out some obvious thing I missed.) Is there a limit to the length of the cables joining the base to the CS pcb? I'm temporarily using some breadboard cables I had lying around - once I get this debugged, I'll make custom cables, but thought I'd use these for now. They're about 20cm. Photos attached.
×
×
  • Create New...