TK.

I think that you are mixing something. The definitions in mios.h are constant values which are used to address the desired encoder mode from the application code. All values in mios.h should never be changed, this is "low level stuff" The MBSEQ application only differs between "normal" and "fast" encoder settings. They are selected in SEQ_BUTTON_Fast (file seq_buttons.inc), and only allow one parameter for fast mode: DEFAULT_ENC_SPEED_VALUE Do you really need different values? If so, the source code has to be changed in seq_buttons.inc, and in addition somewhere within the USER_Init function, since by default the "normal" mode is selected, which doesn't need further initialisations Best Regards, Thorsten.

In one of your older posts I can see that you are using a MPU-401 MIDI interface. Is this part of your mainboard, or a soundcard? Did you check that the interface itself is working, e.g. with a direct loopback PC MIDI Out -> PC MIDI In? Just to ensure... If this is a gameport based interface, you could try a direct TTL connection over the MIDI Link port of the core w/o optocoupler. This maybe gives you some more input, what is working. Best Regards, Thorsten.

Bastelloesung... Siehe http://www.ucapps.de/mbhp_iic_midi.html USB bietet fuer jeden MIDI Port eine eigene Pipe, ausserdem gibt es eine Art Handshaking, so dass Daten nicht verloren gehen koennen. Ich bezweifle, dass sich der Aufwand lohnt. Zumal der COM Port sowieso ausstirbt Gruss, Thorsten.

Here again a video from a debugging session. After the last changes, some features are not working properly anymore (e.g. multi triggers), however, there is a lot of new stuff instead ;-) -> MBSEQ runs in song mode, a lot of arpeggiators are active, some CC lines for trancegate effect, most tracks are configured for 32th note resolution, one track runs with 2/3 speed. Best Regards, Thorsten.

Hi, the speed values can be changed in the .asm file you are using - either main.asm, or setup_mbseq_v2.asm - search for "SPEED" Nice to hear, that this is the only problem :) Best Regards, Thorsten.

Du moechtest also vom Linux Treiber aus "Load Sharing" betreiben? Das wuerde theoretisch funktionieren, erfordert jedoch Kenntnisse in der Treiberprogrammierung. Die maximale RS232 Baudrate ist 115200 Baud, der Mikrocontroller sollte sich in diesem Fall nur noch um das Routen kuemmern, da die Bytes alle 80 uS eintreffen. Zusaetzlich koenntest Du auch ein Handshaking ueber die RTS/CTS Leitungen realisieren, um einen potentiellen Datenverlust von vorneherein zu vermeiden. MIOS ist hierfuer nicht geeignet, es wuerde auf eine eigene Firmware und einen zusaetzlichen Mikrocontroller herauslaufen. Solange Du die MIDIbox als Controller betreibst, wird es mit der to-COM Schnittstelle keine Probleme geben. Ein vollwertiger MIDI In/Out erfordert wesentlich mehr Entwicklungsaufwand auf uC und Linux Seite - viel Spass ;-) Eine bereits laufende Loesung waere die Verwendung des MBHP_USB, oder MBHP_USB_PIC Interface (MBHP_USB_PIC ist nicht offiziell released, und auch nicht dokumentiert, laeuft aber - auch unter Linux - mit bis zu 5 MIDI In und Outs) Gruss, Thorsten.

no... Best Regards, Thorsten.

nein, schon die PIC16F basierenden MIDIboxen konnten mit der COM Baudrate senden, der Merger war nur dann notwendig, wenn man an den MIDI In auch ein normales MIDI Keyboard anschliessen wollte, bei dem sich die Baudrate i.d.R nicht aendern laesst. wenn der interne MIDI Merger aktiv ist, werden eingehenden und intern generierte Daten weitergeleitet. Ausnahme sind getunnelte Events, doch das ist ein anderes Thema ("MIDIbox Link") Das Routing, das Du selber programmieren muesstest... wenn MIDI Out1 saemtliche eingehenden Daten, und zusaetzlich vielleicht auch die internen Daten weiterleiten soll, dann entsteht hier ein Flaschenhals. Das Problem besteht in beiden Richtungen, ist aber sehr stark fallabhaengig. Wenn die MIDI Applikation (in Deinem Fall: Sequenzer) nicht kontinuierlich MIDI Events sendet, dann koennen sie rechtzeitig weitergeleitet werden, bevor sich etwas staut. Eine hoehere Baudrate wuerde das Problem noch verschaerfen... Wie soll Dein Setup konkret aussehen? Ich habe das Gefuehl, dass wir einander vorbeireden. Evtl. ist USB in Deinem Fall doch die bessere Loesung. Gruss, Thorsten.

