TK.

It's implemented now, please try it out - works fine at my side! :) -> http://www.ucapps.de/mios32/midibox_seq_v4_092_pre9.zip o new track mode configuration option: "STrg" (Step Trigger) In this mode, the step progression will be controlled from the transposer bus, hence it can either be triggered from a loopback track or from an external MIDI device (MIDI keyboard, sequencer, etc.) Note that each track can be assigned to a dedicated transpose bus (4 busses are available), this allows to control 4 independent step progressions for all 16 tracks. Best Regards, Thorsten.

Hi, I'm glad that you like the device! :) It's possible to configure the MIDI notes which are sent by the drum instruments: enter the MENU->Event page, select the drum instrument with encoder #11, and change the note with encoder #12. E.g. the first instrument (BD) will output C-1 by default, which is in the 4th octave. Lower octaves are C-0, c-1 and c-2, whereas c-2 can't be played because it's note number 0 (interpreted as "no note" by MBSEQ) Best Regards, Thorsten.

The same way how the MB808 UI is working. Please believe me, the encoder usage for track selection wasn't a good idea, I wouldn't do this again... No, the BLM buttons have to switch between BLM sections, and the purpose of a section depends on the BLM mode. If BLM displays the gates of a track, the BLM buttons would switch between track groups. If BLM displays a drum grid, the BLM buttons would switch between trigger layer (resp. drum instrument) sections etc... You could use the jogwheel for this purpose. The function of the datawheel is already configurable, press&hold EDIT, push GP7 to switch between the functions. Additional functions could be assigned to the jogwheel in future. You are right, that this topic needs more planning. Some functions that I "brainstormed" yesterday might be redundant, such as the mute button that you pointed out. Trigger steps are selectable in BLM drum grid mode - again a conflict with your "TPM", an additional handling could lead to too much confusion. I would prefer the following approach: - show different layout options (how many buttons could be added to the jogwheel section) - then we've to start to write a specification for button assignments and usage, this could be done in the Wiki The only way to get a "big picture" and to work out the details to find the best layout. Best Regards, Thorsten.

This works at my side, could you please check with the latest version? http://www.ucapps.de/mios32/midibox_ng_v1_036_pre2.zip Best Regards, Thorsten.

Commando was the very first tune that I played during implementation of the ASID mode as some kind of reference :) AFAIK nobody worked on a "SID sound extractor" yet, this has to be done at the host side (-> computer software) Best Regards, Thorsten.

Yes, this is the rely message. Does "ngr send... OUT1" also output the event at MIDI OUT1? Best Regards, Thorsten.

No, encoder are worse than buttons. Buttons can be operated almost "blindly", encoders require visual focus to the display and could sometimes select an unintended track if not operated careful enough. I noticed this on the MB808 frontpanel - no fun! I would prefer to select tracks, mutes, parameter and trigger layers with the 4th row By providing another button to select the bookmark (BM) function the user could store and restore any kind of other function (see documentation, bookmarks are very powerful, since they not only allow to switch to pages, but also to select tracks, mutes, etc...) Too waggly usage, not useful in live situations! For me such a big jogwheel in the middle doesn't look nice. Better to place it at the right lower corner, and some buttons below. Probably you've to provide an alternative frontpanel for lefthanded users Buttons should be labeled... by giving generic labels 1/A, 2/B, 3/C, ... users will quickly learn the position and sooner or later operate without focusing the labels anymore... Best Regards, Thorsten.

You are right, this is a documentation error: we are counting from left (USB1 is the leftmost digit) Meanwhile corrected at my website To the actual issue: are you sure that the MIDI output is working at all? You could test it with following terminal command: ngr send CC OUT1 1 1 127 This should send CC#1 with value 127 over channel 1 Doublecheck with: ngr send CC USB1 1 1 127 to ensure that the command itself is working... Best Regards, Thorsten.

