TK.

yes - the segments are controlled time-multiplexed. Best Regards, Thorsten.

I'm very interested on your findings, because this would also help me to improve the curve definitions in MBCV V2! :) I fixed the unstored SRIO num bug, added a sustain pedal function, and analog inputs can be calibrated in V1.007 -> Best Regards, Thorsten.

V1.007 is available: MIDIbox KB V1.007 ~~~~~~~~~~~~~~~~~ o srio_num now stored on EEPROM o changed default delay settings (required after performance fix in v1.006) o added ain_sustain and ctrl_sustain parameters o the min/max values of the potentiometers can now be calibrated with the set kb <kb> calibrate <off|pitchwheel|modwheel|sustain> command. The documentation has been updated as well: http://www.ucapps.de/midibox_kb.html Best Regards, Thorsten.

V1.005 comes with some nice goodies: MIDIbox NG V1.005 ~~~~~~~~~~~~~~~~~ o support for value MAPs. Various examples can be found under cfg/test/map*.ngc o support for EVENT_CV Various examples can be found under cfg/test/cv*.ngc o AINSER modules now disabled after RESET_HW They have to be explicitely enabled with the AINSER command o the AINSER command now supports the "resolution" and "num_pins" parameters All new options are documented under http://www.ucapps.de/midibox_ng_manual_ngc.html Best Regards, Thorsten.

You are welcomed to take over this part! :) You are right - a calibration procedure is probably the most simple way the configure the firmware. I will consider this. Thanks for your feedback - now I'm sure that sending CC#64 is the right way. :) Best Regards, Thorsten.

No, unfortunately the DEFAULT_BPM_DIGITS_COMMON assignment allocates the complete SR Reason: if you would add additional LEDs, they wouldn't be so bright anymore since the DOUT is used as current source for all 7 segments of the digit. Therefore such an option hasn't been considered in the firmware configuration. Best Regards, Thorsten.

The default configuration is: ; === BPM digits === ; ; set to 1 or 2 to enable the 3 optional BPM digits ; 0: BPM digits disabled ; 1: digits with common cathode ; 2: digits with common anode #define DEFAULT_BPM_DIGITS_ENABLED 0 ; ; define the shift register to which the segments are connected (0=disabled) #define DEFAULT_BPM_DIGITS_SEGMENTS 5 ; define the shift register to which the common pins (cathodes or anodes) are connected (0=disabled) #define DEFAULT_BPM_DIGITS_COMMON 6 You would have to set the DEFAULT_BPM_DIGITS_ENABLED either to 1 or 2, depending on which LED digit you got (your link doesn't make this clear). Here a link to the MBSEQ V4 schematic: http://www.ucapps.de/midibox_seq/mbseq_v4_bpm_digits.pdf MB808 only supports 3 digits (since BPM is working at .0 resolution), therefore connect: - the common line of the first digit to D2 of the DEFAULT_BPM_DIGITS_COMMON DOUT - the common line of the second digit to D1 of the DEFAULT_BPM_DIGITS_COMMON DOUT - the common line of the third digit to D0 of the DEFAULT_BPM_DIGITS_COMMON DOUT Best Regards, Thorsten.

A completely different project -> continue at this site, the guys did a great work: http://www.edrum.info Best Regards, Thorsten.

Hi, this issue only exists under Windows and can be solved by using the GM5 driver with a modified midibox.org_gm5.inf file. Are you already using the latest Bootloader v1.010 and the latest MBSEQ firmware? See also Best Regards, Thorsten.

Cool that it works at your side as well! :) I got very similar proposals from the first users at the german board - it depends on the outcome with MBNG if this will be solved once MBKB has been merged into the MBNG firmware, or (if performance isn't good enough) if I will program the enhancements into the MBKB firmware only. Like for all published applications, the source code of MBKB is available in the repository: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_kb_v1%2F If you would like to help: - you could try to develop an algorithm for a flexible (user-definable) velocity curve. Maybe Spline based? - PitchBend min/max and center handling is also an open topic (I've no idea how to provide a simple configuration interface for this) - sustain: I'm unsure if it's better if a sustain pedal just sends CC#64 (this would already be possible), or if it should prevent that NoteOffs are sent until the pedal is released. CC#64 can already be assigned to an analog input (e.g. you could use the modwheel input for kb 2 and assign it to CC#64, if kb 1 inputs are already allocated) For the "holding Note ON" approach a small firmware extension would be required (the state of all notes is already stored in an array, so that this wouldn't be a big deal). Once the best solution is clear, I could add dedicated sustain pedal inputs to J5B.A4 and A5 Anyhow, the schematic for a sustain pedal can be found here: Best Regards, Thorsten.

It depends on the selected page, e.g. in edit page they would be always on if all triggers are selected. Or are the LEDs enabled regardless of the selected page? Do you see some activity when the sequencer is playing? Best Regards, Thorsten.

Cool! :) I will officially release this version once I'm back home. Yes, the PitchBend and SysEx values are very likely generated from wrongly configured encoder or button elements. Best Regards, Thorsten.

Exactly - I will test this on my Stribe (and I can post a schematic once the DOUT_MATRIX driver has been enhanced :)) Btw.: the DIN/DOUT_MATRIX should already work with your "MBSEQ 16x4 BLM board", because it supports rows=4 mode Best Regards, Thorsten.

