TK.

Ok, this seems to be a firmware bug (maybe a protocol violation), because from my experiences with various interfaces (and especially with the MBHP_CORE_STM32 module) the internal MacOS driver works pretty stable (IMHO the most robust implementation compared to Windows and Linux solutions I know) I added the interface to the blacklist. I hope that you've more luck with your NI Audio 8 Best Regards, Thorsten.

It doesn't work correctly anyhow! I will add this interface to the blacklist, as SysEx transfers are not working properly, see http://www.midibox.org/forum/index.php/topic,13658.msg117436.html Somehow I've the impression that many low-cost MIDI interfaces contain the same chip with the same buggy firmware. Good that MBHP_CORE_STM32 comes with an integrated USB interface ;) Best Regards, Thorsten.

In order to exclude a MIOS Studio or Java installation issue: could you please doublecheck the incoming MIDI Messages with an alternative MIDI Monitor like this one: http://www.snoize.com/MIDIMonitor/ You should receive 9 byte SysEx messages like shown in the attached snapshot. Best Regards, Thorsten.

Smash did some layout improvements to ensure perfect production results. I can give a "go" for "mass production" once I got the new prototype and tested it successfully. PCB + preassembled STM32F103RE + preprogrammed MIOS32 bootloader: ca. US $25! (unbeatable price :)) It makes sense to order the board+STM32 only to avoid customs. In Germany, the remaining parts can be purchased at Reichelt. Best Regards, Thorsten.

The contrast pot should always have an effect, especially if V0 outputs 0V. So long the LCD hasn't been initialised, you will see a black bar at one line, especially if V0 (contrast voltage) outputs 0V. You should already see this line if only Vs, Vd and V0 is connected (again: V0 should output 0V, turn the contrast pot accordingly) Be careful when trying different connections - the LCD can easily be destroyed if Vs/Vd is connected to the wrong pins. Best Regards, Thorsten.

Hi, which MIDI Interface are you using - is it listed here? Also the operating system could be for interest. Best Regards, Thorsten.

I will get 5 new boards with presoldered STM32 from Smash soon. Two are already reserved for friends, two are for myself, so I could give you the remaining one if nothing unexpected happens (e.g. a friend notices problems with his board) (obsolete, but progress at Smash's side is very good, so that boards can be purchased from him directly!) No "burner" required, a COM interface with TTL level IO (which could also be USB based) is the most simple solution, see also: http://www.ucapps.de/mios32_bootstrap_experts.html However, Smash already programs the MIOS32 bootloader into the STM32, so that the application can be uploaded via USB MIDI. Best Regards, Thorsten.

You are trying to compile an application from a release package, which only contains the files which were required for the release itself, and no variants. Solution: use the MIOS base package to get all files. Or better: since you are planning to integrate the application into the repository anyhow, download the repository, setup the environment variables (MIOS_PATH and MIOS_BIN_PATH), remove all directories of the release package which don't belong to the application itself, rename Makefile.org to Makefile and compile there. Best Regards, Thorsten.

I agree that it would be better to take the "reference step" as basis for the groove pattern, this only requires a small change in V3 and V4, so I will do this with the next V3 release. Especially for V4 this change will open new possibilities, e.g. in conjunction with the new progression parameters and customized groove templates (e.g. a groove only varies velocity, so that an additional CC track isn't required to generate effects like demonstrated in the MP3s) Note length: would it be ok if such a length entry is only available in the Length Layer, and not in other parameter layers? Such a feature can only be added to V4 of course! Best Regards, Thorsten.

I'm not able to reproduce this, but looked into the code and found some fancy calculations to determine which encoder modifies the begin and end position of the range. It could make sense to add an additional check for the rightmost encoder as a workaround for unexpected states. Due to a holiday trip I'm not able to test the modifications - so, if you are able to build a .hex file, open src/cs_m_utils.inc, search for CS_M_UTILS_GP_Callback_Copy ;; change copy offset and copy marker to begin/end range depending on encoder which has been moved movf MIOS_PARAMETER1, W bz CS_M_UTILS_GP_Callback_CopyB [/code] and replace it by: [code] CS_M_UTILS_GP_Callback_Copy ;; change copy offset and copy marker to begin/end range depending on encoder which has been moved movf MIOS_PARAMETER1, W bz CS_M_UTILS_GP_Callback_CopyB xorlw 15 ; check for rightmost encoder (counted from zero): always modifies end position bz CS_M_UTILS_GP_Callback_CopyE movf MIOS_PARAMETER1, W ; back to original value If you are not able to build a .hex file by yourself, please wait for ca. 1 week. Best Regards, Thorsten.

Does this mean that you got a package from him meanwhile? What was the content (I see some additional PCBs on the sofa in background). According to his description you should get "2x 6562; 3x C1583 97G; 1x K30A-Y; 1x K30A-O; 1x C2291 82G; 1x BA6110" which are probably very expensive. Best Regards, Thorsten.

Works fine at my side (end of range can be changed with rightmost encoder if track length is 32) - so what is different at your side? Best Regards, Thorsten.

No, such a function isn't available since it would require the usage of a CC - providing a pattern switching functionality via CC is dangerous for the case that somebody connects another sequencer, or a MIDI controller/keyboard to the MIDI IN without knowning about the risks of data loss if a bank change CC (e.g. CC#0) is received. Therefore switching the pattern (not the bank) via CC instead of program change is only optional and disabled by default. I could add an option for bank switches as well, but I guess that sooner or later (e.g. once the first "accident" happened which destroyed the unsaved edit buffer), you will disable it again because of pure frustration. Personally I would never enable such a function by myself... therefore implementing a feature which nobody will use over long term anyhow is really low priority on my TODO list. Best Regards, Thorsten.

And here is the contemporary work (insider joke) ;) Following simple 4-step sequence is played: The tone colour is varied with a 16-step CC track: It sounds like this: mbseqv4_demo_progitv_len4n.mp3 Repetitive and boring. Ok, now we have some new magic "experimental progression parameters" in the Track Direction page, right side: Itv. (Interval): defines an interval of x steps after which: Repeat: the step will be repeated n times Skip: and/or m steps will be skipped In following example each 4 steps one step is skipped: mbseqv4_demo_progitv_len4s.mp3 And here each 4 steps the step will be played twice (repeat=1): mbseqv4_demo_progitv_len4r.mp3 Now let's try it with 16 notes: Again the result: repetitive and boring: mbseqv4_demo_progitv_len16n.mp3 Let's try Interval=4 and Skip=1: mbseqv4_demo_progitv_len16s.mp3 Or Interval=4 and Repeat=1: mbseqv4_demo_progitv_len16r.mp3 Or Interval=5 (uneven) and Repeat=3 (uneven as well): mbseqv4_demo_progitv_len16x.mp3 Fun! :) Selectable Interval: 1..64 steps Selectable Repeats: 0..16 steps Selectable Skips: 0..16 steps All parameters can be controlled from a loopback track for automated variations while the sequencer is playing. But tweaking the values manually and using a static setting already results into very interesting results. Best Regards, Thorsten.

fixed in RC31 Best Regards, Thorsten.

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.