TK.

Probably you missed this page: http://www.ucapps.de/midibox_808.html Best Regards, Thorsten.

Here a first impression of the virtual MIDIbox SEQ V4 for the iPad. As you can see, there is some space for additional buttons or display functions. :) Due to the delayed delivery in Europe I won't be able to test and finish the emulation before june... Currently I cannot estimate if the timings will be so stable like on a real MBSEQ, however together with the upcoming OSC option we will get at least a nice remote control :) Best Regards, Thorsten.

Did you press ALT+Pattern button before power-off to store the current pattern? Best Regards, Thorsten.

The feedback issue should be fixed in RC37 now: RC37: o SW based feedback loops won't lead to endless repeated replies [/code] jvdieks: could you please check this with Cubase? Known issues: - if the feedback loop already exists while the MIDIbox is turned on, the 1st level bootloader could hang up - I don't like this, but a solution to overcome this is difficult (updating the bootloader is dangerous for people who don't own a PIC programmer) Workaround: turn on the MIDIbox before starting Cubase, or remove one of the MIDI cables until the application has been booted. - an application cannot be uploaded so long the feedback loop exists (MIOS Studio 2 will detect this) Best Regards, Thorsten.

Short answer: there must be an option in Cubase to avoid this feedback loop. Long answer: MBSID sends a reply on SysEx message to improve the robustness of MIDI transfers (e.g. a tool can verify if the sent message has been received and if the checksum is correct). The Java based editor relies on this feature. I admit that this is somehow overengineered, you won´t find this kind of communication on many synths. In MBSEQ I already implemented a filter for feedbacked messages, maybe I could add this to MBSID as well w/o affecting the communication w/ existing tools, but I´ve to try this out first. But: the way how patches and the edit buffer are requested and sent is very common for most synthesizers. The dump which is sent by MBSID can be directly sent back from a PC/Mac without changing the SysEx data. If Cubase always sends back the received stream, you will notice a dramatic performance issue (a synth gets stucked whenever an editor (or similar tool) requests a patch) - therefore I´m sure that Cubase provides a filter mechanism - somewhere... Best Regards, Thorsten.

2) is the most efficient solution as it only allocates local stack (in zero time) - but take care that stack memory is limited (1024 bytes), don't declare huge arrays there 1) is expensive since it allocates RAM statically, and it's bad programming style - you want to avoid the usage of global variables whenever possible. Best Regards, Thorsten.

I would have to spend some time to reach the state that you and some other people requested: 1 day: adding option for 16 instead of 8 faders (probably requires to open a second USB MIDI port and to make the SysEx handler multi port capable - I cannot give you exact instructions what exactly has to be edited, but many changes at different places have to be expected) 1 day: adding configuration possibility w/o the need to recompile the firmware, e.g. config options stored in a .txt file on a SD Card 2 days: providing the possibility to store the configuration in internal flash instead of SD Card + appr. SysEx transfer tool. Note that this option will be required for your usecase, as a SD Card has to be connected to J16, but this port is already allocated for fader #13..16 1 day: support for 2 CLCDs instead of a 240x64 GLCD 1 day: support for even more CLCDs instead of GLCD 2 days: find perfect solution for touchsensors 1 day: testing under MacOS and Windows before release to avoid time consuming troubleshooting sessions at your side 2 day: writing documentation to avoid confusion at your side I don't think that I can spend such efforts before July/August, since there are so many other interesting projects in the queue. :) If you are happy with the current state of the MBLC application, you could use it as it is - it works fine at my side :) But this would require that you recompile the firmware by yourself anyhow, accordingly a release is not required. Just download the current code from the SVN server and install the MIOS32 toolchain. Best Regards, Thorsten.

Yes, except for the connection name - you probably mixed it again. The three control lines are located at MBHP_AIN::J6:A/B/C, they have to be connected to J19 in your special case (96 pot inputs) The analog and supply lines are located at MBHP_AIN::J5, they have to be connected to MBHP_CORE_STM32::J5A/J5B/J5C Best Regards Thorsten.

