TK.

Beta21 is available now: MIDIboxSEQ V4.0beta21 ~~~~~~~~~~~~~~~~~~~~~ o ongoing preparation work for BLM16x16 Features will be described under http://www.ucapps.de/midibox_seq_manual_blm.html o the simple Transpose/Arpeggiator MIDI split function has been replaced by a new bus routing concept. There are 4 busses that can be configured in the MIDI page. Each bus provides a dedicated MIDI port, channel and lower/upper MIDI note to define a keyboard range. o the bus can either be routed to the transpose/arpeggiator function ("T&A Mode"), or it can be used to play the currently selected track "live" ("Play Mode") o Track Mode page: now allows to select the bus over that the transpose/arpeggiator function should be controlled o Record function: whenever active, the MIDI port and channel used for recording won't be routed to Transpose/Arpeggiator/Play bus. o the "Roll" trigger now selects a 2D10 roll instead of 3D08 since it's more useful in most cases. In order to apply customized roll values, please use the roll function of the parameter layer instead of the Roll trigger. o implemented "Roll2" parameter layer function. This alternative solution to "Roll" allows to define the number of step repeats, and the distance between them. o added optional button/LED function for UNDO o fixed MIDI clock issue sent to USB5..USB8 (resulted into multiplied tempo values in some DAWs) o CC assignment displayed correctly in mixer page o LFO CC not sent anymore if track is muted o fixed crash if preset name is longer than 7 characters o fixed step selection of copy function o inverted encoder behaviour in mute page: moving clockwise will unmute, moving counter clockwise will activate mute o if a previously "empty" pattern/map/song is stored without name, it will be labled with "unnamed" now. o LFO effect now works on CC parameters as intended o If a track is in CC mode, a CC/Pitchbender value will only be sent if the gate trigger is set. CCs/Pitchbender events are sent for each step regardless of the gate as before if the track is in Note or Chord mode. o transpose now works correctly on CC and Pitchbender values, but only if the track is configured for CC mode. Transpose will be ignored for CC/Pitchbender events if track is in Note or Chord mode. o AOUT gates now 0V after power-on o some minor bugfixes [/code] Have fun! :) Best Regards, Thorsten.

Go to http://www.findchips.com and enter 74hc165 into the search mask :) Best Regards, Thorsten.

The construction looks very similar to my setup, with one exception: since MBSEQ frontpanel and BLM are separated, my solution is easier to transport. And I can remove the BLM if I need some free place at the desk for something else. In order to connect BLM to my MBSEQ I will use a single cable for MIDI IO and power supply. With optocouplers instead of TTL level digital IO the allowed cable length is ca. 10 m! :) Best Regards, Thorsten.

For STM32/MIOS32 I'm normaly using strtol since it allows to differ between decimal and hexadecimal values. here an example: ///////////////////////////////////////////////////////////////////////////// // help function which parses a decimal or hex value // returns >= 0 if value is valid // returns -1 if value is invalid ///////////////////////////////////////////////////////////////////////////// static s32 get_dec(char *word) { if( word == NULL ) return -1; char *next; long l = strtol(word, &next, 0); if( word == next ) return -1; return l; // value is valid } [/code] You have to add "#include <string.h>" to the header of your .c file Best Regards, Thorsten.

At least the PIC part of the ultracore can be re-used for the BLM :) Best Regards, Thorsten.

I already considered to provide 4 transpose/arpeggiator busses routed to Bus1..Bus4, that can be loopbacked or controlled from keyboard splitzones (and now also from BLM16x16+X). And a "play through" function is planned as well. This concept is similar to your proposal, as each track can select the desired transpose or arpeggiator zone individually. Advantage compared to your idea: it fits better with the loopback mechanisms! I don't like the velocity option - it makes the configuration more and more complicated and especially intransparent! I mean: you would probably know how to use it, but the next guys would think that transpose seems to be buggy if they don't remember that they activated such a strange option by fault. Btw.: this is the wrong topic to discuss about MBSEQ features. Your request will probably get lost here! Best Regards, Thorsten.

Wow! Now it becomes interesting! :) Best Regards, Thorsten.

P = U*U/R = 5V*5V/10000 Ohm = 0.0025W So, you could even use 1/400 watt resistors :) Best Regards, Thorsten.

