TK.

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.

fixed (programming error in USER_AIN_NotifyChange after code optimisation) -> http://www.ucapps.de/mios_download.html Best Regards, Thorsten.

fixed Best Regards, Thorsten.

Hi, you can run MBSEQ V2 on the PIC18F4620 without recompiling the .hex file, only the bootloader and MIOS are different (precompiled .hex files are available for these variations within the MIOS update package) Since I've overworked the controlling of "output ports" completely (AOUT is now handled as a seperate MIDI Out, and not like a Meta Event like before), it shouldn't be a problem to add a bypass option, which forwards incoming MIDI events of a certain channel directly to the CV and gates. Best Regards, Thorsten.

Great :) Feel free to contact me directly (tk _at_ midibox.org) Best Regards, Thorsten.

Your drawing looks correct, there is only one error, but I guess that you've considered this: the polarity of the LED is wrong. When the LED is permanently on, it has the same effect like if the optocoupler is not in the socket (you can remove the opto in order to doublecheck this behaviour). This would identify again, that there is a connection problem (did you check the bottom of the PCB?) And another hint: check the polarity of D1 Best Regards, Thorsten.

Try to upload with the 1st level bootloader (within 2 seconds after power-on) if this happens Best Regards, Thorsten.

Is this test working? if not, you propably missed to solder a pin, or there is a short at the bottom of the PCB Best Regards, Thorsten.