No, you were speaking of the MBHP_AIN module, therefore I referenced the three multiplexer control inputs at J6:A/B/C The configuration has to be done in mios32_config.h as explained in the 012_ain_muxed tutorial example. This would be a working configuration for up to 96 pots (control lines are connected to J19 instead of J5C, as you obviously want to use the analog inputs of J5C) // AIN configuration: // bit mask to enable channels // // Pin mapping on MBHP_CORE_STM32 module: // 15 14 13 12 11 10 9 8 // J16.SO J16.SI J16.SC J16.RC J5C.A11 J5C.A10 J5C.A9 J5C.A8 // 7 6 5 4 3 2 1 0 // J5B.A7 J5B.A6 J5B.A5 J5B.A4 J5A.A3 J5A.A2 J5A.A1 J5A.A0 // // Examples: // mask 0x000f will enable all J5A channels // mask 0x00f0 will enable all J5B channels // mask 0x0f00 will enable all J5C channels // mask 0x0fff will enable all J5A/B/C channels // (all channels are disabled by default) #define MIOS32_AIN_CHANNEL_MASK 0x0fff // define the deadband (min. difference to report a change to the application hook) // typically set to (2^(12-desired_resolution)-1) // e.g. for a resolution of 7 bit, it's set to (2^(12-7)-1) = (2^5 - 1) = 31 #define MIOS32_AIN_DEADBAND 31 // muxed or unmuxed mode (0..3)? // 0 == unmuxed mode // 1 == 1 mux control line -> *2 channels // 2 == 2 mux control line -> *4 channels // 3 == 3 mux control line -> *8 channels #define MIOS32_AIN_MUX_PINS 3 // control pins to select the muxed channel #define MIOS32_AIN_MUX0_PIN GPIO_Pin_5 // J19.SO #define MIOS32_AIN_MUX0_PORT GPIOB #define MIOS32_AIN_MUX1_PIN GPIO_Pin_6 // J19.SC #define MIOS32_AIN_MUX1_PORT GPIOB #define MIOS32_AIN_MUX2_PIN GPIO_Pin_13 // J19.RC1 #define MIOS32_AIN_MUX2_PORT GPIOC [/code] Best Regards, Thorsten.

No, just send to the DEFAULT port, which is assigned to USB0 by default. If you want to send to a MIDI port, just use MIDI0 instead of DEFAULT (or USB0) There is nothing special that you need to add to your code to make this working. It seems that you still haven't worked through the tutorials ;) Best Regards, Thorsten.

AINx4 modules are not chained, the three multiplexer control lines (J6:A/B/C) are connected in parallel - it's really straightforward. Best Regards, Thorsten.

Could you explain the issue a bit better please, because somehow your question doesn't make sense to me. Best Regards, Thorsten.

Alright, I moved your posting to the fleamarket Best Regards, Thorsten.

yes Yes, and you don't need to remove the VR if it is already soldered on board. Best Regards, Thorsten.

P.S.: to check the digital control of the INA/INB inputs, it's probably easier to use the mf_direct_control application instead of sending Pitchbend events to MBLC - it allows you to set the pins directly by using 16 buttons (the first 16 buttons in the DIN chain) Best Regards, Thorsten.

The default mode (TOUCH_SENSOR_MODE 1) is sufficient for your case. Since the faders are even not moved by the calibration applications, the problem is probably located at the MBHP_MF module. Check the voltages: you should read ca. 7.5V at IC1..IC8 pin Vss/Vdd - this voltage should be stable even if the application tries to move the faders. If the voltage is dropping below 7.5V whenever a fader should be moved, the problem is either related to your PSU, or to the LM317 based VR circuit (e.g. bad soldering) Check also the voltages between IC9/10 Vss and Vdd pin, we expect ca. 5V Whenever a fader should be moved, one of the two IN inputs (INA/INB) of the TC4427 IC will be activated (change from 0V to 5V) - one line for upward, another line for downward moves (I don't remember how they are mapped exactly) This allows you to check the serial connection between MBHP_CORE and MBHP_MF: send a Pitchbend value at channel #1 with value 0 (e.g. via MIDI-Ox) - either IC1:INA or IC1:INB should be activated. Now move the fader manually to this position - the line should be deactivated. Thereafter send the maximum pitchbend value, the other line should be activated until the fader has been manually moved to the top position. If none of the direction inputs is activated, there is a problem with the 74HC595 chips or the SO/SC/RC line to the core (check soldering) Best Regards, Thorsten.

Beta20 is available: o taken over track/layer button/LED usage of MBSEQ V3 (important if you are using the old frontpanel): - pattern page: track buttons have the same function like group buttons. They allow to quickly jump between groups to select a new pattern - song page: track/group and parameter layer buttons can be used to set the cursor position while editing a song entry o AOUT driver working again (was not working in beta19) o there is now a separate port/channel setting for recording, it can be directly changed in the UTILITY->RECORD page o the MIDI file import function now starts with the first track that contains MIDI events to ensure that MIDI file tracks are aligned properly to MBSEQ tracks. This is a workaround if the DAW uses the first track as a "master track" to store tempo informations. Previously this always resulted into an empty G1T1 track, and sequences started at G1T2. [/code] One of the next features is the integration of OSC - a lot of preparations have already been done, and you may have noticed, that Seppoman started a for the MBHP_ETH module. It will be possible to send and receive OSC datagrams, e.g. to control OSC capable synths over an ethernet network. If MBHP_ETH is connected to a WLAN router, wireless transfers will be possible as well. One of my long term plans is to create some applications for the upcoming iPad (no, I don't own it yet, and I'm waiting for the first user reviews before buying one). This opens new possibilities, such as running the BLM16x16 emulation on the iPad, or even to run the virtual MBSEQ if the performance is sufficient. MIDI communication will be embedded into OSC frames - so, in any case the MBHP_ETH module will be very useful, not at least for an Ethernet<->MIDI proxy (e.g. send MIDI data from an iPad to your MIDI (or analog) synths w/o the need for a computer) Best Regards, Thorsten.

Thanks - I fixed the link. There will be another update before easter (and before my holidays) with some minor improvements that are on my TODO list. :) Best Regards, Thorsten. P.S.: the AOUT module is not working with beta19 due to a SPI driver change - it will work again in beta20

