TK.

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.

Hi Mike, interesting! You and me seem to be the only guys who are using this feature (it's one of my most favourite ones). According to the svn log, it wasn't working since 298 days, 21 hours, 10 minutes (it was working in v4 of course ;)) Fixed in v3.4e Best Regards, Thorsten.

Ok, I will add CC ramps to the song sequencer as well. CC ramps and LFO effects are planned as "global effects" as well, so I think that this should be combined (change the global configuration from a song) I also think that it makes sense to increase the number of song steps from 128 to 256 to get enough place for the new features. I restructured the BPM configuration page so that it can be used more intuitively: The "internal clock divider" has been removed, as the possibility to select a tempo preset has the same effect. The "external clock divider" has been replaced by the possibility to enter the PPQN rate at which the DIN Sync clock pin should be triggered (1..384 PPQN) The "External Restart" (which can be selected with MENU+METRONOME in V3) can now be triggered from the BPM page, so that no double assignment of the METRONOME button is required. The function can be optionally assigned to a dedicated button of course. It can also replace the METRONOME button function. Also new: the MIDI Clock Input/Output port setup can be done in the BPM page instead of the MIDI page. Best Regards, Thorsten.

There is an update (v3_4d): o In Slave Mode the sequencer won't switch to Master mode when the Play button is pushed. This automatic switching is only available in Auto Mode anymore[/code] Best Regards, Thorsten.

Hi, 48ppqn means that the clock has to be sent with double frequency. With some changes in the code it should be possible to realize this (the timer rate has to be doubled, the MIDI Out clocks need a predivider) - but it's nothing what I could write down w/o testing. I guess that it needs some tweaking until it will run perfectly! Unfortunately I don't own a LM-2 ;) Best Regards, Thorsten.

From your descriptions I assume that either the MIDI Out or windows driver of your MIDI Interface, or the MIDI In of the core module isn't working, because MIOS Studio tries to contact the core but doesn't get a response. The MIDI Out of the core module, and the MIDI In of your MIDI interface seem to be ok. Please do following tests of the MIDI Troubleshooting guide, and write down the results: TEST IN1: TEST IN2: TEST IN3: TEST IN4: TEST IN5: TEST IN6: TEST IN7: TEST INOUT1: Best Regards, Thorsten.

I used a MIDIsport 2x2 many years w/o issues. But the driver is multi client capable. If M-Audio Uno doesn't support multiple clients, this indicates that a different driver is used which could have bugs. Best Rgards, Thorsten.

Yes! Programs like Ableton Live allow to compensate Audio into the negative or positive direction in relation to the incoming MIDI clock to overcome such issues. Best Regards, Thorsten.

You have to differ between how much current can a 74HC595 source/sink w/o the risk for damage, and how much current can a single 74HC595 output source/sink w/o influencing the current through other outputs (resp. w/o violating the logic-level specs, but this isn't for interest here anyhow). On my original 4x16 Duo-LED Matrix design, there is a noticable influence once more than 8 LEDs are sinked through a single 74HC595 at the same time. Therefore I recommented sink drivers. Comment to answer from ST: they are right - if you are searching for a perfect solution, use a chip which has been created for driving LEDs. Comment to answer from Fairchild: they are right - they are speaking about a current limit through a single pin, they don't mention the influence between outputs, but you haven't asked for this... Comment to answer from ON: they are right, but Voh/Vol isn't for interest while driving LEDs (in other words: miss-using a logic chip) Best Regards, Thorsten.

True words! ;) Currently I would say, that connecting a MBHP_CORE_STM32 module to a MB-6582 via CAN will give us the most powerful options, since PICs can be used to access the SIDs while STM32 is doing the sound engine, communication and user interface work. If more than two SIDs would be connected to a single STM32 w/o the usage of additional microcontrollers, the firmware would mainly be busy to transfer data to the SIDs and wouldn't have so much time to calculate modulation sources and pathes - the problem: write accesses to SIDs have to be synchronized to the 1 MHz clock, this costs 2..3 SID cycles. While for a PIC this means the loss of 20..30 instructions, for a STM32 this means a loss of ca. 200 instructions per write access! Another advantage of using PICs: STM32 could send some "background jobs" to the PICs which are handled in parallel. E.g., FM modulation or playing samples. They could be handled with incredible high speed (e.g. 20 kHz - note: a C64 usually accessed the SID with 50 Hz) without loading the "master processor". There are two options I'm planning to evaluate in the next months before starting to program the firmware. 1) (over)clocking the SIDs with 2, 4 or 8 MHz! This would result into faster transfers. Disadvantage: lower frequencies cannot be played accurately anymore, and VCA envelopes are faster (*). Advantages: this could allow to handle 8 SIDs from a single STM32 w/o such a high performance loss. This could also allow to apply the ADSR workaround much faster, which means, that such an option could lead to the world-first "real SID" synthesizer with perfectly working ADSRs ;) Note that this option would work with PICs as well, which means that re-using the PICs from an existing MB-6582 is again the most powerful solution, everything else is only a cost-saving measure. /edit: (*) can also be seen as an advantage! 2) STM32 introduced a new connectivity line with derivatives which contain USB, two (!) CANs and an ethernet controller (unfortunately w/o PHY layer) beside of other useful peripherals. Two CANs means even higher bandwidth, USB can be used in parallel, and integrated ethernet controller is the cherry at the top (MIOS32_OSC is already up&running, in addition it would be possible to download new patches directly from the internet ;)) These chips are not available yet, but it will be possible to prepare the firmware for such an upgrade option, which could be used for the final design. Best Regards, Thorsten.

