TK.

Thank you! Best Regards, Thorsten.

Different notes/CCs are stored in bank 1/2 and bank 3/4, but if your question was, if currently only the same combination of Seq1/2 patterns can be stored/restored, then my answer is yes. But as already mentioned: if somebody prefers to store/restore Seq1/2 independent from each other, it's not a big deal to add an option for such a usecase. :) Best Regards, Thorsten.

Hallo Joerg, fuer die Integration in Traktor ist nicht viel "Eigenintelligenz" notwendig, da die Software ja eine eigene Lernfunktion hat. D.h.: solange die MIDIbox fuer jedes Poti und fuer jeden Taster ein eigenes Event sendet, kannst Du alles vom PC aus zuweisen! :) Gruss, Thorsten.

Internally 4 different patterns are running (stored in 4 different bank files), but the MBSEQV4L user interface combines these 4 patterns to a single pattern (at least you won't notice the split). Means: pattern changes always happen for both sequences to the same pattern number. If somebody prefers to switch pattern independent from each other (e.g. Seq1 plays 1:A1/2:A1 while Seq2 plays 3:A2/4:A2), I could add an option (e.g. configurable in MBSEQ_C.V4) to handle pattern switching based on the Seq1/2 button status (note that both sequence buttons can be selected at once). I find the current handling more intuitive since you don't need to take care to select both Seq buttons before changing two patterns synchronously. If a certain theme (e.g. played by Seq2) should be re-used in multiple patterns, just copy&paste it. However, as long as options are easy to implement, I can add them of course... this one would make the sequences totally independent from each other, but the usage would be more cumbersome (bad for live situations) MIDI channels (and ports) are part of the pattern. The sequencer engine takes care that events (especially note off events) will be sent to the intended MIDI channel/port even after pattern changes and if the MIDI echo effect is active, regardless of the number of delayed notes. -> absolutely no risk for hanging notes - I'm proud about this fact! ;-) These details simplify to answer your questions: In reality (current default UI handling) pattern 1:A1, 2:A1, 3:A1, 4:A1 are playing, you could only switch to 1:A2, 2:A2, 3:A2, 4:A2 But 1:A1 and 2:A1 can be assigned to a different MIDI channel and port than 3:A1 and 4:A1 1:A2 and 2:A2 can be assigned to a different channel/port as well as 3:A2 and 4:A2 yes, this is possible. Best Regards, Thorsten.

Again some good news: Due to the high demand I decided to hand over the bulk order to Tim aka. SmashTV! This has some advantages: I give it into the hands of a professional (he already improved the Gerber Files! :) ) you can order the MBHP_CORE_LPC17 and MBSEQV4L FrontPanel PCB from a single source you will be able to order the PCBs from the Low Value Order Page Shipping costs to Europe (e.g. Germany): ca. 5 EUR PCBs will be available by end of november Long-Term availability of both PCBs! All people who have already added their name to the bulk order list will be informed via PM once the PCBs are available. Therefore it still makes sense to enter your name if you are interested. Best Regards, Thorsten.

Excellent!!! :) I added this document to the user manual Best Regards, Thorsten.

approved Best Regards, Thorsten.

Hallo Joerg, man (im Notfall ich) koennte die Poti-Unterstuetzung schon einbauen, doch sie waere dann erstmal nicht konfigurierbar. Das habe ich mit der MBNG geplant (die quasi eine erweiterte MIDIO128 sein wird), doch daran setze ich mich erst um Weihnachten. Welche MIDI Events sollen denn gesendet werden? Gruss, Thorsten.

Due to the high quantity the PCBs will be available for 11 EUR p.p.! :) Best Regards, Thorsten.

It's definitely cool stuff, but it seems that it needs more time until the DIY folks realizes the possibilities. ;) MIDI OUT ports don't add latency Each HW based MIDI IN port adds a latency of ca. +1 uS (the MBHP_CORE_LPC17 module has 4 UART inputs) Each IIC based MIDI IN port adds ca. +10 uS latency if the receive interrupt signal can be directly connected to the core module. Each IIC based MIDI IN port adds ca. +50 uS latency if the receive status has to be polled. Not really required, Ethernet<->WiFi routers are available for ca. 10 EUR today, there is no need to develop an own solution which would load the core with additional protocol overhead. Best Regards, Thorsten.

