TK.

Ok, now I understand the problem: the empty labels caused an error message. Accordingly no new .bin file was generated (by intention), and therefore your labels haven't been updated. Probably you cleared the screen in the previous definitions (which were valid), right? I changed the error message into a warning. But since you overlooked the error message, it's very likely that the warning could confusion in future as well... ;-) Best Regards, Thorsten.

The non-functional prototype for Lemur ;-) How about dedicated octave buttons? And two additional buttons/LEDs could be used to enable Recording or Live Playing mode. Best Regards, Thorsten.

Hi Stephan, if diodes are soldered in the wrong direction, you've to change the polarity of the pull-up resistors at the DIN inputs as well. They have to pull the signal to ground instead of 5V If you are using the original MBHP_DINX4 module, search here: http://www.ucapps.de/mbhp_din.html for the keyword "pull-down". If you are using the MBHP_DIO_MATRIX module (-> http://www.ucapps.de/mbhp_dio_matrix.html), just change the polarity with J6 Best Regards, Thorsten.

Btw.: I noticed that MBSEQ calls the slide function glide (as you called it before)... so let's take this term. In order to get Glide working, your synth has to support the so called "SusKey" function (sometimes also called "Fingered Portamento"). The synth will activate portamento whenever keys are overlapping. For some synths (like MBSID V2 in Multi mode) this will also work correctly for polyphonic chords. So: whenever Glide is activated, MBSEQ will play the new notes of a step, and then release the previously played notes to activate glide. If Glide is not active, the length will be played according to the Length Layer (which could overlap as well, or also stretch notes over multiple steps) It sets the velocity to 127. All good synths (such as MBSID ;-)) allow you to assign various parameters to velocity. E.g. MBSID in Bassline mode assigns not only the VCA sustain, but also Filter ENV Decay rate to velocity. Using velocity assignments is the best way, because this ensures that the parameter is changed exactly at the same moment where a new note is played. You can assign one or more parameter layers to CCs to control this as well. But in this case, you would have to set the CC values as usual in the EDIT page. There is no relationship between the ACCENT trigger and CCs @latigid on Prototyping this extension on an iPad is a good idea! :smile: Back to Jumpatron: yes, you are right! Note that a Duo-Colour LED can only display green, red or yellow (mixed colour when both LEDs are active) How about following approach: Red: one or more notes are played outside the displayed octave range, but not in the visible range Green: one or more notes are played in the displayed octave range and not outside the range Yellow: notes are played in multiple octave range (so, partly displayed, partly not displayed) And then use color coding for the octave buttons as well. It could make sense to spend 5 LEDs for the octave buttons for the 5 available octave ranges (they would span 120 notes). This would allow to display the octave ranges, in which notes are played, with yellow colour. And the green colour would display the selected octave Speaking about number of LED/button functions (resp.: DIN/DOUT shift registers): it definitely makes sense to connect the LEDs and Buttons in a matrix configuration. With 1 DIN and 2 DOUTs, up to 64 buttons and 64 LEDs (Duo-LEDs: 32) could be accessed. The MBHP_DIO_MATRIX module fits perfectly for this purpose. For the current keyboard extension layout we would need 32 buttons. 32 inputs are currently free for additional button functions. LEDs: + 2*24 for the notes (Duo-Colour LEDs) + 2*5 for octave selection (Duo-Colour LEDs) + 4 for Gate/Glide/Accent/Fx makes 62 Two LEDs are currently free for other purposes. Best Regards, Thorsten.

Here are the detailed instructions for uploading an application: http://www.ucapps.de/mios_bootstrap_newbies.html Here is also a walkthrough for MBSID for the case that you haven't seen it yet: http://www.ucapps.de/midibox_sid_walkthrough.html Hopefully! (crossing fingers) Best Regards, Thorsten.

Now it's time to upload the .hex file of the MIDIbox SID V2 application. :) Bst Regards, Thorsten.

Hi Marcus, you've to enter: without brackets - the brackets are only used to describe the syntax Btw.: from Christian I got the confirmation that 20 is a good matching value. 50% is probably too much - but you will see this. Best Regards, Thorsten.