You won't be able to edit parameters when GP encoders and buttons are so far away from the LCDs! Adding encoders to the BLM and/or MBSEQ circuit could be possible, but I'm not sure if the SRIO chain can be scanned stable enough if the SCLK cables get so long! Up to 10 free DIN registers could be added to the PIC (= up to 40 encoders), and since this chip drives the signal lines at 5V push-pull, it would probably better to add the encoders there. But as already mentioned in another posting, I'm much more happy with a desktop solution, resp. a separated BLM that sits flat on the desk. Best Regards, Thorsten.

From my experiences with the BLM16x4 that I built into a rack case a separate BLM that sits flat on the table is definitely better than a rack mounted option! I haven't got the new rubber button order yet, and will need a frontpanel before I'm able to mount them. Before other people are trying this, I recommend to wait for my tests. I assume ca. 50 EUR - no? You would save 35 EUR, but would get a robust and easy to solder solution in return. Maybe my warning wasn't clear enough: don't do this at home kids! ;) Probably yes See http://midibox.org/forums/index.php?app=gallery&module=images&section=viewimage&img=279 The cables are so thin, and the circuit is so large that a picture doesn't really help. The schematic http://www.ucapps.de/mbhp/mbhp_blm_map.pdf gives you a better overview, but if it doesn't make sense to you, it's definitely better to wait for a PCB, because otherwise chances are high that you've to spend much more time to find and fix wiring errors!!! Best Regards, Thorsten.

For this video I preferred the lowest velocity at the bottom since it is hard to find the lower keys with a camera before your face (thats the reason why I mostly used the upper buttons for all modes ;)) I will provide a swap option so that people can decide themselves. A big advantage of having the loudest keys at the bottom: it will be easier to change the transpose key with a hand that is playing/holding notes. Btw.: I also consider to add a (horizontal) keyboard split option. Only 8 velocity values will be available per instrument, but they can be played in parallel, resp. it won't be required to switch between the tracks. And the mode selection buttons will be changed to the lowest "extra column" keys, so that the most important modes can be switched with a single hand. Soon! Btw.: good that you stopped your activities with the PCB layout, as this gave me some time to reconsider the usage and arrangement of extra buttons. :) yes. And switching between the patterns can either be done immediately (the way I prefer), or synchronized to the measure. It gives you exactly the same functions like the MBSEQ V4 Pattern page, just more direct access. Btw.: muting is possible with the extra column by clicking a button twice (first click selects a track, second click mutes a track) It's your own choice if you prefer a traditional connection via MIDI compatible cables (with optocouplers) or a direct, digital connection. Using optocouplers decouples the BLM circuit and allows long distances. Digital I/O over long cables could be unstable in a noisy environment. One of the 5 UARTs is available at the JTAG port J3 that you don't use yet. This additional MIDI port will be enabled in one of the next MBSEQ releases. I haven't checked the layout, but it can be assumed that any button/LED matrix is compatible with the firmware. Sometimes the mapping has to be adapted in the software, alternatively you have to ensure that the matrix is connected exactly like documented here: http://www.ucapps.de/mbhp/mbhp_blm_map.pdf Best Regards, Thorsten.

In this case it could be a good idea to change the matrix structure to 8x8 instead of 16x4. This would give us 4 quarters, and between these modules there are only the SRIO connections to BLM_SCALAR modules. It would require some firmware changes, but so long only a second variant is required to simplify the HW, it would be ok. This isn't feasible with a double layer board, because there are too many crossing traces between buttons and LEDs. We would need to use a multi layer PCB, and thats expensive. dito, same problem with crossing traces. Please identify the costs before this discussion goes into the wrong direction. So, we have already three plans that contradict each other - are there other opinions; how should your BLM16x16+X look like. (I will start a poll once enough frontpanel ideas have been collected) Best Regards, Thorsten.

The keywords in the manual are "metronome", "copy", "clear", "edit page", "track selection" Best Regards, Thorsten.

Unfortunately this isn't possible. There is no free memory anymore, there is no spare fast accessible MIDI port, and the firmware structure doesn't allow to run low-priority tasks so that BLM handling won't affect the sequencer timings. All the reasons why I switched to a new platform. Best Regards, Thorsten.

