TK.

If you could send me a sample, this would be great; it would be a nice test vehicle for me. Best Regards, Thorsten.

Hi, from my point of view, this is possible, but mainly depends on the effort you want to spend for the implementation. Performance-Wise the STM32F4 is a beast, this is what several MIOS32 benchmarks are showing. Typically STMF4 is 2 times faster than a LPC1769, and 3.5 times faster than a STM32F1 Compare against ATmega: see for example EEMBC benchmark comparison charts: http://www.eembc.org/benchmark/index.php Typically STM32F4 is 5..6 times faster than a ATmega644 You are right, that by moving to a 32bit architecture additional performance improvement can be expected, and you can take advantage of it and increase the sample rate & accuracy. If performance is still not sufficient, then consider to replace timing critical routines by hand optimized assembly code. This is what Xavier did in his Preen2 FM project: http://ixox.fr/preenfm2/ Best Regards, Thorsten.

I debugged this again and finally found the root cause: loading the 4 patterns took more time than expected, therefore the last pattern was sporadically out-of-sync depending on the CPU load. The pattern load is now running with higher priority (2 times faster) which should solve the issue. Could you please check this at your side? -> http://www.ucapps.de/mios32/midibox_seq_v4_081_pre4.zip Best Regards, Thorsten.

No, because in a 8x8 DOUT matrix the LEDs are only activated for 12.5% of the time The brightness also depends on the LEDs you are using. A "blacklist" (which also lists the good ones) can be found here: http://www.midibox.org/dokuwiki/doku.php?id=mb-lre8x2cs_pcb Best Regards, Thorsten.

Not really (too difficult) I could provide a save_patch and load_patch command in the terminal if this helps The first patch will be loaded automatically after startup - and will then contain your default settings. Best Regards, Thorsten.

The DAC pins are not available at J10B, but on the STM32F4DISCOVERY board. See http://www.ucapps.de/mbhp/mbhp_core_stm32f4.pdf search for "Audio DAC" Best Regards, Thorsten.

I tested it on a V4L yesterday. Please try the latest version: http://www.ucapps.de/mios32/midibox_seq_v4l_082_pre3.zip Best Regards, Thorsten.

Thanks for the files! I was able to reproduce the sync issue at my side, but after 1 hour of analysis I still haven't fully understood why it happens. However, I found a workaround which might be acceptable: if a pattern is already loaded and actively running, it won't be reloaded anymore. I guess that most users will prefer this handling anyhow, because interactive changes in the pattern won't get lost. Please try this version: http://www.ucapps.de/mios32/midibox_seq_v4_081_pre3.zip Best Regards, Thorsten.

Than longer I'm waiting, than better ideas... ;-) Meanwhile I think that the best way would be to give direct access to the AOUT_PinSlewRate*, AOUT_PinPitchRange*, AOUT_PinPitch* functions of the AOUT driver via meta events, so that any controller could change them directly. TODO marker Best Regards, Thorsten.

The most simple strategy would be the following: - download the repository into a separate directory and change your MIOS32_PATH accordingly - change the PLL frequency configuration in mios32/STM32F4xx/mios32_sys.c, because STM32F401 can only be clocked at 84 MHz I assume that the corresponding SFR configuration can be found somewhere in the internet - compile a new bootloader under bootloader/src with "make STM32F4DISCOVERY"; this will refresh mios32/STM32F4xx/mios32_bsl_STM32F4DISCOVERY.inc (this step requires a perl installation) - recompile bootloader/updater and program it into the flash If this already helps, let me know about the changes and I will consider MIOS32_PROCESSOR=STM32F401VC in the main branch, so that you can use a common repository again. Best Regards, Thorsten.

You've to connect the analog input, Gnd, Vss, touchsensor as well. So, actually really a nice work. :) Best Regards, Thorsten.

Currently only the global settings can be saved from the SCS. Patches can only be saved from the Lemur patch. As I can see, there is still some work for a public release... :-/ Best Regards, Thorsten.

I second that! Best Regards, Thorsten.

Hi, yes, not required for J16 J16 (SD Card) has to be supplied with 3.3V, therefore J24 should select 3.3V J25 and J26 should select 5V No, please install 220 Ohm arrays for J8/9 and J19 yes Best Regards, Thorsten.

Let's take this into the Wishlist for the STM32F4 based "MIDIbox SEQ V4 Plus" Best Regards, Thorsten.

MBSEQ isn't a USB host device as well. This could become a feature of the STM32F4 based "MIDIbox SEQ V4 Plus", but it has low priority at my side (because I know that this will result into some remote troubleshooting for devices which I don't own by myself) Best Regards, Thorsten.

Problem was related to a bug in Lemur - see also Best Regards, Thorsten.

It's a bug in Lemur! "<variable> |= <value>" isn't working anymore. I added a workaround ("<variable> = <variable> | <value>") which solves the issue - patterns are displayed correctly again! :smile: -> MIDIbox_BLM16x16+X_v1_003.zip for Lemur Best Regards, Thorsten.