You are really mixing things. The shift register MBHP_CORE_LPC17:IC2 works independent from the shift register chain which is used as CS line extension, and connected to J28. Just ignore that IC2 is a shift register, please focus on the J15A port, and take the logic on the MBHP_CORE_LPC17 module as a black box! This would avoid some confusion at your side... ;-) So: please connect all D0 (SCLK) to J15A:E, all D1 (SDA) to J15A:RW, and all DC to J15A:RS The first 8 CS lines are connected to J15A:D0..D7 The remaining CS lines are connected to the outputs of a separate shift register chain which is controlled from J28 I hope that no further explanation is required. Best Regards, Thorsten.

Especially for LCDs it makes sense to check for EBay auctions. E.g. see following hint for a great looking 2x40 LCD: 6 EUR per LCD makes 0.08 EUR per character... Best Regards, Thorsten.

I can really recommend this LCD! I bought 4 of them some weeks ago, they are beautiful! :) Best Regards, Thorsten.

Ok, I see your points. So, the new recommended method is to use a dummy LED event, which will be triggered after startup, and on any bank change. Such as: # This is a dummy LED without assigned hardware (hw_id=2000 not used anywhere else) and without MIDI event. # the purpose of this EVENT item is to print the bank whenever the LCD is refreshed (e.g. after startup or bank change) EVENT_LED id=2000 fwd_to_lcd=1 lcd_pos=1:1:1 label="Bnk%q" Complete example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftemplates%2Flre8x2.ngc As you can see, this method will also allow you to define multiple dummy events to display strings at different positions. Btw.: the same method can be used to print static strings as well. yes, the limitation is 200 characters for the whole command line... but I think that I could use the same code like for .NGC file meanwhile (since it seems to work stable), which would allow to parse up to 1024 characters. There is another limitation: the max. label length is 248 characters - due to the current 200 char limitation of the parser you haven't got the related error message. So - this will be fixed with the next release. /edit: the fix is already in the repository. I can't reproduce this, please provide a downstripped example. Of course, an empty label string shouldn't clear the screen... Best Regards, Thorsten.

Alright. It makes sense that you wait for my version of this extension, because it could be that I will add some additional button functions which you would hardly miss in your layout... To your functions: Glide: ok Accent: ok Tie: is technically the same like Slide for a MIDI sequencer, therefore redundant Rest: is called "Gate" in MBSEQ (with inverted function: note will be played when active) The "last/next step" function (I would call it "Previous/Next step") is redundant, because the datawheel and the Up/Down buttons have the same purpose. But it doesn't hurt to duplicate them. They are at a better reachable position for fast entry with the left hand, while notes are entered with the right hand. I would order the functions differently: Gate Glide Accent Fx Prev Next Fx: this will allow you to enable/disable the MIDI effects for certain steps. Very useful especially in conjunction with MIDI Echo and Humanizer. For the case that polyphonic steps are entered, additional indicators would be helpful to notify, that there are notes outside the displayed octave range. Duo-Colour LEDs for Octave Up/Down could be used for this. And while writing about this: actually Duo-Colour LEDs also make sense for the keyboard so that "normal notes" are green, and "accented notes" are red. Best Regards, Thorsten.

Ooops, sunday again! So it's time for the weekly release ;-) MIDIboxSEQ V4.074 ~~~~~~~~~~~~~~~~~ o "SD Card connected" message not displayed after boot anymore, instead only when the SD Card is exchanged o whenever the ALL function is active, you can now directly select the steps which should be modified with the GP buttons (LEDs will show the selection pattern) o the ALL function has been enhanced: - press & hold the ALL button and move the encoder of the already selected step (marked with >...<) to change all steps to the same value (like before) - if ALL button not pushed (but active), move the encoder of the already selected step (marked with >...<) to change all step values relatively (like before) - NEW: if ALL button is active (regardless if pushed or not), and the encoder of an unselected step is moved, the editor will generate a ramp between the selected step and the moved encoder. This feature has been borrowed from Sequentix Cirklon - thanks for the inspiration! :-) The "selected step" can either be changed with the datawheel, or it will be changed if the ALL function isn't active (as before) Best Regards, Thorsten.