Hi Grizz, how is your MBSEQ powered? Notebook PSUs (but sometimes also PSUs of desktop PCs) are mostly too weak. This can lead to such effects that sometimes the core is working, sometimes not. Sometimes the USB MIDI port will be found, sometimes not. The best solution is to connect the MBSEQ to an USB hub with dedicated PSU (1A or more). Alternatively you could use the external power option of the core. Best Regards, Thorsten.

I opened a separated forum section for discussions about the MIDIbox BLM, since this project is not tightly coupled with the MIDIbox SEQ project, but can also be used standalone. Schematics: mbhp_blm_scalar.pdf the "BLM_SCALAR" module mbhp_blm_scalar_module_interconnections.pdf interconnection diagram. 5 x BLM_SCALAR modules are required for a complete BLM16x16+X mbhp_blm_map.pdf the mapping between BLM_SCALAR and Buttons/Duo-LEDs. I'm not planning to layout the PCBs by myself, but volunteers already evinced to help out! :) Just start to coordinate your efforts here. Some input from my side: as you know I created the BLM16x16+X on veroboards (link to Gallery) For me this was less time consuming than layouting and ordering PCBs, especially since at the time where I started this project it wasn't clear if the SRIO hardware will work stable - I used tricks that I never tried before to reduce the chip count. With the prototype I've proven that the concept is working, so that I can release the schematics for layout. If somebody really plans to build the circuit on verboard like me instead of waiting for the PCBs, be warned that you need some soldering experience, a lot of time and especially patience! It took me ca. 40 hours to complete the BLM16x16+X on verobards. It was hard work and I would never do this again! ;) With PCBs I expect only ca. 15 hours work, a more stable construction, and less risk for wiring errors (-> newbie friendly). My costs so far (all parts ordered at Reichelt): LED 5 RG-3 Duo-LED, 5mm, 3pin, rot / grün 300 45,00 Euro TASTER 3301B Kurzhubtaster 6x6mm, Höhe: 9,5mm, 12V 300 30,00 Euro 1N 4148 Planar Epitaxial Schaltdiode, DO35, 1 300 6,00 Euro To speed up the wiring I used "verowire" (german: "Fädeldraht"), and I used 7 x "H25PR200" veroboards which won't be required for a PCB based solution, therefore they are not listed in the list above. I strongly recommend you to order 300 LEDs/Buttons/Diodes as well although only 289 are used. E.g., at my order Reichelt only sent me 296 LEDs instead of 300 - good that these were spares! I had the remaining components for the 5 BLM_SCALAR modules + 1 PIC based MBHP_CORE already in my "personal stock". If you are interested in the part numbers you will find the references at the MBHP_DIN and MBHP_DOUT page. Layout suggestions: in the last months I got some mails about how a BLM layout could look like, and this only showed me that it will be very hard to find a universal solution. E.g., somebody proposed to prepare the layout for different button footprints. My comment: due to the increased amount of drill holes this will lead to much higher costs for everybody. Somebody else proposed to use RGB LEDs instead of Duo-LEDs, since they are cheap at EBay My comment: this will increase the costs for everybody again, and it will be hard to find the same LEDs at such a high amount. E.g., consider only 30 people would like to join the PCB order - they would have to find ca. 8700 RGB LEDs from the same seller, or some of the people would have to buy more expensive RGB LEDs from a regular electronic shop. Another point that needs to be considered: for the BLM16x16+X I already chained 15 74HC595, MIOS8 supports 16 DOUT shift registers maximum. Increasing the amount of DOUT registers to control the blue LEDs will lead to difficult software changes. Third point: RGB LEDs draw much more current, especially more than Red/Green LEDs. Blue LEDs probably require additional transistors (or ICs) as source driver. The additional 74HC595 and these source drivers will require a different BLM_SCALAR module - again it doesn't make sense to bring this into an universal layout that is intended for my original project. I'm sure that most people will be happy about a cost efficient solution with Red/Green colour LEDs (like me). Buttons: this will also become a difficult topic. I will use these ones: But I'm not sure if this construction will be stable enough. A better solution could be the usage of the same buttons and caps that where used on Wilba's MBSEQ frontpanel. Partitioning the PCBs: the SRIO and BLM circuit has already been separated. The SRIO boards are stacked under the BLM board. It has to be considered if a huge BLM board is better than splitting the circuit into two or three parts (think also about the reduced shipping costs...) For the BLM_SCALAR boards I recommend separate modules for each 16x4 matrix, because it is too difficult to plug the board into more than 2 large dual pin header sockets. Note that this approach would also allow you to use the same BLM_SCALAR boards for different BLM board designs! Matrix routing: can be changed if really required. The firmware has to be adapted accordingly (changes are difficult for somebody who never worked with forward/backward matrix transformations before, see main.c) Therefore changes in the routing are only recommended for people with software programming skills. Additional features: I will add 6 faders to my BLM16x16+X, because I find it important to get the possibility for manual sound changes with one hand, while sequences are changed with the other hand (therefore it's better to have the close to the matrix). The firmware is prepared for up to 8 pots/faders. More informations/suggestions on request. However, my hope is that this will become a community project where experienced people will help out and where I don't need to support you that much! I could be interested to join the PCB/kit bulk order as well! :) /Update Oct-2015: after 5 years finally we got a kit created by Latigid On! -> http://midibox.org/forums/topic/19736-blm-16x16x-build-guide/ /Update Jan-2016: new firmware blm_scalar_v1_1 can be downloaded from http://www.ucapps.de/mios_download.html It contains prebuilt hex files for various hardware configurations: o project_without_ain.hex -> without AIN enabled (use this if J5 pins not connected to ground) o project_with_4_mapped_ains.hex -> for Latigid On's BLM PCB layout, only 4 faders used o project_with_4_unmapped_ains.hex -> AIN pins are mapped 1:1 o project_with_8_mapped_ains.hex -> for Latigid On's BLM PCB layout if 4 faders + 4 extension AINs are used o project_with_8_unmapped_ains.hex -> AIN pins are mapped 1:1 /Update Jan-2016: if you are using a PIC18F452, it's required to change the PIC device configuration while flashing the bootloader: the brown out reset level has to be changed from 4.5V to 2.7V as shown in this picture: Otherwise PIC could be reset sporadically (depending on the number of enabled LEDs) because the voltage level could fall below 4.5V! This change is only required for PIC18F452, other pics (such as PIC18F4620 and PIC18F4685 will work w/o this change). Unfortunately this change can only be done with a PIC programmer. Please contact me for the case that you don't own a PIC programmer. I could send you a replacement PIC18F452 Alternatively use a PIC18F4620 or PIC18F4685 if you own one Best Regards, Thorsten.