Hi Chris, I confirm that this can be confusing: encoders define a default matrix pattern, other events won't, hence no pattern is displayed. If you add "led_matrix_pattern=1" to EVENT_AINSER it will work With the next version all events will get this default assignment Best Regards, Thorsten.

I've to spend some thoughts about this. The request makes sense, but to ensure compatibility a new parameter layer type for this kind of Chord handling has to be introduced. This means that instead of only 32 chords in Chord1, and 32 additional chords in Chord2 mode, we would have up to 128 chords available - ideas how to fill the space? ;-) Added to wish list - makes sense, but will need some time to implement this I will check this with high priority Still on the wish list, but lower priority compared to other (especially easy to implement) requests Could be implemented, but I have to experiment with this hardware before I can give a final confirmation Best Regards, Thorsten.

It's still on the wishlist, which means that it will be implemented (sooner or later) Best Regards, Thorsten.

I think that additional buttons will be required, maybe above the Jog Shuttle. They would allow to switch the keyboard into different modes, such as 1 button to select the "normal layout", the 4th row (which is not available on Wilbas frontpanel) is used to select tracks 1 button so that the 4th row is used for mutes 1 button so that the 4th row is used to select parameter layers 1 button so that the 4th row is used to select trigger layers 4 buttons to switch to BLM mode and to select the 4x16 segment maybe some spares if space is available Best Regards, Thorsten.

I remember that I ordered this chip some time ago to work on a Dual-MBHP_IIC_MIDI board, but I'm still unsure if it's worth to work on this. Implementation, documentation and support effort is higher than the benefit (at least at my side) Actually it would be nice if somebody else could implement an alternative solution, do all the required testing and give long-term support. Best Regards, Thorsten.

I'm in contact with the designer. The good news: he plans a public release of all sources, which means that it will be possible to change the HW interface so that it can be directly connected to the core w/o need for serial shift registers! It might even be possible to use a bigger FPGA for the emulation of 8 SIDs, all connected to a single SPI which will be the best way how to control the SIDs from a MBHP_CORE_STM32F4 module. Best Regards, Thorsten.

WS2812B is possible for V4+, but the LEDs consume so much power that the device can't be supplied from a USB cable (strongly recommended todays!) Best Regards, Thorsten.

Zoom control is still on the agenda... ;) If layout of 4x16 RGB LEDs is problematic, I would prefer 4x16 duo colour Best Regards, Thorsten.

No problem, button matrix could also be 4x16: In order to switch between different modes (common button assignments, BLM) a special button will be required. The encoder switches could be used for this purpose Best Regards, Thorsten.

Btw.: advantage of the stickers - people can customize them easily if they prefer different button assignments The font should be transparent Best Regards, Thorsten.

Or stickers on top of the pads, see example from Novation: Best Regards, Thorsten.

Iluminated button caps: DIY! -> Best Regards, Thorsten.

Encoders are important for fast parameter changes with a single hand. Here an alternative idea for a FP layout: However, a potential issue with the adafruit pads is the spacing between the pads: it doesn't allow to add labels But labels are essential for intuitive usage! Best Regards, Thorsten.

@mongrol was the OLED working before? I just tested a MB997D with two common CLCDs - they are working (tested with MBSEQV4) Best Regards, Thorsten.

Great build, and really worth the money! Best Regards, Thorsten.

Hopefully it will be possible to find a more detailed datasheet. Maybe it isn't related to current draw, but to a configuration option. This is based on speculation, but worth to check (because I've no other idea): according to the website this display supports different protocols such as 6800, 8080 and SPI. The 8080 protocol is required, if 6800 is selected instead, a short circuit would happen between the parallel connected data busses during read operations, and this could cause a malfunction (e.g. core reboot) With some luck you will find some bridges on the PCB which show the configurable options on the silk screen. Best Regards, Thorsten.

Could you please provide a link to the datasheet of this display? Best Regards, Thorsten.