Sowohl MIDI->USB als auch USB->PC sind gebuffert, zusaetzlich bietet USB auch noch eine Art Handshaking, so dass Daten nur auf der MIDI->USB Strecke verloren gehen koennten. Das serielle Interface hat einen Hardware Buffer, doch der ist kleiner. Auf Treiberseite wird jedoch ein zweites mal softwaremaessig gebuffert, so dass die Wahrscheinlichkeit fuer einen Datenverlust sehr gering ist (in der Praxis wird das wohl niemals geschehen). Ja, wie unter http://www.ucapps.de/mios_bootstrap_experts.html beschrieben, muss im ID Feld der Wert "000000000000100" eingetragen werden. Dies geschieht beim Programmieren des Bootloaders, der holt sich dann genauso wie spaeter MIOS die Konfiguration aus diesem Feld. was moechtest Du genau mergen? Theoretisch waere das moeglich, ich habe es jedoch noch nie selbst ausprobiert. Man kann das interne MIDI Interface auf 38400 Baud einstellen, und die MBHP_IIC_MIDI slaves (bis zu vier koennen betrieben werden) mit normaler Baudrate. Allerdings werden die Datenstroeme nicht von MIOS verwaltet, sondern das muss auf Applikationsseite geschehen. Ein Beispiel befindet sich in der MIDI Router Applikation. Ein Problem: in dieser Konstellation kann es sehr einfach zu einem Buffer Ueberlauf kommen, da die Daten ueber den internen Port schneller eintreffen, als sie ueber das normale MIDI Interface mit niedrigerer Baudrate uebertragen werden koennen (Flaschenhals Problem) - MIDI bietet kein Handshaking. Grosse Buffer mildern das Problem (bei MIOS: 64 Bytes, bei MBHP_IIC_MIDI: 96 bytes), doch die Gefahr besteht... Ja, ausschliesslich (Multi Master Betrieb wird nicht unterstuetzt) Gruss, Thorsten.

Hallo Stefan, es mag zwar seltsam klingen, doch die serielle Verbindung ueber die COM Schnittstelle funktioniert schneller als die Verbindung ueber MIDI->USB->Laptop, da MIDI mit einer etwas langsameren Baudrate laeuft, und der direkte Weg ueber USB bei den MIDIbox Projekten nicht moeglich ist. to-COM ist auch einfacher zu realisieren, deshalb wuerde ich diese Loesung in Deinem Fall favorisieren. Der Treiber fuer das COM Interface befindet sich wahrscheinlich bereits auf Deiner Festplatte, er gehoert zu Alsa. Ein HowTo zur Installation gibt es hier: http://alsa.opensrc.org/serial, einziger Unterschied: die Baudrate betraegt 38400 Gruss, Thorsten.

it works like described in the ChangeLog no, there are static assignments like described in the ChangeLog. There will be an additional modulation matrix like described in the V2 Wishlist, there are no additional details available yet Same like for MBSEQ V2, see http://www.midibox.org/forum/index.php?topic=7220.0 We will see.... there are some threads where the concepts are discussed, but everything can change - just wait until next year. Best Regards, Thorsten.

I've just implemented this - but on the easy way (not so complex like you are planning it for Vx): a track can now run with a resolution of 64th notes, and this value can be divided by 2, 3, 4, 5, ... 64 So: for the normal 16th notes resolution, divider value 4 has to be selected, for 8th notes divider 8, for 32th notes divider 2, etc... Especially for odd dividers there is an optional synchronisation to the (virtual) master track after 1 bar And the divider menu page provides a "quick selection" for most common divider values. Best Regards, Thorsten.

Nice Idea, I've added it to this page: http://www.midibox.org/dokuwiki/doku.php?id=layout_improvements, so that it doesn't get lost Best Regards, Thorsten.

The A/B switch allows to chain two patterns - very useful :) Best Regards, Thorsten.

Hi, currently it's a very primitive hardwired routing. It will get much more flexible with MBSID V2 (flexible routine, multiple parameters, selectable ranges) Best Regards, Thorsten.

How do you want to edit the patch name without the menu buttons? And I guess that for MBSID V2 they will be more important than ever before. Best example is the MBSEQ V3, where all menus have been improved for better live usage - with the drawback, that everybody needs the original hardware setup in order to use the new firmware Best Regards, Thorsten.

By default, the matrix displays the LFO/ENV levels of the master in realtime (see ChangeLog) It seems that this (nice) feature confuses people more than really required, therefore I will change the default setting, so that the matrix connections are displayed after startup Best Regards, Thorsten.

This pinning is correct - I noticed this mismatch some years ago, but it was too late to change all schematics, because this mostly results into more questions than really required. Best Regards, Thorsten.

Great :) Best Regards, Thorsten.

Good that I don't need to fullfill your personal wishlist here ;-) The calculations for shuffle are not correct, you are especially mixing ppqn with the number of ticks between two steps, and you don't consider the required divider values when a sequencer is synchronized to MIDI clock (or when it sends MIDI clock). However, 0..15 ticks for shuffle is more than enough, the algorithm is already available in the MBSEQ application, therefore I think that I don't need to explain where the errors are... just listen to the MP3 at the MBSEQ page which demonstrates how the sequencer behaves when the shuffle value is slowly increased. Best Regards, Thorsten.

Meine 8580R5's werden auch heiss, aber es hat ihn in den letzten drei Jahren nicht geschadet Gruss, Thorsten.

Hi Rowan, it's not required so long you are not using any MBHP_IIC* module Best Regards, Thorsten.

It's worth a try for this small money. The 5V output is a little bit weak, but it could be enough (it mainly depends on the power consumption of the backlit LCD, and how many LEDs are connected). Filter: maybe the Synth-DIY mailinglist could help here, there are the experts for PSU filters :) Best Regards, Thorsten.

So long you don't use a backlit LCD, which consumes a lot of power, it should work Best Regards, Thorsten.

From the programming point of view I could support so many gates and CV outputs you ever want. But I don't want to do the circuit/PCB design + documentation for stuff I never used and tested by myself. So, if you could develop the circuit, and provide it to the community, I could easily add the driver as "AOUT option #3" Best Regards, Thorsten.