TK.

RC31 is available: o fixed storing ensemble in internal EEPROM if no BankStick selected o the ensemble stored in internal EEPROM (previously called E001) is now called EInt o the patch stored in internal EEPROM (previously called [A-H]001) is now called PInt o EInt now automatically selected after startup if no ensemble BankStick connected o E002 now automatically selected after startup if EInt was selected before o fix for communication with Rutger's SysEx editor: mod matrix direct assignments are handled correctly now in stereo edit mode [/code] Best Regards, Thorsten.

This topic has been moved to MIDIbox SID. [iurl]http://www.midibox.org/forum/index.php?topic=13616.0[/iurl]

Of course, this isn't a bug ;) How should MBSEQ come back in sync so long Live doesn't send a MIDI Clock Start event? Best Regards, Thorsten.

It's now possible to mute layers of the selected track by pressing&holding the MUTE button. This gives you also a nice overview about the instruments which are played by the track: In the normal mute page, tracks are marked with a small "m" if individual layers are muted to improve the oversight (partially muted tracks can be confusing if you don't remember the disabled layers...) Note that a common track (non-drums) can be muted as well. This allows you to (for example) to mute CC lines, or to disable effects like Roll or Probability: Best Regards, Thorsten.

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=13606.0[/iurl]

Great work! :) Best Regards, Thorsten.

Is this only an issue with your 707? Are there any specs for the DIN sync input of this drum sequencer (e.g. required pulse length)? Btw.: does the same happen if you are using a J5 gate out triggered by a Note Event to clock the 707? The difference: a much longer pulse length. Best Regards, Thorsten.

via forum mail to user "benuron" Best Regards, Thorsten.

I guess that you've uploaded the wrong .hex file. Please try setup_mbseq_v3.hex first, just upload the file again if you are unsure! Report the results! If it won't work I will search for an older release package on my harddisk, but I'm very sure that it won't help! Best Regards, Thorsten.

And you uploaded setup_mbseq_v3.hex, and not any other .hex file which could have a different button/LED assignment? Best Regards, Thorsten.

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.