Jump to content

borfo

Programmer
  • Posts

    299
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by borfo

  1. You are not blind. Instead, I am an idiot and linked the wrong page as someone already pointed out. But now that I see the pictures of your box it looks like everything is as it should be - if the numbering seems weird to you now it probably won't take long to get used to it. Or if you wanted to, you could swap the two I/O boards, but then the back panel labelling would be wrong and you say you don't want to open the box... Fancy work on the build too.
  2. If you look at the jumper description for J11e on the MIDI IO page (http://www.ucapps.de/index.html?page=mbhp_iic_midi.html), you'll see that the midi inputs are directly pinned out from the core board. So, most likely your cable (or whatever you have running off of J11e to connect your IOs) probably has a few mixed up pins. You should be able to just rearrange the pins and fix your problem.
  3. Have you been following that "Let's invent a new frontpanel thread? I'm liking the fact that the rows will all have 16 buttons - makes a lot more sense... And given how well the launchpad minis line up with the LCD columns, I'm tempted to make a tiny SEQ frontpanel that only has the encoder row, the datawheel, and maybe a handful of other convenience buttons. If you could put MIDI assignments in the SEQHW_V4 file, instead of just shift register numbers, or if every parameter that could be controlled by a frontpanel button or encoder was coded to a MIDI CC/SYSEX/NRPN/etc. address (OSC would work too...) then the launchpads could be both the BLM and 16 rows of 16 SEQ buttons. The launchpad buttons and LEDs are way nicer than tact switches, too. It would be easy to tie all the parameters to MIDI, but if I'm remembering right, the reason they're not is because of low memory on the LPC17 Cores. Once he makes the move to the STM32 V4+, this should be easy to do. Even if they're not all accessible by midi yet, there are quite a few MIDI controls. Certainly enough to make SOME fun new BLM modes anyway, even if all the frontpanel functionality can't be duplicated yet.
  4. I'm in the process of designing myself my perfect self-contained MIDI jam case, and I've been planning to make a new SEQ anyway. I've already got a bunch of these panel switches and they seem pretty ok... I think I may as well try a panel mount job with a few customizations. (I had actually also settled on using rows of 8 instead of the Wilba design.) Great timing that this new design is finalized though - wouldn't want to build a new seq only to find that everyone's using something totally different now. Anyway, great work on the design. Looks great, and the modular design will be totally useful. Same with the consistend 8 button grids. Everything's 8 in Midi, and in a lot of music. Having that consistency in the button rows will naturally lead the interface to become more useful and intuitive, I think.
  5. You're probably right re: just using DIO and DIN's... I figure with the panel mount switches, I'll just buy a bunch of extras and it'll be pretty easy to replace them if they fail. And I figured I'd use LEDs in addition to the buttons instead of bicolor leds. But $1 per switch on your design is a good price. I was expecting a price along the lines of those marquardt switches that people were using for a while. I've had good luck with the cheap chinese stuff, but at $1/switch, I may just build your board - at least for the button part. I didn't realize you were at the board-ordering stage already - I haven't been here for a while, still catching up on new developments. When do you expect to have boards to sell?
  6. Oops... They make both momentary and latching versions. I bought momentaries - I just wasn't paying attention when I searched for that link.
  7. Or, alternately I guess, it would be pretty easy to make a second variety of frontpanel PCB that just does the same multiplexing, but pins out all the frontpanel LEDs, buttons and encoders instead of providing pads for PCB mount controls... That would make these PCBs very small and affordable. ...that's kind of what a DIO module is, I suppose. But a pinned out PCB that was multiplexed, marked and designed to be used with the same MBSEQ_HW.V4 file as the commonly used frontpanel PCB would be handy. Edit: I just found this great pinning diagram of wilba's panel that maps it to a DIO Matrix and a DINx4 (http://www.ucapps.de/midibox_seq/mbseq_v4_dio_wilba_layout.pdf), which goes a long way towards what I'm suggesting here... A little PCB that piggybacks on the headers on the DIO_MATRIX, holds the diodes, and pins out and labels the button and led matrix coordinates would be really handy though. Maybe I'll design one... Hm.
  8. A suggestion for these new panels: Could you add holes for 2.54mm headers to the encoder, button and led pads so that builders could choose to pin out to panel-mounted controls and indicators instead of using the recommended buttons? This would give builders a lot of options, but would still be way less hassle and way easier to troubleshoot/assemble/etc. than wiring up a frontpanel straight to DIO/DIN/DOUT modules. I've recently found these super cheap 16mm illuminated panel mount buttons on aliexpress - https://www.aliexpress.com/item/ON-OFF-illuminated-round-Latching-Push-Switch-4pin-1A-250V-3A-125VAC-Green-50PCS/514238730.html (Oops - linked to latching buttons - they also make momentaries in the same style.) They're $0.60USD each. Pretty affordable. I ordered some, and they're pretty nice actually, and come in quite a few colors. I was considering building a new SEQ with these buttons panel mounted and wired to DIO modules, but thinking about the rats nest of wires that would be required is a bit scary. If this new PCB allowed pinning out the controls to headers, that would make a project like the one I'm thinking of very doable.
  9. The answer to this doesn't seem to be obvious in the docs, but given how flexible MIOS is, I figured I'd ask. I'd like to have a few buttons with LED indicators (maybe 8?), as well as an encoder or two attached to my sequencer frontpanel that always serve as a typical midi controller - like, the buttons and encoder would send CCs to another device via midi, and the buttons would have LEDs that could be lit by the connected device as indicators. I could build an arduino thing for this, or an NG. But since my needs here are pretty modest, and my SEQ is right there and already connected to everything I'd ever need to control, I'm wondering if the SEQ could support having a few extra buttons/leds/encoders attached that would function as a dedicated midi controller... Not really a mixer map type thing, sort of a minimal NG, but I wouldn't need any banking or anything - these buttons could always send/respond to the same CC, out the same port, no matter what the SEQ was doing. Would this be possible? How?
  10. I realize that it's not a particularly detailed license - I'm actually an intellectual property lawyer. But TK's general awesomeness more than makes up for any failings he may have in the intellectual property license drafting department. Haha. "Personal noncommercial" is a license though, it's just a bit vague. Seriously though, I love TK's attitude to IP in the work he's done, think he's built an amazing system here, and think he should own all the midibox related code so that if he ever decides to move to a different licensing scheme, he won't have ownership issues. So this code is his to do with as he likes. Do you want to do anything with this code that "personal, noncommercial" wouldn't work for? I probably wouldn't have issues with that, but I already assigned copyright to TK, so he's the one who'd have to grant any licenses. Maybe he'd grant you a Death and Repudiation License if you asked nicely... Haha.
  11. Some things I learned while writing my pyBLM script: SEQ won't respond to layout or ping sysex messages unless the device_id being sent by the client script matches the device_id of the SEQ The BLM client (ie: the pyBLM script) is just a dumb translator. All of the real functionality is handled on the SEQ. The only thing the BLM client has to do is send layout information to the SEQ, translate MIDI messages in BLM protocol format coming from the SEQ into messages the button/LED matrix you're using will understand to light up indicator LEDs, and translate BLM button presses into the SEQ's BLM Protocol format. It's actually pretty trivial to write a BLM client once you understand what's happening. It appears that the SEQ only uses the column transfer format from the BLM Midi Protocol docs to send data to the BLM, and single-access and row transfer formats are never used. TK, can you confirm this? There is some info missing from the BLM SCALAR MIDI Protocol documentation (http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm_scalar%2FREADME.txt) Specifically, how to address the second extra column used by the novation launchpad scalar setup. This should be added to the docs: Sent button events: +---------------------------------------+-----------------------------------+ | BLM16x16 Buttons | 9<row> <column> <button-state> | | Extra column buttons | 9<row> <40+column> <button-state> | | SECOND Extra column buttons | 9<row> <50+column> <button-state> | | Extra row buttons | 90 <60+column> <button-state> | | Additional extra buttons (e.g. Shift) | 9F <60+function> <button-state> | +---------------------------------------+-----------------------------------+ ... SECOND Extra Column optimized LED pattern transfer (prefered usage): NOTE: in distance to single LED access, we always sent over the same channel! +--------------------------------------------+-----------------+ | row LEDs 0..6, green colour, 8th LED off | B0 50 <pattern> | | row LEDs 0..6, green colour, 8th LED on | B0 51 <pattern> | | row LEDs 8..14, green colour, 16th LED off | B0 52 <pattern> | | row LEDs 8..14, green colour, 16th LED on | B0 53 <pattern> | +--------------------------------------------+-----------------+ | row LEDs 0..6, red colour, 8th LED off | B0 58 <pattern> | | row LEDs 0..6, red colour, 8th LED on | B0 59 <pattern> | | row LEDs 8..14, red colour, 16th LED off | B0 5A <pattern> | | row LEDs 8..14, red colour, 16th LED on | B0 5B <pattern> | +--------------------------------------------+-----------------+
  12. Not sure. I have 4 launchpad minis - they show on my computer with the USB device name - eg "Launchpad Mini 2:Launchpad Mini 2 MIDI 1 32:0". Right now, pyBLM autodetects any attached USB device with the word "launchpad" in its device name. I am not sure what the device names for launchpad models other than the Mini would be. If they don't have launchpad in their name the script would have to be adapted slightly. Other than USB name issues, the script may not work on first generation launchpads - not sure. I don't have one to test with. Should work with the "s" versions as well as the more recent ones. Hopefully users will let me know what launchpads work. If only the Mini works right now, it should be trivial to fix the script so that at least non-1st-gen Lpads work. Launchpad Pros **could** work, but I think it would require some tweaking to my script, or an altered firmware for the pro that would put it into the same "XY Mode" that I'm using for the launchpads in my script I have a pro, but I have better uses for it, so don't plan on doing much extra work to support it in this script. Someone else is welcome to do this if it's a desired feature. That's what I was planning to do in my setup. I haven't tested on a pi yet, but the script should work on any properly configured Pi model. FYI - I've compiled the Juce BLM scalar implementation for a first model Pi in the past - the compiled version binary, and instructions on compiling your own for Pi are posted in this forum somewhere. A search for "raspberry pi" should find it. I would start it headless (ie: don't start X), and autorun this script on boot. Python3 would have to be installed - I think it is by default these days - as would Mido (pip install mido) and python-rtmidi (pip install python-rtmidi).
  13. I was planning on setting up something like this - what you describe would be pretty easy to implement. The client side of the BLM (eg: this app or the Juce app) is really just a dumb translator at heart - it just translates midi messages incoming from the SEQ into LP led-illumination messages, and MIDI-encodes button presses on the LPs in a way that the SEQ can understand. All of the important processing is happening in the SEQ. The BLM does make provision for up to 6 "extra buttons", but I'm not sure how these work. It would be easier and probably better to just configure the extra row on the client-side to send arbitrary MIDI messages on the Ext. Ctrl channel, and not try to use the BLM protocol for these messages. You could do this yourself pretty easily if you know any python. Look at the callback for the Pad object, and the Pad[#].buttonmap object. ...I had also thought that I might want to use the extra row of buttons to add some "smart" functionality to the currently "dumb translator" BLM client - add extra modes that I personally would like to have but that TK may not find useful enough to add to the main SEQ program on the server side, or functionality that would be too cumbersome for the Midibox Core. It would also be very easy to add support for other midi devices to pyBLM - eg: maybe you have a korg NanoKontrol or two that you would like to use to control your SEQ in some way - a user with some knowledge of python could add support for one or more other devices that they own by adding a translator class and callback to the script separate from the BLM protocol stuff. I have a couple of controllers I may add to my own setup... I have some midi implementation questions for TK before I start with that though. In theory, it would be pretty easy to write a python script that communicates with a bare stm32f4 or lpc17 core to allow full external MIDI controller operation of a SEQ V4 with a minimal frontpanel, or even without building a frontpanel at all. But I don't think all the required parameters are available via midi right now.
  14. 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 (http://mido.readthedocs.io/en/latest/installing.html), 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: https://github.com/borfo/pyBLM
  15. 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.
  16. I got a little further in my script, and now that I'm seeing the live incoming data from the BLM, I've got a few more questions: Looks like pretty much everything I'm getting from my SEQ relating to the main 16x16 grid is this type of message - updating each column one at a time: BLM16x16 optimized LED pattern transfer with 90° rotated view (rows and columns swapped, LSB starts at top left edge!) +--------------------------------------------+------------------------+ | row LEDs 0..6, green colour, 8th LED off | B<column> 18 <pattern> | | row LEDs 0..6, green colour, 8th LED on | B<column> 19 <pattern> | | row LEDs 8..14, green colour, 16th LED off | B<column> 1A <pattern> | | row LEDs 8..14, green colour, 16th LED on | B<column> 1B <pattern> | +--------------------------------------------+------------------------+ | row LEDs 0..6, red colour, 9th LED off | B<column> 28 <pattern> | | row LEDs 0..6, red colour, 9th LED on | B<column> 29 <pattern> | | row LEDs 8..14, red colour, 16th LED off | B<column> 2A <pattern> | | row LEDs 8..14, red colour, 16th LED on | B<column> 2B <pattern> | +--------------------------------------------+------------------------+ I haven;t seen any of the row-type pattern transfer messages, or the single-access messages. Does the SEQ use any of the other transfer approaches for the main 16x16 area? Or does it always use the column transfer messages? _____________________________ For the "extra column buttons" - the 2x1 and 2x2 launchpad BLMs have two extra columns - looking at the single access transfer: Extra column buttons | 9<row> <40+column> <button-state> Would I be right to assume that if note = 0x40, that means the first extra column, and 0x41 would mean the second extra column? I also noticed some MIDI messages from the BLM that follow the extra column transfer format, but which are not documented in the BLM protocol document. But where the first extra column messages came in as: 0xB0 0x40 <pattern> - 0xB0 0x42 <pattern> - 0xB0 0x48 <pattern> - 0xB0 0x4A <pattern> These undocumented messages came in as: 0xB0 0x50 <pattern> - 0xB0 0x52 <pattern> - 0xB0 0x58 <pattern> - 0xB0 0x5A <pattern> Am I right to assume that these "5" based messages are an optimized transfer protocol for the second extra column? Are more than two extra columns possible with the BLM? Are there transfer options for more than one extra row? _____________________________
  17. Your timing is perfect... I've finally ordered the rest of the parts to finish my SID boards that have been sitting half finished for a year or two... I have 5 6581s, but I may as well fill the thing up while there are known good SIDs available. Put me down for four, I guess. Any chance you feel like giving a bit of a break on the price for 4 of them? Either way, let me know the total with shipping to Toronto, Canada, plz. Thanks!
  18. Hi all - and particularly TK since you know this stuff better than anyone: I'm writing a headless BLM scalar implementation in Python (using Mido - http://mido.readthedocs.io/en/latest/index.html) for 1-4 Novation Launchpads. I wanted to write something that doesn't require the user to run a windowing system like the Juce app does - something that would be easy to run on a headless Raspberry PI. I'm pretty much finished with it - I'll post it in here when I'm done. I have a few questions though - things that weren't totally clear to me from the BLM protocol docs, etc. Can I expect the device_id of all MB Seq's to be 0? If not, can I send a message to the seq to request its device_id? How? (my sc ript currently sends a series of pings where the device ID ranges from 0 to 127 out all 4 discovered MB SEQ ports - when it receives a ping response, the script automatically learns the port number and device ID. Is there an easier way to get the ID?? (NOTE to future BLM developers: the Seq will not respond if you send it the wrong device ID) ) Other than the BLM Protocol document and the CC and Remote MIDI implementation documents at trunk/apps/sequencers/midibox_seq_v4/doc/, are there any other SEQ V4 MIDI implementation documents anywhere? Or are those documents a complete list of the control-type MIDI messages that the seq will send and respond to? Re: the sysex layout message: F0 00 00 7E 4E <device-id> 01 <num-rows> <num-columns> <num-colours> <num-extra-rows> <num-extra-columns> <num-extra-buttons> F7 Can you explain these a bit? Numrows and num columns are self explanatory - I assume they should be 16 or 8 for a launchpad BLM, depending on how many Lpads you have. How many colours should I say I have? Two? What is the effect of claiming more colours than that? Will the BLM use more than two colours? What values should I use for <num-extra-rows> <num-extra-columns> and <num-extra-buttons> -- should these be [1, 2, 0] on a 2 launchpad configuration, and [2,2,0] on a 4 launchpad configuration? ...and [1, 1, and 0] on a 1 launchpad configuration? Could you explain what num-extra-buttons does, and what extra buttons are available? Is there any additional functionality I could enable by mapping these extra buttons to the bottom row of round launchpad buttons on a 4x4 layout?
  19. Thanks - I have a couple of LPC17's lying around. I guess I'll try the setup with one of those, and I can always upgrade later if I need to. I have a feeling this thing will eventually wind up with a ton of banks/pages, but I can cross that bridge when I get there...
  20. I'm building an NG as a central controller for several synths, so that I'll be able to control parameters for a bunch of synths using one NG interface. Right now I'm thinking the controller will have two 4x20 LCD displays, with 16 or 32 encoders, and about 40 buttons. Is there any real advantage to basing a MIDIbox NG controller on a STM32F4 core? Or could I use an LPC17 core without any real difference in performance?
  21. If you're having trouble running the binary, make sure you've installed the JUCE dependencies: sudo apt-get update sudo apt-get -y install freeglut3-dev libasound2-dev libfreetype6-dev libjack-dev libx11-dev libxcomposite-dev libxcursor-dev libxinerama-dev mesa-common-dev And that you have set the executable bit on the BLM binary file - either right click on the file, select "properties" or whatever, and look for the permissions section - check "allow executing this file as a program" or whatever (not sure of the exact menu names and wording offhand.) Or, from a terminal, in the directory where the binary is: chmod +x [NAMEofBLMbinary] If you still have problems, run the binary from a terminal - that may show some error messages that will help diagnose what the issue is. From a terminal in the directory where the binary is: sh ./[NAMEofFILE]
  22. I don't know. I'm using it headless, with 4 novation launchpads. The launchpads support many simultaneous button presses, not sure about the onscreen BLM emulator.
  23. I got my boards the other day - really quick shipping. I'm going to start assembling them tonight.
  24. Have you looked at FX->Echo? If your LFO effect would just be dropping or raising pitch or velocity, FX->Echo can do that. Edit: oh, I didn't notice the minuses on the last phrase - you mean setting up FX -> Echo so that it doesn't do the same thing on every echo? ...like, it would alternate between rising pitch echos and falling pitch echos? The software doesn't do that now, but it would be easy to program. I was thinking about adding a feature to the Robotizer that would change the parameters of the other effects, but haven't gotten around to it yet. Take a look at the Robotizer code - follow searches for "robot" around in the source code and you'll see where you'd have to make changes to implement your LFO/Echo
  25. Yeah, it should be possible to build it into a midibox pretty easily... There are a bunch of mods on it to adjust the tone/pitch/etc. of the voices, too. I'm thinking two boards with different settings might give a useful set of 8 voices.
×
×
  • Create New...