Thanks for the input! I remember that I wanted to improve the phrase mode anyhow! :) Best Regards, Thorsten.

approved Best Regards, Thorsten.

Some detailed informations about the supported packet formats are described here: http://www.ucapps.de/midio128.html Search for "Supported OSC Packet Formats" They are implemented into a driver module which can be optionally inherited by any MIOS32 application. I will add more protocols on request. Regardless which format is selected, multiple MIOS32 based cores can always communicate together via ethernet since they are using exactly the same drivers... ;-) For MacOS I implemented a proxy application which transforms ,m Packets to MIDI events - it even supports SysEx :) But usually you would select a protocol which can be handled by the remote application. E.g. Reaktor works fine with the "Text Msg Float" format, there is a special protocol for Pianist Pro and TouchOSC (iOS apps) In this video at 4:25 you can see, how I'm sending OSC packets from an iPad application to MBSEQ, and MBSEQ converts them to (USB-)MIDI events which are sent to a virtual synth in Logic Audio (unfortunately Logic doesn't support OSC natively) http://www.youtube.com/user/ucapps?feature=mhee#p/a/u/0/6gRD_GLHbJM It's a nice demonstration of just another possibility: sending OSC packets via WiFi and transform them with a MIOS32 core to anything else (no need for a PC) Best Regards, Thorsten.

Ooof! Thanks for pointing this out and sorry for this time consuming debugging session! :-/ To be honest: I remember that we had a similar issue on Christian's board and just removed the header between MBHP_CORE_LPC17 and J4 of LPCXPRESSO (the debug port), so that it has no contact. I'm unsure how I have to document this properly so that nobody else is blocked by the same issue. Some pictures might help? Best Regards, Thorsten.

It doesn't contain a USB-MIDI example - so, no "low hanging fruit" ;) Best Regards, Thorsten.

You can use J19 for DOUTs of course - just access it directly with MIOS32_SPI functions like I did in the aout.c driver: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Faout%2Faout.c Initialisation: #ifdef MIOS32_BOARD_MBHP_CORE_STM32 // MBHP_CORE_STM32: pins in open drain mode (to pull-up the outputs to 5V) status |= MIOS32_SPI_IO_Init(AOUT_SPI, MIOS32_SPI_PIN_DRIVER_STRONG_OD); #else // MBHP_CORE_LPC17 (and others): pins in push-poll mode (3.3V output voltage) status |= MIOS32_SPI_IO_Init(AOUT_SPI, MIOS32_SPI_PIN_DRIVER_STRONG); #endif // init SPI port for fast frequency access status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK0_PHASE1, MIOS32_SPI_PRESCALER_4); [/code] Transfer of a single byte: [code] u8 my_byte 0x42; MIOS32_SPI_TransferByte(AOUT_SPI, my_byte); // toggle RCLK pin MIOS32_SPI_RC_PinSet(AOUT_SPI, AOUT_SPI_RC_PIN, 1); // spi, rc_pin, pin_value MIOS32_SPI_RC_PinSet(AOUT_SPI, AOUT_SPI_RC_PIN, 0); // spi, rc_pin, pin_value For multiple bytes just call MIOS32_SPI_TransferByte multiple times and capture the value by toggling the RCLK pin AOUT_SPI is set to: // Which SPI peripheral should be used // allowed values: 0 (J16), 1 (J8/9) and 2 (J19) #ifndef AOUT_SPI #define AOUT_SPI 2 #endif [/code] please use a different name Best Regards, Thorsten.

Do you have a link to an open source project which uses the USB host function for USB-MIDI? Best Regards, Thorsten.

