TK.

An older version won't help Doublepost! Discussion continues here: http://www.midibox.org/forum/index.php/topic,13576.msg116764.html#new Best Regards, Thorsten.

This cannot be related to the firmware version (it already has been tested by some people), therefore uploading an older release won't help anyhow. How did you upload the application? Did you use a different MIDI Interface this time? Did MIOS Studio report any errors during code upload? Which upload mode are you using? (hopefully "Smart mode") How did you test that the encoder is working? If there wasn't an issue during code upload, it could help to use MIDIO128 for troubleshooting the encoders and buttons. It would also be interesting to know some more details about your MBSEQ construction. E.g., flickering LEDs or non-functional buttons/encoders are a common problem if cables to the DIN/DOUT registers are too long. Also a short between SCLK and RCLK can cause this, etc... (more once you explained the details) Best Regards, Thorsten.

Ploytec released an update for 32bit and 64bit Windows: http://www.ucapps.de/mbhp_usb_gm5.html Best Regards, Thorsten.

It works! (Ilmenator tried this some months ago) Best Regards, Thorsten.

Hi, I guess that you mean the MIDIbox SEQ V3 setup files. setup_mbseq_v3 will work fine for you, the remaining files are customisations for myself, Wilba, CD and (new, will be part of the next release package) MK. They are using different LED/Button assignments, and as a personal service from my side I provide precompiled binaries for them so that they don't need to build a new .hex file by themself on new releases. If you really want to find out the differences (I don't see a need), you could run a "diff" between two .asm files, or just compare the settings line by line. Best Regards, Thorsten.

Hallo, die Fader sollten im Ruhezustand auf keinen Fall blockieren, und auch keinen Strom ziehen. Vielleicht ist etwas mit der Verbindung zwischen Core und MF Modul nicht in Ordnung, so dass die 74HC595 nicht sauber angesteuert werden. Hast Du schonmal die mf_direct_control Applikation ausprobiert? Damit lassen sich die Pins zu den H-Bruecken direkt ansteuern. Gruss, Thorsten.

The lcd_interconnection test is a very helpful application to test all connections to the LCD (details are explained in the README.txt) Best Regards, Thorsten.

Could you please try "TEST INOUT1" (loopback through core) with MIOS Studio. First send some notes - the MIDI Output monitor as well as Input monitor should display the same event. Thereafter push the "Start" button of the upload window - both monitors should show the same SysEx string. Best Regards, Thorsten.

There are two shift register (SR) chains, one for "DIN SRs" (each MBHP_DINX4 module is stuffed with 4 SRs), and one for the "DOUT SRs" (each MBHP_DOUTX4 module is stuffed with 4 SRs). Sometimes they are also called SRIO chains (Shift Register Input/Output chains) SRs are counted from 1, the first SR is the register which is directly connected to the core. Hope this helps. Here a table which could help even more to determine the SR and pin number: http://www.midibox.org/dokuwiki/doku.php?id=home:mbhp:module:din_dout_pin_list Best Regards, Thorsten.

This feature was a special request by Wilba, I could make it optional if desired. In order to decide about the default behaviour, I would like to know, how many other users like/dislike this function (all triggers inverted when ALL button pressed) - opinions? Best Regards, Thorsten.

An UI link between two cores would produce an immense effort at my side, and I wouldn't use such an option by myself, therefore: no Wouldn't it be better to provide "local trigger/parameter layer mutes"? Each track can already play 16 drum instruments, means: the sequencer can already handle up to 256 "drum tracks" in parallel. The only feature you need is to mute these individual drums, correct? This would cost 32 bytes RAM - much less than all the code/RAM for a core link. Best Regards, Thorsten.

Because this is illegal - this isn't a hacker forum, thread closed. Best Regards, Thorsten.

