• Content count

  • Joined

  • Last visited

Everything posted by borfo

  1. This is the discussion thread for the MIDIdocs article "Novation Launchpad BLM" in the Wiki.   Feel free to ask questions or make comments or corrections on the article in this thread.
  2. Cool - have fun!   Out of curiosity, did you try installing pyBLM on windows as well?  I'm assuming you didn't, but if you did, how did it go? 
  3. Hi - I think I've tested it on a raspberry pi...  It should work anyway.   ...Are you sure you're installing Mido into Python3, not just into Python 2?  Try "pip3 install mido" and rt-midi...  If that doesn't work you You might also try installing as your user rather than sudoing it.  You could also try installing python3-mido and rt-midi from your package installer (if they're there) instead of through pip.  
  4. You could try the python BLM implementation - if you do, let me know if it works for you:  edit:  Oops - didn't notice that you were already aware of the python BLM thing.  because the virtual BLM and pyBLM use totally different codebases, I thought the issue you're having under the virtual BLM software with conflicting device names might not occur with pyBLM.  Might be worth giving pyBLM a shot now rather than trying to work out the issue in virtual BLM if you're planning on using pyBLM anyway.    ...pyBLM should work in windows too, I think, provided the dependencies will install.
  5. I think I fried mine...  Does anyone have an extra set?  Or some extra PICs that you could program for me?
  6. Thanks everyone - I'm not sure they're fried, but they're certainly corrupted, and the bootloaders on all of them are no good.  I think I overvolted the board while I was impatiently trying out some ill-considered power supply ideas after my commodore 64 psu arrived DOA.  I tried flashing one with an arduino PIC programmer circuit I found on the internet, and the burn failed.   I've found someone local to borrow a Pickit 2 from and I'll try reflashing my existing PICs...  If that doesn't work I just bought four compatible PICs for cheap on eBay, so I should finally be able to get this thing working one way or another.
  7. I just found 4 cheap PICs on ebay actually...  I'm in Toronto, Canada - probably easier to figure out something local rather than sending PICs back and forth to Scotland.  Thanks a lot for the offer though.
  8. midibox stuff pic programmer, core, lpc board LCD

    [Deleted message asking about PICs to replace the corrupted ones in my MB SID] Edit:  Nevermind - I just found a cheap set of PICs on ebay.
  9. Older pics programmer and book on programming

    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?
  10. (WTB) Seq V4 parts ( 2 raystar oleds for trade )

    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.
  11. (WTB) Seq V4 parts ( 2 raystar oleds for trade )

    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.
  12. 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...
  13. 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.
  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. kicad schematic files for MB modules?

    I've built modules in Kicad from the schematics on 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:   
  16. R3 DIN Printed Circuit Board or Kit

    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.  
  17. Drumpads

    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: Definitely looks to be worth experimenting with.
  18. 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.    
  19. Drumpads

    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.
  20. ...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.
  21. 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?
  22. 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?
  23. 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...
  24. pyBLM allows you to use up to four novation launchpads as a BLM for the MIDIbox Seq V4.  In this respect, pyBLM basically does exactly what the Juce Scalar Emulation app do, but it leaves out all the extra features and GUI elements.  It currently works well with 4 launchpads (16x16 BLM).  It should more or less work with 2 (8x16 BLM), although I get an error on a callback that I haven't figured out yet. It doesn't seem to work with one launchpad yet - does the SEQ support a one launchpad 8x8 BLM?  If so, I may fix pyBLM to support that sometime, or if you want to do it, feel free. It will never work with 3 launchpads. NEW FEATURES (not in the Juce version): Autodetects launchpads: when the script starts, you'll see a green line displayed on each of the launchpads detected by pyBLM.  The line will have a length (measured in LP buttons) equal to the number of launchpads detected by pyBLM. Autoconfigures launchpad layout and rotation based on button presses: when you see the green line, press one of the square buttons on each of your launchpads to tell pyBLM which of the detected launchpads you want to use, and how they are laid out.  Start with the launchpad in the upper left corner of your layout, and move clockwise.  Each pad should show a scrolling number between 1 and 4, indicating the order in which you selected the launchpads.  Top left corner should be "1", top right should be "2".  If you have 4 LPs, bottom right will be "3" and bottom left will be "4".  The script automatically configures the launchpad rotation, a feature that I will particularly appreciate when trying to use the SEQ while drunk. Autodetects the SEQ device ID and port (or you can set the port manually):  After the scrolling number appears in the step above, the configured LPs will light some of their round side buttons.  Press button 1 to 4 to select the SEQ USB port.  Or press the green buttons (button 7 or 8) to cause pyBLM to automatically determine the SEQ BLM USB port and connect to your SEQ.  Pressing a round button stops the layout configuration step above - you can choose not to use all of the detected launchpads if you wanted to for some reason. eg: if you have four LPs, you could press a round button after configuring only two of them and pyBLM would set up an 8x16 BLM. Once you press a round button, a scrolling number will indicate the detected SEQ BLM USB port.  After that, the BLM is set up and should work exactly as it does when connected via the Juce app.   Dependencies:  Python3, Mido (, python-rtmidi   pip install mido pip install python-rtmidi mark the script executable, and run.   Tested only on Linux so far, although it should also work on inferior operating systems.  Let me know if you find bugs.   ________________________________________________ License:  I'm giving this code to TK, it's his to distribute and license as he chooses.  Unless and until you hear something different from TK, assume personal, noncommercial use only. ________________________________________________ Code:
  25. 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?