TK.

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.

Sorry, I can't help here, I'm not a Windows user. Best Regards, Thorsten.

There wasn't an issue with Microchip EEPROMs (24LC), but with others so far I remember. Best Regards, Thorsten.

Hi, To read the tutorials step by step: http://www.ucapps.de/mios32_c.html We are using different toolchains, they depend on the OS (Windows/Mac/Linux). It's explained in the MEMO You won't get in touch with FreeRTOS so long you don't want to start timed/independent tasks. The big advantage of FreeRTOS is the preemptive multitasking and synchronisation mechanisms (mutex) - if you don't see an advantage with such methods (as explained in the tutorials), just ignore them. But I wouldn't program an application without the provided features anymore. If you want to see the differences, just compare the PIC assembly based MBSEQ V3 code with MBSEQ V4. Check especially how difficult it was to run slow LCD output "in parallel" with timing critical MIDI output - no problem with a RTOS I gave you access to the hidden programmers section. Best Regards, Thorsten.

Hi, I've enabled the "brown out" reset circuit and set it to 4.5V to ensure that the PIC will be reset if the voltage drops below this level. This ensures (for example) that IIC EEPROMs (BankSticks) are only accessed under proper working conditions - with lower voltages data stored in a BankStick could be unintentionally erased or overwritten. So long you are not using devices which rely on this voltage, you can disable the Brown Out reset feature - this can only be done with a PIC programmer (see options screen of your PIC programming software) Best Regards, Thorsten.

Thats a nice idea! :) Do you have C++ knowledge? I could prepare an empty stub for a new MIOS Studio 2 tool where you could insert your code. Advantages: proven MIDI handling, platform independence, and reusable for similar tools in future. Best Regards, Thorsten.

Please write a separate announcement in this section, I will make it sticky. Best Regards, Thorsten.

It's explained in the CHANGELOG and in the src/sid_filter_table.inc file - what detail are you missing? Best Regards, Thorsten.

The filter calibration table is now part of RC36 (yes, I know that it's cumbersome to find the best matching values, since the firmware will be reseted after each .hex file upload...) I avoided to call this effect NMFP ;) Best Regards, Thorsten.

RC36: o Bassline engine: detune parameter now mapped to Parameter #003 o a table based calibration table is now provided for the SID filter. It has to be adapted under src/sid_filter_table.inc and can either be uploaded together with the firmware build, or separately if by uploading "sid_filter_table.hex" after the "make" command (type "make sid_filter_table" to build only this file) The table can be used to compensate technology related non-linearities of the 6581 R-2R DAC o various minor bugfixes [/code] Best Regards, Thorsten.

No, thats wrong. If the descriptions in the MBSEQ V4 manual are not sufficient, have a look into this (expired) tutorial for V2: http://www.ucapps.de/midibox_seq_tutorial1.html You could help me to find an explanation which is better understandable for people who never worked with such an arpeggiator mechanism before. Best Regards, Thorsten.

I tried USB1 and IN1 Did you ever use the arpeggiator? I mean: do you know how it is working? Best Regards, Thorsten.

There is no STM32F105 derivative (which allows to use CAN and USB in parallel) with 512k flash available yet, therefore it can take a year until a complete solution is possible. On the other hand I will be able to prepare the firmwares until then on a STM32F103, but either w/o USB or w/o CAN... Java: yes, JSynthLib is incomaptible to the latest (buggy) Java changes done by Apple. Best Regards, Thorsten.

This is a very interesting page: http://www.bel.fi/~alankila/c64-sw/index-cpp.html (btw.: wouldn't it be nice to use the improved filter models for the MBSID V3 VST/AU emulation? :) It gave me the keyword R-2R ladder DAC. As you can read in Wikipedia: I don't think that the Rs were laser-trimmed in those years ;) So, how to solve this: I could add a fast accessible calibration table so that the "bad steps" can be excluded or smoothed out. It would consume 4k (not sure if so much is still available), but everybody would have to adapt it manually for his SID by editing the table and rebuilding the application. Best Regards, Thorsten.

Now I tested it with a 6581 marked with 2584, another one marked with 4084 Both have a different filter response - but the interesting point: with both chips I can hear this unbalanced step as well (on the 4084 much more noticable than on a 2584) Time to search in the internet for similar observations. Best Regards, Thorsten.

Btw.: are your 6581's from the same batch, resp. produced at the same time? Best Regards, Thorsten.