Thank you for the great feedback! :) For discussions about the construction (and coordination for PCBs/kits) I created a new forum section: http://midibox.org/forums/index.php?/forum/43-midibox-blm/ I used virtual instruments that are part of Logic Studio 9: Mostly presets, but with modifications to harmonize the sounds. + Stylus RMX as a drum sampler (I don't use the beatslicing mechanisms): They are already working together. MBSEQ V4 directly controls the LEDs and receives button changes. Whenever a track or step or mode or whatever is selected on the BLM, MBSEQV4 directly jumps to the appr. edit screen so that step informations are displayed and values can alternatively be changed with the common control surface. :) The same vice versa: if you select a velocity, length, CC or similar parameter layer, the value can be modified on the BLM16x16 as well (but only with 4 bit resolution per step of course) This for example allows you to draw waveforms :) Best Regards, Thorsten.

MBSEQ V4 remote controlled by my new Button/Duo-LED matrix prototype. The frontpanel hasn't been created yet, and it's difficult to push the mini buttons without button caps. But playing with this toy is already a lot of fun! :) The BLM firmware is running on a dedicated PIC based core module and communicates with MBSEQ via MIDI. The optimized protocol is fast enough to achieve high refresh rates between 350 fps (if only a single line is changed) and 20 fps (if all 512 LEDs are changed). Best Regards, Thorsten.

Finally I was able to reproduce this - the MIDI clock was sent to the non-existent USB5..USB8 ports, and Live mapped these ports to USB4 It will be fixed in Beta21. Best Regards, Thorsten.

Hi Trevor, that's ok for me :) Best Regards, Thorsten.

My plan is to give each button a useful function. But you are always free to remove functions that you don't like and to add your own code. Some programming examples can be found at http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fcore%2Fseq_blm.c No problem. :) Best Regards, Thorsten.

