TK.

Hi Chris, adding a resistor (e.g. 470 Ohm) to between the core output pin and WS2812 is probably a good idea, see this posting for the arguments: https://electronics.stackexchange.com/questions/177019/why-does-a-resistor-in-my-neopixel-data-line-work-at-all The LED should turn off once the Core starts to drive data into the chain. Enable the "fastboot" option so that this happens as fast as possible Best Regards, Thorsten.

The square is at the same side like the notch, and it shows to pin number 2 (because the connector is mounted at the bottom of the LCD, and not at the top) This can be very confusing, therefore I prefer pictures ;) Best Regards, Thorsten.

Where are the notches - please compare with: Best Regards, Thorsten.

I updated the documentation at the bottom of this page http://www.ucapps.de/mbhp_core_stm32f4.html It shows how the LCD should be connected And I've some good news: I tried the wrong connection with one of my old LCDs - and this didn't fry the LCD. Instead, the Lumi pot changed the contrast - exactly the same effect noticed by @Nirokesan Changing the connection again - LCD working again! :) So, I think that my statement, that a wrong connection destroys the LCD is wrong, I just never tried this. ;) Actually this was based on experiences with the PIC based MBHP_CORE module, which had a different pinning. For 32bit cores a new pinning has been introduced, which seems to be fool-proven. And also based on the circuit this makes sense (although it wasn't my intention): Vs/Vd will be connected to B-/B+ if the connector is rotated, so that the Lumination pot controls the LCD supply current instead of the backlight supply. Best Regards, Thorsten.

For me it's very interesting, that we now have a second case with similar symptoms. Maybe this gives me the missing hint for the root cause. Questions to you: did you ever connect the LCD cable the wrong way by accident? Please don't try to change the cable orientation - this could destroy the LCD. If you are able to change the contrast of the black bars with the contrast pot, you know that it's currently connected the right way which LCD are you using exactly? does the same happen if only a single LCD is connected? could you please check the connections with the "testlcdpin" command and report the measurements? I built different STM32F4 core modules in the past, some of them are frequently used - and I never noticed such a problem. But there might be a general difference in my configuration: in the bootloader, I enabled "fastboot" mode. Could you please try the same at your side? The setup procedure is documented here: http://www.ucapps.de/mios32_bootstrap_newbies.html Best Regards, Thorsten.

A new version is available: MIDIboxSEQ V4.094 ~~~~~~~~~~~~~~~~~ o support for Antilog Frontpanel. The appr. HW configuration file can be found under hwcfg/antilog/MBSEQ_HW.V4 o enhanced COPY/PASTE/CLEAR functions for following pages: - PATTERN page: copy/paste/clears all patterns. Special function: by pressing COPY+PASTE the patterns will be pasted into the next slots - PARSEL page: copy/paste/clears the currently selected parameter layer only - TRGSEL page: copy/paste/clears the currently selected trigger layer only - INSSEL page: copy/paste/clears the currently selected instrument only (useful for drums: corresponding trigger any parameter layers are cleared) o improved ALL button behaviour o New worflow for PATTERN page: GP 1/2, 5/6, 9/10, 13/14 allow to select group as well especially interesting for Antilog Frontpanel: Selection buttons can be used for mutes) o New workflow for MUTE page: Whenever a track or parameter layer is unmuted, it will be automatically selected o EDIT page: improved handling for chord layers o moved some configuration settings which were previously part of the MBSEQ_HW.V4 file to the Options page, so that they can be changed without a file editor: - MIDI remote key (or CC) - Track Selection CC - MIDI OUT Runtime Status Optimisation - MENU button assignments o support for "Shadow Out", which will forward the MIDI events of the currently selected track to a specified MIDI port and channel (e.g. can be used to visualize played notes with an external device). Select the port/channel in the OPTIONS page. o Metronome page removed. Please configure the metronome function in the Options page. o Pattern banks can't be modified by default anymore, because they are typically assigned to group 1/2/3/4, changed bank assignments can confused users to much. If somebody still finds this feature useful: it can be enabled in the Options page @u-link your requested MIDI routing option is called "Shadow Out" and works independent from the MIDI router This version should also satisfy frequent requests for trigger/parameter/instrument copy/paste/clear functions Best Regards, Thorsten.

@v4: which core are you using? MBHP_CORE_STM32, MBHP_CORE_LPC17 or MBHP_CORE_STM32F4? @u-link: I added your request to the wish list. Instead of a MIDI router option, I will probably provide this as some kind of global "duplicate" option intended to satisfy your use case, so that additional special functions could be added later without taking limitations of the MIDI router into account. The "mixer map on encoders in mute mode" is also on the wish list now (together with your other proposals) - I've to consolidate this with other ideas around mixer map usage. This could become an optional mode which can be activated by people who know how to use it (otherwise it will confuse common users too much) Best Regards, Thorsten.