Ok, LEDs now lit according to the gatelength. :smile: I spent some more thoughts on this: actually it's better if the entire sequence is cleared with CLEAR+SEQ1 resp. CLEAR+SEQ2. And the GP buttons just clear the related track without hidden conventions (e.g. it wasn't obvious that GP#4 only clears PitchBend). In combination with a changed CC line assignment algorithm the CC Clear function finally becomes more useful: o CLEAR button now allows to clear individual tracks with the GP buttons: - CLEAR+SEQ1: clear entire Seq1 + configuration (*) - CLEAR+SEQ2: clear entire Seq2 + configuration (*) - CLEAR+GP1: clear note triggers (values are kept but not played) - CLEAR+GP2: reset velocity values to 64 - CLEAR+GP3: reset note length values to half step - CLEAR+GP4: clear Track 4 (Pitchbend + last CC lines) - CLEAR+GP5: clear CCs of Track 5 - CLEAR+GP6: clear CCs of Track 6 - CLEAR+GP7: clear CCs of Track 7 - CLEAR+GP8: clear CCs of Track 8 Same for GP9..16 for Seq2 (*) track configuration won't be changed if 'PasteClrAll' set to 0 in MBSEQ_GC.V4 file o changed the track and layer assignment algorithm for CCs in recording mode: Previously new CC lines were recorded into Track 4, Layer B upwards. Now they are assigned the following way: - 1st CC line is recorded into Track 5, Layer A - 2nd CC line is recorded into Track 6, Layer A - 3rd CC line is recorded into Track 7, Layer A - 4th CC line is recorded into Track 8, Layer A - 5th CC line is recorded into Track 8, Layer B - 6th CC line is recorded into Track 8, Layer C - 7th CC line is recorded into Track 8, Layer D - 8th CC line is recorded into Track 7, Layer B - 9th CC line is recorded into Track 7, Layer C - 10th CC line is recorded into Track 7, Layer D - 11th CC line is recorded into Track 6, Layer B - 12th CC line is recorded into Track 6, Layer C - 13th CC line is recorded into Track 6, Layer D - 14th CC line is recorded into Track 5, Layer B - 15th CC line is recorded into Track 5, Layer C - 16th CC line is recorded into Track 5, Layer D - 17th CC line is recorded into Track 4, Layer B - 18th CC line is recorded into Track 4, Layer C - 19th CC line is recorded into Track 4, Layer D Same for Track 12..16 for Seq2 Advantage: if only a few CC lines are recorded, we've dedicated tracks for PitchBend and CCs (Track 4-8, Layer A) which can be individually muted and cleared. Additional CCs populate the remaining layers from Track 8 backwards, so that PitchBend remains an individual track if not more than 17 CC lines are recorded. The new pre-release is available at: http://www.ucapps.de/mios32/midibox_seq_v4l_082_pre3.zip /Update: v4l_082_pre3 provides a better Seq1/2 selection handling whenever a track is cleared Best Regards, Thorsten.

no, but I take this as a reminder... Best Regards, Thorsten.

Da muessen aber noch viel mehr Probleme geloest werden, nicht nur ein lokales Stop/Play... ;-) Hast Du Dir schonmal dieses Projekt angesehen? -> http://midisizer.com/midirex/ Gruss, Thorsten.

Hi Jazza, It's sad to read that a MIDIbox builder died! Do you know his forum name? It seems that there is a problem with your MIDI interface, because SysEx messages are corrupted. Is it already listed here? -> http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist Do you own an alternative MIDI interface? Best Regards, Thorsten.

Well, if you see the AINSER menu item, you can already use the AINSER8 module. Disadvantage: one pot movement will generate 8 MIDI events instead of only 1 (because the analog input is not multiplexed). The 7 redundant MIDI events can be disabled by clearing all MIDI port flags (USB1..4, OUT1..4, OSC1..4) However, if you are saying, that no MIDI events are generated at all, there is either a connection or a software configuration problem. It's very difficult to support you on such an issue remotely if you are not able to use MIOS Studio; and I can't help you on Linux issues! If you would be able to use MIOS Studio, you could just follow the testing procedure under: http://www.ucapps.de/mbhp_ainser8.html Your observations with the ainser_jitter_mon application would make it much easier to give additional debugging hints... Best Regards, Thorsten.

Hi Florian, somehow I already feared that this can lead to confusion: the GP button assignments are similar to the MUTE page: button #1..#8 control Seq1, and button #9..16 control Seq2 independent from the selected sequence. Advantage: direct control over both sequences without switching Disadvantage: unusual/inconsistent UI handling It's probably better if I decouple the UI from the actual track & layer assignments (which are inherited from the "big brother" V4): - button assignments in CLEAR and MUTE page shall reflect the sequence selection, starting from button #1 - button assignments shall differ between Pitchbend and CC layers in track #4..7, which means that: o Button #1 clears/mutes note triggers o Button #2 resets velocity (mutes have same function like Button #1: no notes are played) o Button #3 resets note length (mutes have same function like Button #1: no notes are played) o Button #4 clears/mutes the Pitchbend line o Button #5 clears/mutes the first recorded CC line o Button #6 clears/mutes the second recorded CC line o ... o Button #15 clears/mutes the 11th recorded CC line o Button #16 mutes the remaining CC lines in MUTE page, resp. it initializes the whole sequence & configuration in CLEAR page Do you agree, and/or do you have additional ideas? Best Regards, Thorsten.

This is the default configuration: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Ftools%2Fmk_syx%2Fmidibox64.ini And with the default LED_MAP the LEDs should reflect the state of the buttons. Best Regards, Thorsten.