Open the setup_mbseq_v3.asm file, and change following lines: LED_GROUP1 EQU (((11 -1)<<3)+ 0) ; OPTIONAL! see CHANGELOG.txt LED_GROUP2 EQU (((11 -1)<<3)+ 2) ; assigned to pin 2 due to DUO LED LED_GROUP3 EQU (((11 -1)<<3)+ 4) ; assigned to pin 4 due to DUO LED LED_GROUP4 EQU (((11 -1)<<3)+ 6) ; assigned to pin 6 due to DUO LED [/code] to: [code] LED_GROUP1 EQU (((11 -1)<<3)+ 0) ; OPTIONAL! see CHANGELOG.txt LED_GROUP2 EQU (((11 -1)<<3)+ 1) ; assigned to pin 1 for nuke's HW LED_GROUP3 EQU (((11 -1)<<3)+ 2) ; assigned to pin 2 for nuke's HW LED_GROUP4 EQU (((11 -1)<<3)+ 3) ; assigned to pin 3 for nuke's HW thereareafter build a new .hex file and upload it Best Regards, Thorstem.

Yes, MIDI IN should be superfast as well. :) Here some impressions from a similar test, this time MIDI events are sent over ethernet by using the OSC protocol. At the Mac side I'm using an OSC->MIDI proxy, so that Note On/Offs can be recorded with Logic Audio. First bar: 256 MIDI events via USB-MIDI for comparison (ca. 2 mS) Second bar: 256 MIDI events sent with 256 separate OSC datagrams (ca. 46 mS) Third bar: 256 MIDI events sent in 32 OSC bundels (ca. 11 mS) The STM32 was extremely busy while sending OSC messages. Timestamps are not used - they could help to trigger events synchronously, but they would also lead to a higher latency. The OSC Proxy was busy as well, it consumed ca. 10% CPU while processing the packages - bad if the same computer is used to play virtual instruments. This article gets a FAQMARKER, so that I can quickly find it if somebody should argue again, that OSC is faster than MIDI ;) Best Regards, Thorsten.

I will check this soon. Best Regards, Thorsten.

See the Troubleshooting Tips It sounds a bit like Issue 3c Best Regards, Thorsten.

I've his address from the last GM5 batch order, and via http://www.telefonbuch.de it's also possible to find out a mobile phone number of somebody who lives in the same street (could be his wife/mother/grandma/sister). If you are interested I can give you the details so that you are able to contact him directly. Best Regards, Thorsten.

Hardware changes: MBHP_CORE has to be be replaced by MBHP_CORE_STM32 LCD connectors to J15 have to be changed (they have an 1:1 pinning now, which is less complicated than the pinning of MBHP_CORE, and compatible with the Ultracore BankSticks not supported anymore (obsolete) instead a SD Card has to be used (which is cheaper than BankSticks anyhow). It will be possible to access the SD Card via USB as a mass storage device, so that no external card reader is required to exchange data with a PC/Mac. This means, that you could solder the cables directly on the SD Card pads to ommit the SD socket. on an existing MIDIbox, you have to modify the rear panel for the USB socket and the second MIDI In/Out Thats all. I already migrated my MBSEQ V3 in order to prove this (now I've two MBSEQ V4s :)) The STM32 based solution is less complicated than the PIC, therefore better for Newbies. E.g., no trouble with SysEx transfers via your MIDI interface, because STM32 provides an integrated USB interface. Once connected, you are able to upload code from MIOS Studio. There is an on-board LED which tells you that the chip is running. It even runs if no crystal is connected (in this case USB won't work though) Also debugging the core is easier thanks to the verbose debug terminal, which prints text messages (instead of cryptic MIDI events) when anything goes wrong. Etc... I just have added BUTTON_MORPH, BUTTON_MIXER and BUTTON_TRANSPOSE I will add such functions on request, because there is enough memory free to provide such options in a single binary (currently only ca. 30% of the flash memory is used), and programming them in C is so simple that no testing is required at my side before releasing such an extension. Everybody is still free to change the source code by himself of course like you did for V3. The hook is called "SEQ_UI_Button_Handler(u32 pin, u32 pin_value)" Best Regards, Thorsten.

No, CAN isn't really required for MBSEQ, it could be nice for MBSID V3, but this is far future, especially as it could take more than one year until STM releases the STM32F106x series for production! MBSEQ V4 will use the current MBHP_CORE_STM32 module, I don't see any reason why another chip should be used. The performance will be identical (both chips are clocked at 72 MHz) Best Regards, Thorsten.

Aufloesung: der NI Kore gehoert in die Blacklist! Gruss, Thorsten.

Only one word: tight! Thanks to USB!!! :) Following impressive example shows, how fast MIDI events can be sent via USB interface in comparison to UART based MIDI with and without running status optimisation: So, the thin red bar at the left side are 128 Note On and 128 Note Off events sent via the STM32 internal USB interface. The transfer of 256 MIDI events takes 1.9 mS The second bar in the middle shows 128 Note On and 128 Note Off events with running status optimisation (highest throughput by ommiting the status byte - works only if Note events are sent over the same MIDI channel) The transfer takes ca. 164 mS The third bar at the right side shows the common UART based MIDI timing without running status optimisation. The transfer takes ca. 245 mS This test shows, that the usage of an integrated USB peripheral is the perfect solution for controlling software synthesizers, especially drum synths or percussive sounds which should be played synchronously. :) Best Regards, Thorsten.