It's already implemented as alternative function for the metronome button (press MENU + METRONOME) Unfortunately you haven't told us if you are using V3 or V4, this makes it difficult to give you an explicit help :-( MBSEQ V3 users: If you want to use the METRONOME button to directly access this function (w/o pressing MENU), replace DIN_ENTRY SEQ_BUTTON_Metronome, 1, 3 [/code] by: [code] DIN_ENTRY SEQ_BUTTON_ExtMIDIStart, 1, 3 in your setup_*.asm file If you want to assign a different/additional button, just add a new button entry with the appr. SR and pin number MBSEQ V4 users: edit this entry in your MBSEQ_HW.V4 file on SD Card BUTTON_EXT_RESTART 0 0 [/code] Best Regards, Thorsten.

Isn't it great to have 4 independent USB ports that give you access to up to 64 MIDI channels? ;) Use models: you want to generalize/improve the routing inside your DAW, or you are using a Windows PC and want to send MIDI data to different programs w/o using virtual MIDI ports to split the streams. If you don't see any use for 4 USB MIDI ports, always use USB1 and ignore the others. Probably you selected a pattern for group #3 that was previously pre-initialized for group #2 The MIDI channels can be configured in the EVENT page - they are not strictly tied to the group or track number, but free configurable and stored in the pattern itself. This gives you highest flexibility (e.g. different patterns can send to different ports and MIDI channels) Best Regards, Thorsten.

I real giant frontpanel (* :drool: But there are some things that need to be considered: you placed the BLM at the top of the panel, which means that when you are pushing buttons you won't see the LCD output. But for some BLM modes it might be important to get a direct response from the LCDs. Therefore I propose to place the BLM below the common control surface. The 16 "extra column" and 16 "extra row" (I haven't found a better name yet) buttons/LEDs are missing. They are important to select modes/tracks/step views and maybe other features (like loops, sections, parameter/trigger layer, octaves, special effects) directly. Also the "shift" button is not there (lower left corner of my BLM16x16+X) - thats one of the most important buttons to control the entry. E.g., pressing SHIFT will allow you to select the BLM mode with the 16 "extra column" buttons that are normaly used to select and mute tracks. It will allow you to accent steps with the BLM in pattern edit mode. etc. Currently I'm in the progress to implement the BLM modes and to find an intuitive interaction scheme. Once most of the modes have been implemented and I'm happy with the solution, I will finalize my own frontpanel (e.g. adding labels to the extra buttons) and document the project. So long I haven't reached this state, I can only recomment: be patient please and design your frontpanels based on my specs, otherwise you won't be able to use most of the features later! (I'm not willing to implement alternative solutions for reduced BLMs, because it would be too much work and the usage would be really ugly - so cumbersome like on most monome apps ;)) I will document the schematics in the next days and start a separate topic for this. Basically it consists of 5 chained "BLM_SCALAR" modules that are documented here: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fschematics%2Fmbhp_blm%2F (but note that the Jx sockets are combined now to two 2x10 sockets) A schematic which documents the matrix construction (connections between rows and columns) isn't available yet. It requires a PIC based MBHP_CORE module with the "blm_scalar" firmware: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm_scalar%2F I consider a PIC18F4550 based USB option as well, but I'm not sure if this is really for interest... Communication between MBSEQ V4 and BLM is done via MIDI. The protocol is documented in the README.txt file of the application - it's really fast! And it's generic enough so that the BLM could be controlled from other applications (e.g. PC/Mac based) as well. The MBHP_CORE_STM32 module has some spare "midi" Rx/Tx ports available on the JTAG connector, one of them will be used so that no common MIDI IO pair has to be sacrificed. Thats all for now. My BLM is running very stable btw. - I'm surprised a bit because I expected a) a higher current consumption and b) issues with the shared DOUTs as line control driver for LEDs and buttons (the only solution to reduce the DOUT chain to 15) - but it works :) If somebody could create a PCB for the matrix (once schematics are available), it would be very helpful. Best Regards, Thorsten.

Don't worry, all 100 nF caps only exist to meet certain design rules, but your sammichSID will perfectly work even if they are not stuffed. If you want to feel better, you can use *any* 100 nF cap that is available in your local electronic store, there is no need to spend some $$ for mouser shipping costs. Best Regards, Thorsten.