Problem: the SONG button already has a second function, it switches between Song and Phrase mode. Another problem: if somebody presses SONG and MUTE (or SONG and PATTERN) unintentionally together, the current song position would be overwritten. I think, that it would be better to have a "store current" function assigned to a GP button, so that no (hidden) button combination is required. So: select a pattern action, press "store current" and the current pattern set will be copied into the song step Or select a mute action, press "store current" and the current mutes will be copied into the song step. Same for mixer map and tempo, and maybe for future actions as well. Mutes cannot be stored together with pattern sets in a single step, since actions share the same memory locations (8 bytes of a song step can either store pattern/bank changes, or a jump, or a song change, or a mixer map, or a tempo change or a mute pattern and maybe more in future). In addition, it wouldn't be so easy to display a complete song step (pattern set and the mute pattern) on a single LCD anymore. I would have to remove the info screen of the second LCD... So - storing a Mute pattern in a separate song step has many advantages, and I won't search for a different solution. Best Regards, Thorsten.

Yes - note that tempo changes with ramp value "0 s" will be done immediately. So, you can store your prefered tempos there. And you can add "tempo sweeps" if desired. When you listen to the demo, you will notice that I did pattern changes during tempo sweeps. They are handled in background. It's even possible to interrupt an ongoing sweep by a new preset, which gives you the possibility to play a bit with different up/down ramps (some kind of "scratching" ;)) The advantage of my solution is, that prefered tempo changes can be prepared - thats really important for live sessions (no need to search for the right tempo with the encoder) If you prefer a single-button solution for a tempo change/sweep *together with* a pattern change, the song phrase enhancement will be the solution. Best Regards, Thorsten.

They could (these are floats), but you wouldn't really notice an effect - such ramps sound more like a sequencer hick-up. Currently it enters the preset screen for the case that it isn't assigned to a Fx button. Currently you just only need to press different preset buttons to achieve similar effects. I think that they are more useful than your proposal - you will see this once playing with the function. Best Regards, Thorsten.

So, you mean something like this: Selectable in such a page: Which sounds like this: http://www.ucapps.de/mp3/midibox_seq/mbseqv4_demo_tempo_sweeps.mp3 Good that I considered automated tempo changes from the beginning while implementing the MIDI event scheduler :) Note that tempo changes with a definable ramp time could be part of a song phrase as well (definable in song page, similar to Pattern Sets, Mutes, Mixer Maps, etc...) Best Regards, Thorsten.

Link to the new thread http://www.midibox.org/forum/index.php/topic,13485.0.html

It cannot be changed, as sm_fast scans the keyboard "so fast as possible" in an endless loop. If you prefer a defined scan period, use sm_slow. On the other hand - why do you want to change the speed? No, the timer is only used to decrement the debounce counters. sm_slow uses the common MIOS hooks to scan a matrix and can be used in parallel to other routines w/o drawbacks. E.g., I'm using the same approach for MBSEQ, MBSID, MBFM - and these are really CPU intensive applications. sm_fast is a hack which controls the SRIO chain directly so fast as possible. This should be done exclusively. No other routines should run in parallel. Best Regards, Thorsten.