Implementing the LED functions is actually a bit more difficult like the buttons, because the output routine has to differ between different layer modes and configurations. I could help you on this, especially since with the 303 edit view the basics exist: http://www.ucapps.de/midibox_seq/cs4/edit16.gif And I would be interested on a special HW extension for this purpose by myself ;) What is "rest" in MBSEQ terminology? (resp. what is a "rest" function?) Best Regards, Thorsten.

Usually it's set with the source which causes the bank change, e.g.: EVENT_BUTTON id=2000 type=Meta meta=SetBank button_mode=OnOnly range=1:1 lcd_pos=1:17:1 label="Bnk%q" Best Regards, Thorsten.

The mistake is probably only, that you are trying to fix this at the wrong place. I guess that the rows are flipped due to a hardware wiring issue. Accordingly, I would change the routine which selects the rows of the hardware (BLM_PrepareCol) instead of the routine which processes the scanned data. What you need is some kind of mapping: First row selection: 0b1110 (as before) Second row selection: 0b0111 (instead of 0b1101) Third row selection: 0b1011 (as before) Fourth row selection: 0b1101 (instead of 0b0111) The selection pattern will be determined in line 167: // select next DOUT/DIN column (selected cathode line = 0, all others 1) dout_value = (1 << blm_selected_column) ^ 0x0f; The most simple change to flip bit 1 and 3 would be: // select next DOUT/DIN column (selected cathode line = 0, all others 1) dout_value = (1 << (blm_selected_column ^ 2)) ^ 0x0f; Best Regards, Thorsten.

D0 and D1 have to be connected to the same pins like D0/D1 of the first 8 LCDs (this is the serial interface to the GLCDs) Best Regards, Thorsten.

No, inverting means, that the signals on the DOUT output will be reversed. Means: instead of 1, a 0 will be output, and instead of 0, a 1 will be output. This is required for the case that somebody swapped anode/cathode of a LED, or to revert the polarity change of a sink driver. Best Regards, Thorsten.

Correct - this matches with a common DOUT chain as you can see here: http://www.ucapps.de/mbhp/mbhp_doutx4.pdf There is no connection between OE# of SR2 and D1 of the display, because OE# of the "CS line extension" has to be tied to ground like on a common MBHP_DOUTX4 module. I guess that you mean the connection to J15:RW of the core module, which is also connected to OE# of MBHP_CORE_LPC17:IC2 - but this shift register is used for a different purpose and not related to the "CS line extension". Best Regards, Thorsten.

Hi, APP_Init() is always called after power-on, but the USB connection could be delayed (depends on the operating system you are using). Therefore it can happen, that debug messages, which are print directly after power-on, get lost. Best Regards, Thorsten.

Please note: for proper NRPN handling you need V2.043 Best Regards, Thorsten.

The NRPN issue is finally fixed in v2.043 For drums I've currently no solution - it needs some time to work this out so that it works properly for all usecases (not only your own usecase that you mentioned...) Best Regards, Thorsten.

A new version is available: MIDIboxSID V2.043 ~~~~~~~~~~~~~~~~~ o fixed NRPN handling for Multi patches o implemented CCs for Bassline/Drum/Multi Engine See doc/mbsidv2_cc_chart.txt for available CCs o display updated when the patch name has been changed from external Best Regards, Thorsten.

Actually I intended to propose the usage of "sed" for this simple filtering job first, but then thought it would be better to avoid overloading you with so many different tools for such similar purposes ;-) Best Regards, Thorsten.

Die Konfiguration von SysEx Streams ist mit der MIDIbox NG einfacher geworden, siehe auch: http://www.ucapps.de/midibox_ng_manual_ngc.html Auf der anderen Seite kann man davon ausgehen, dass Roman's dedizierte Applikation die beste Loesung fuer Leute sein wird, die mit wenig Kontrollelementen auf saemtliche Parameter zugriffen moechten. @Roman: ich werde Deine Applikation wahrscheinlich dann auch selbst nutzen, ich habe erst letztens meine DB50XG wiedergefunden! :) Gruss, Thorsten.