The firmware is currently in a state at which commercial companies would already release it as a v4.0 version. ;) Everybody who already owns a MBHP_CORE_STM32 module is able to use the firmware, it's located in the repository, usually I send precompiled binaries on request if somebody doesn't want to install the gcc toolchain on his computer. Sidenote: it isn't required anymore to recompile the firmware on HW customisation, as all hardware settings are done in a configuration file stored on SD card (see MBSEQ_HW.V4), which can be edited with a common text editor. I haven't released it for public yet, as SmashTV is still working in a solution to provide MBHP_CORE_STM32 modules with presoldered and tested STM32 for those guys who don't want to solder this SMD chip by themself, and/or don't own a JTAG programmer (or RS232 based programming device). For those who prefer pure DIY: MBHP_CORE_STM32 schematic and layout are stable since some months! (but Smash has improved the layout for production meanwhile) Best Regards, Thorsten.

1st level bootloader: der ist fuer ca. 2 sekunden nach Power-On aktiv. Du verwendest ihn so: Box ausschalten, in MIOS Studio den Start Button druecken, Box einschalten -> Upload sollte starten. Falls nicht, probiere es nochmal oder lass Dich von der Dokumentation inspirieren: http://www.ucapps.de/mios_bootstrap.html Wahrscheinlich hast Du irgendwann einmal einen Code Upload einfach abgebrochen. Dadurch wurde die Installation zerstoert, und kann mit dem normal Bootloader nicht mehr erneuert werden. Der 1st Level Bootloader ist dann die Rettung (naechste Antwort nicht vor heute Abend - falls etwas nicht funktioniert, Doku lesen, oder im Forum nach aehnlichen Faellen suchen!) Gruss, Thorsten.

Das ist ein problem mit der Spannungsversorgung - klemme mal die IIC Module und evtl. die DOUT Module ab (einfach ICs entfernen), und spiele die Firmware ueber den 1st Level Bootloader auf. Gruss, Thorsten.

Of course, local clock dividers are still available for each track and clocks can be divided by any number of ticks, not only the even ones (to avoid unnecessary requests of features which already exist since v3) I mean the global clock divider which was selectable in the v3 BPM menu, and which was called "Internal clock divider" since there was also an "External clock divider" for DIN sync. It could also be called "PPQN scale" E.g., it allowed you to slow down the tempo from 140 to 70 (1:2), 35 (1:4) or 17.5 (1:8 ) by pushing a single button. Now the tempo and ramp is completely configurable, there are 16 preset slots - therefore this clock divider (which was a simple but useful effect) is obsolete. Since you probably never discovered this nice feature before, you won't miss it! ;) Yes! Best Regards, Thorsten.