There was a two-colour option in MBSEQ V3 where a track consist of 32 steps (one colour for 1-16, another colour for 17-32). In MBSEQ V4 a track consists of much more steps, therefore such a display option doesn't make sense anymore. However, if you can assign any other LED function to the second colour if you want. E.g., LED_LOOP or LED_FOLLOW would be a nice candidate; it's your choice. Diodes: they are required for the multiplexed 8x8 button matrix. Best Regards, Thorsten.

Beta19 is available: MIDIboxSEQ V4.0beta19 ~~~~~~~~~~~~~~~~~~~~~ o changed order of instruments in initial drum map (HiHats now at position 3, 4 and 5) o implemented MIDI file import function (UTILITY->DISK->IMPORT) MIDI files have to be copied into the /midi directory of the SD Card. All tracks are imported at once (up to 16) in the same order they are stored in the .mid file. Accordingly, track assignments can be done within the .mid file before it is imported (e.g. edit the .mid file with your DAW) Currently only MIDI Notes and drums are supported (no CCs, no Pitchbender). To import drum tracks, change the import mode from "Note" to "Drum". This mode especially allows to control the velocity of each step separately. Currently drum instruments are only mapped to a pre-selection of 4/8/16 notes - this map cannot be customized yet! Since MIDIbox SEQ is a step sequencer, notes will be quantised with a selectable resolution (16th, 32th or 64th). Also the number of layers/drum instruments is selectable (4, 8 or 16). Than more layers are available, than more notes can be played at the same step. In "Note" mode, all notes share the same velocity and length value, in "Drum" mode each step and instrument has a dedicated velocity value. If the imported track contains different velocity or length values for polyphonic played notes, and this characteristic is important, it is recommented to split the track into multiple pieces (e.g. for long and for short notes) and to import them into separate MBSEQ tracks. Another hint: if notes of the imported track don't start exactly at the 16th/32th/64th note position (e.g. because they have a "swing" feel), it is recommented to quantize the notes in a DAW before the import. The swing feel can be added again after the import (GROOVE page). All tracks will be initialized depending on the selected resolution and layers before the import is started. Than higher the resolution, or than more layers are selected, than less bars can be imported (number of bars is displayed on screen). The MIDI port will always be set to DEFAULT during import. The MIDI channel will be set to the channel of the first played note (for each track separately). MIDI Files can be imported while the sequencer is running. This allows you to search for a certain file, but also to try different parameters during runtime. o some minor bugfixes [/code] Special thanks to Smid Irin who gave me a *lot* of *very* useful .mid files - they helped me to understand the limitations (quantisation), to find workarounds and to optimize the handling of such files. Here two MP3 with patterns that I used as a reference. The patterns have been imported, and they are played by MBSEQ (and not by a MIDI player...): Some virus-like tunes: http://www.ucapps.de/mp3/midibox_seq/mbseqv4_import_tunes.mp3 Some drum patterns at 64th resolution - Shuffle3 groove with intensity 37 has been applied: http://www.ucapps.de/mp3/midibox_seq/mbseqv4_import_drum.mp3 Best Regards, Thorsten.

...or you could record the tracks with your DAW, store them into a MIDI file, and import this into V4 ;) Best Regards, Thorsten.

Under Windows "svn" isn't available by default, but you could use a SVN client like Tortoise Once installed, just checkout "svn://svnmios.midibox.org/mios32" - thats some kind of URL. In order to simplify the documentation I only specified the syntax of plain svn commands. Best Regards, Thorsten.

Unfortunately not - the effort to program a perfectly working conversion tool is higher at my side than writing down the notes/songs/maps on a paper and transfering them manually to MBSEQ V4 at your side. However, if missing completeness isn't an issue, I could provide a menu function to copy the most important data that are easy to convert directly from a bankstick, but the usage won't be so comfortable like known from other functions. Thank you! I will take them as a reference for the next beta release (at least such files should be transfered properly) Best Regards, Thorsten.

Record function: it seems that it makes sense to provide a separate Record Port and Channel, and to make it selectable from the appr. page instead of hiding the selection in the MIDI configuration page. MIDI File import: looks like a simple task. I cannot promisse that I will be able to implement this before my holidays, but it would be helpful if you (everybody who is interested in this function) could attach some sample .mid files, so that I can try out different ways while searching for a comfortable solution. As a special service I can probably give you a ready converted "session" by end of this week ;) Best Regards, Thorsten.

Hi, glad that you like the firmware :) The biggest blocking point for the .midi file import function is, that I don't have a clear idea about the user interface. It would be interesting, how your midi files are structured (e.g. how many tracks, how many bars, how are the drum instruments organized), and how you would like to assign them to MBSEQ tracks. E.g., would you like to assign all drum instruments to a single drum track, or would you like to group them into separate tracks. How would the menu pages look like in your usecase, so that all MIDI files can be properly imported? Best Regards, Thorsten.