I've currently no access to my MBSID and therefore couldn't try out code changes by myself. Your request to provide a command for sending individual parameters would lead to a lot of new code due to all the options (WOPT, engine, etc...) -> see also SID_SYSEX_ParWrite But the biggest problem would be the reduced transfer speed caused by the SysEx Header/Footer overhead. It would be easier to add a special dump transfer mode for Lemur, which has to be enabled with a special SysEx command (later). Today you could already try it out without such a command: In sid_sysex.inc, search for SID_SYSEX_SendDump Then search for "feed WDT" - after the "clrwdt" instruction enter: #if 1 ;; Lemur option movlw 0xf7 ; end SysEx rcall SID_SYSEX_TxBufferPut movlw 0xa0 ; for lemur: start sending common MIDI events rcall SID_SYSEX_TxBufferPut #endif [/code] Now the 1024 data bytes (resp. nibbles) will be sent as Poly Pressure events to Lemur with the same Bandwidth as if they would be embedded into a SysEx stream! :) Due to the "running status" feature of MIDI, 0xa0 only has to be sent once. All following two-byte pairs will be handled as Poly Aftertouch events. Second modification: after the SID_SYSEX_SendDump_I_Cont label write: [code] SID_SYSEX_SendDump_I_Cont #if 1 ;; send checksum movlw 0xa1 ; Poly Pressure, channel 2 - all data sent + checksum rcall SID_SYSEX_TxBufferPut movff SID_SYSEX_CHECKSUM, WREG sublw 0x80 andlw 0x7f rcall SID_SYSEX_TxBufferPut movlw 0x00 ; dummy rgoto SID_SYSEX_TxBufferPut #endif So - with 0xa1 Lemur will get a notification that the complete dump has been sent, and optionally you would also be able to compare the checksum. Best Regards, Thorsten.

Thanks for the nice feedback! :) Yes, I can support the MAX7221 - now where we've generic configuration commands, it isn't a big problem for me to change the purpose of a DOUT_MATRIX by providing additional parameters. I will try this before New Year. J10: yes, will be possible as well. J10 needs a configuration command anyhow, e.g. if it should be used for additional chip select outputs for the LCDs Best Regards (& Merry Christmas), Thorsten.

Ja, aber nicht auf Port J15B (dem zweiten LCD Port), sondern nur auf J15A. Deshalb habe ich nochmal nachgehakt. Wenn aber auch mit der MBSEQV4 keine Ausgabe auf irgendeinem Port erfolgt, dann kann es mittlerweile eigentlich nur noch an den Verbindungen zwischen den LCD Ports und dem LPCXPRESSO liegen. Dazwischen liegt ja auch noch ein 74HC595, und die Platine ist selbstgeaetzt... ich werde nach Weihnachten mal einen LCD Interconnection Test schreiben, womit sich die Verbindungen ueberpruefen lassen. Gruss, Thorsten.

Hi John, an inspiring project; thanks for posting this! :) No, this is very unusual. It sounds like a production failure or a SW issue, it could make sense to inform Schaeffer about this. Best Regards (& Merry Christmas), Thorsten.

Great work! I will definitely use this panel as well once it's ready, and of course I can help you to test all functions! :) Best Regards, Thorsten.

Hi, here is a guide for Windows users: http://www.midibox.org/dokuwiki/doku.php?id=windows_toolchain_quickstart Best Regards, Thorsten.

Yes, two cores can be linked this way, and the MIDI OUT of the first core will still work for common MIDI devices. Best Regards, Thorsten.

Noch ist nichts verloren! In den obigen Bildern sieht man, dass Du das LCD an Port J15B angeschlossen hast. Zum Testen wuerde ich aber erstmal Port J15A hernehmen; J15B wird nur von bestimmten Applikationen freigeschaltet. Bei der MBLC bin ich mir sicher, dass dies geschieht. Doch als Referenz nimmst Du lieber erstmal eine vorkompilierte App von http://www.ucapps.de/mios32_download.html so wie bspw. die MIDIbox SEQ V4. Wenn die Displays damit funktionieren, liegt es doch "nur" an den Compiler-Einstellungen. Gruss, Thorsten.

Yes - that's the purpose of the integrated MIDI merger. Best Regards, Thorsten.

Finally (after a slight modification on my MB16E, so that I can use it for MBHP_CORE and MBHP_CORE_LPC17 :)) -> http://www.ucapps.de/mios/midibox64e_v2_2e.zip Could you please test the changes at your side? Best Regards, Thorsten.

I checked this by measuring the delay caused by the Bank Load - and noticed that it was actually done twice! ;-) So: please try this version: http://www.ucapps.de/mios/midibox64e_v2_2e.zip Now it takes ca. 300 mS to load a bank. Unfortunately I can't make it faster due to the huge bank size (8 groups are loaded at once) Best Regards, Thorsten.

Hi Anders, I'm surprised that it takes so much time to switch between the banks. Could you please check, if you've enabled the "AUTO_SNAPSHOT" option, which dumps all events of a bank to the MIDI OUT interface on every bank change? You could check this with a MIDI monitor. This would take some time - the MIDI bandwidth is the bottleneck. Best Regards, Thorsten.