The AOUT driver behaves like expected, because it only supports 12/4 and 8/8 bit mode as described here: //! <LI>2 (AOUT_IF_74HC595):<BR> //! CV: up to 32 cascaded 74HC595 (each MBHP_AOUT_LC module provides 2 74HC595)<BR> //! Resolution is selectable with interface_option, each 74HC595 has an own bit //! which define: //! <UL> //! <LI>0: 12/4 bit configuration //! <LI>1: 8/8 bit configuration //! </UL> //! Examples: //! <UL> //! <LI>0x00000000: all AOUT_LC modules used for 12/4 bit configuration //! <LI>0xffffffff: all AOUT_LC modules used for 8/8 bit configuration //! <LI>0x00000003: first AOUT_LC used for 8/8 bit configuration, all others for 12/4 //! <LI>0x0000000c: second AOUT_LC used for 8/8 bit configuration, all others for 12/4 //! </UL> //! Digital: none</LI> [/code] What are you planning to do exactly? Wouldn't it be easier to output the values with DOUT modules connected to J8/J9? Best Regards, Thorsten.

Hallo Bernhard, Portamento wird erst mit der MBCV V2 unterstuetzt. Und zwar traditionelles Portamento, Constant Time Glide und Glissando. Neben weiteren Features wie LFOs (bis in den hoehrbaren Bereich), ENV (linear und exponentiell), Modulationspfade (bspw. auch ENV->LFO1->LFO2), Arpeggiator, etc... Das alles mal 8! :) Um auf MBCV V2 umzusteigen benoetigst Du ein MBHP_CORE_LPC17 Modul. Fuer die Firmware (die schon ziemlich gut funktioniert) suche ich noch Betatester. Gruss, Thorsten.

Alright, V4.054 is available now: MIDIboxSEQ V4.054 ~~~~~~~~~~~~~~~~~ o in edit page the datawheel can now be used for different purposes: it can scroll the cursor, the step view, can change the value (as before) and it can be used to select the parameter/trigger layer. The function can be selected by pressing SELECT + GP7/8 o Rômulo aka. Midilab started to implement a footswitch function which is especially useful for live recording and track modifications while playing on a keyboard. Press&Hold the footswitch to enable record mode, release it to disable record mode. Tap the footswitch shortly to delete the track. The footswitch can be assigned to a free DIN pin in MBSEQ_HW.V4 o note and chords can now be edited without immediate change by pressing&holding the EDIT button. The new value will be taken over once another step is edited, or the EDIT button is released. o fixed potential buffer overrun when preset is stored [/code] Best Regards, Thorsten.

I'm glad to hear this, because while implementing the mode I noticed a big problem: the display routines take values based on complete events provided by the sequencer engine instead of directly accessing the parameter layers. This has the big advantage, that there is a lower risk of incorrectly displayed values if I'm doing a programming error in all those if/else/if/else branches (spaghetti code...) So, I will limit the feature to notes/chords and change the code accordingly to avoid any "it mostly works, but under this special condition it doesn't..." bug report. I can only say: I know that it will never work perfectly! Best Regards, Thorsten.

Welcome to the forum! :) Have a look into the "Chaos Matrix" project, it's the best example how to build a customized "synth programmer", especially since it sends SysEx streams as well: http://www.midibox.org/dokuwiki/doku.php?id=chaos_matrix Best Regards, Thorsten.

As long as only a single value should be handled this way, I could add this to the firmware without much effort. But once you want to change multiple values (also triggers) and take over them by releasing the EDIT button, the effort would be too high. Your choice? ;) Best Regards, Thorsten.

Hi, ok from my side! :) Best Regards, Thorsten.

For 8 DINX4 modules you would have to enter following definition to the mios32_config.h file of the application: // scan 8 DINX4 modules #define MIOS32_SRIO_NUM_SR 32 [/code] thats all... Hardwarewise it could work without additional hardware if the cables between DINX4 modules is as short as possible. It's also very important that they are connected in a long chain! Don't use starlike wiring, this could result into uncontrollable impedance issues. If SCLK/RCLK should get unstable, the chain has to be terminated with a 100 Ohm/ 100 pF RC (see this schematic as example: http://www.ucapps.de/midibox_seq/mbseq_v4_din.pdf) Best Regards, Thorsten.