Thank you! :) As mentioned by Peter, the recording function will forward incoming MIDI events to the selected track. One of the 8 buttons above the jogwheel is called "Tracks", once activated you can change the track with the select buttons in the middle. In the video I'm mainly using the select buttons to control mutes and phrases. Since unmuting a track will also select it (upcoming feature in V4.094), mostly I don't need to switch to the "Tracks" function anymore. In the Mute page the select buttons seem to be redundant, because the GP buttons control the same. But: the mute function will stay active when you change to another page, which is quite useful in certain situations. Here an overview about the select button assignments: Bookmark: e.g. can be used to switch to predefined pages, to mute/unmute/select multiple tracks, etc... StepV: selects the step view Tracks: selects the tracks (and group which belongs to the tracks) ParL: selects the parameter layer TrgL: selects the trigger layer Inst: selects the instrument (especially useful for drum tracks) Mute: as the name says Phrase: as the name says Best Regards, Thorsten.

New fronpanel video:

I need some time to thing about how to support this issue remotely... Best Regards, Thorsten.

There is a display manager located in this file (read the header for more information): http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fcore%2Fseq_lcd.c However, each page heavily relies on a 2x80 screen. See the various seq_ui_* files in this folder: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fcore%2F&# It will be too much effort to adapt this to other screen sizes, you won't see the necessary information to handle the sequencer efficiently. However, if you find any other display which allows to display 2x80 characters (or more, maybe a graphical LCD?) then this could help - but the coding job will be at your side. Best Regards, Thorsten.

This isn't plausible, it really looks like a strange hardware fault which is impossible to debug remotely for me. :-/ Did you ever connect the LCD the wrong way? From software point of view, the LCD configuration can't be changed directly, especially not from the MBSEQ_HW.V4 file. There is only one way to select a different LCD type (which could result in such a effect), and this is via the bootloader update application. So, if you want to doublecheck the unlikely event that for some unknown reasons the LCD configuration has been changed, you could upload the bootloader update app, enter "help" and check the selected LCD type which is printed by "help". It should be 0x00 This app has the same "testlcdpin" command, so it also provides a nice way to doublecheck the hardware with an alternative firmware build. Best Regards, Thorsten.

To the "testlcdpin d1 0" check: do you see the same effect if no LCD is connected? Best Regards, Thorsten.

The core itself doesn't require a new firmware, but the frontpanel required some changes which are implemented meanwhile. Here a precompiled binary: http://www.ucapps.de/mios32/midibox_seq_v4_094_pre3.zip The appr. configuration file is located under: hwcfg/antilog/MBSEQ_HW.V4 Best Regards, Thorsten.

There are two intended use cases: all patterns (which are showed by the PATTERN page) can be copied into a buffer with the COPY button. Then you can select other patterns, and PASTE the buffer into these slots. all patterns (which are showed by the PATTERN page) can be duplicated into the next pattern slots This was not possible before - it was required to go into the SAVE page and to store all 4 patterns into new slots is implemented this way with this behaviour it wouldn't be possible to paste or duplicate all patterns at once anymore, but this is one of the major use cases. This is unusual and not required This isn't required, because for both use cases the currently visible patterns have to be copied into the buffer, hence this operation can be done when the COPY button is pressed. Best Regards, Thorsten.

If this helps: it should be possible to forward SysEx streams with MIDIbox SEQ if source and destination channels are set to "All" Best Regards, Thorsten.

This will lead to unintended side effects which have to be avoided. E.g. the recording (and live) function has to keep track of the played keys (and it also measures the delays between Note Off and On) - by switching to another channel, this information will get lost and the recording function won't work properly anymore. It's the same place which has to be made ready for 16 channels... not possible for a common V4 firmware. Best Regards, Thorsten.

I added this request to the wish list, but note that due to the much higher memory consumption (recording structs will allocate 16 x more RAM) such a feature would only be feasible with MBSEQ V4+ running on a STM32F4. It can't be made available for STM32F1 or LPC17 Best Regards, Thorsten.

It works! :) Best Regards, Thorsten.

Did you select the right interface (AOUT_NG) with GP16 encoder? If yes: there is a special testmode accessible via MIOS terminal. Just open MIOS Studio and enter "testaoutpin", this gives you some instructions. Best Regards, Thorsten.

It seems that your repository contains expired source files, this compile problem for LPC17 has been fixed some time ago. Just update your subversion repository Best Regards, Thorsten.

Hi, you should consider to connect the RGB LEDs to a LED matrix, this is less expensive and also reduces the number of wires. E.g. a 8x16x3 matrix consist of 7 x 74HC595 and allows you to connect 128 RGB LEDs. Then just add another 8x16x3 matrix for the second deck. Do you know the MIDIbox NG application? It supports such features out-of-the-box: http://www.ucapps.de/midibox_ng.html Best Regards, Thorsten.

AFAIK there is no forum posting about this so far. The shift registers are service from MIOS32_SRIO, this code has to be duplicated (and button related functions have to be removed): http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2Fcommon%2Fmios32_srio.c Btw.: why do you need the second SRIO chain? Wouldn't it be easier to enhance the first chain by +16 SRs? Best Regards, Thorsten.

Fine! :) For common users the relation between patterns and mixer isn't obvious, it could be very confusing. Especially for those who use only a single mixer map for all patterns. Best Regards, Thorsten.

You got mail. Best Regards, Thorsten.