TK.

Hallo Michael, der Master weiss gar nicht, ob 1, 2 oder 3 Slaves angeschlossen sind, es gibt hier keine Rueckkopplung, er sendet die Kontrolldaten einfach raus. Insofern musst Du nichts an der Software aendern. Gruss, Thorsten.

The DOUT registers are refreshed at 1 mS maximum, if you need higher frequencies, you need to write an own SR handler which is doing this (and nothing else) from the main thread (-> Tick()). The scan matrix examples are a good template, how to realize this. Best Regards, Thorsten.

Good progress! No, a ground connection wouldn't help, in distance: it could lead to new problems (ground loops), therefore an optocoupler is so important (especially for synths and jitter-free pots) An optocoupler contains a small LED and a small light receiver, the LED is driven from the MIDI interface (your MIDIsport 2x2), and the output of the light receiver is connected to PIC. This is the reason why I proposed the LED check in the troubleshooting section, because if the MIDI interface can drive this "normal" LED, it can also drive the integrated LED within the optocoupler. Something what can happen is, that the integrated LED will be destroyed if you forgot the resistors at the MIDI In. Also the protection diode 1N4148 is important, otherwise a wrong polarity could fry the LED as well... so, have you ever bypassed one of these components during your tests? Best Regards, Thorsten.

Hi Luke, this is not supported by the official firmware, but somebody made a modification, which was discussed somewhere in the forum. Seems that this hasn't been added to the Wiki.. I searched for the article, but haven't found it. I think it was either here (HUI) or in the assembler section - does anybody have more luck? Best Regards, Thorsten.

Am besten schliesst Du erstmal in Ruhe die LEDs an das DOUT Modul, so wie in diesem Schaltplan beschrieben: http://www.ucapps.de/midibox_fm/mbfm_dout_default.pdf Auch die Buttons fuer die Spalten kannst Du bereits so wie gewohnt anschliessen: http://www.ucapps.de/midibox_fm/mbfm_din_default.pdf Die 4 Buttons fuer die Zeilen werden an einem Pol zusammengeschlossen, und an J8:D1 gefuehrt. Die gegenueberliegenden Pole werden ueber Dioden (bspw. 1N4148) an J4:D2-D5 des DOUT Moduls angeschlossen Gruss, Thorsten.

Ja, die Farbe ist irrelevant, man muss an den Settings nicht aendern. Aus einem RAM Dump koennte ich herauslesen, in welchem Zustand sich der LCD Driver befindet, z.B. welcher Display Typ aktiviert ist (er sollte auf 0 stehen, dieser Wert wird vom PIC ID Header vorgegeben, wenn man den Bootloader in den PIC programmiert), und ob MIOS immer noch versucht, das Display anzusprechen. Einen RAM Dump kann man in diesem Debug Fenster requesten: http://www.midibox.org/dokuwiki/lib/exe/fetch.php?cache=cache&media=http%3A%2F%2Fwww.midibox.org%2Fmios_studio%2Fmios_studio_functions_s.gif - "SRAM Read" anwaehlen - Address 0x000 - No. Bytes 0x600 - Start druecken - die ausgegebenen Daten in diesen Thread reinpasten Gruss, Thorsten.

This is something what I'm planning to solve in one of the next MIOS versions - currently the same SR scanning routine is used for DIN and DOUT registers, which means, when the DINs are temporary disabled due to the cheap debouncing method, the DOUT registers won't be updated. The solution is to add a second scan routine which only services the DOUTs so long the debouncing delay is active. Best Regards, Thorsten.

Ok, wie bereits geschrieben: in beiden Schaltplaenen findest Du die Pinbelegung fuer Alps Encoder in einem extra Kaestchen. LEDs - das kurze Beinchen ist die Kathode, auch hier am besten mit dem Schaltplan vergleichen: [tt] |\ Anode | \ | Kathode ---------------| >|--------- langes Beinchen| / | kurzes beinchen |/ [/tt] Du verbindest die Kathoden (den Minus-Pol) mit Masse - das ist richtig. Gruss, Thorsten.

Hallo Chris, so wie es ausschaut, wurde das direkte Requesten eines Snapshots via SysEx vergessen... Es gibt drei moegliche Bastelloesungen, die keine grossen Codeaenderungen nach sich ziehen: 1) in USER_MPROC_DebugTrigger (main.asm) folgenden Aufruf einbauen: USER_MPROC_DebugTrigger call MB64_PATCH_Send return [/code] Und die Funktion mit dem MIOS Funktionsaufruf: F0 00 00 7E 40 00 0D 01 00 60 0C 00 00 00 00 00 00 00 00 F7 ausfuehren 2) in MB64_SFB_Handler_01 (mb64_sfb.inc) folgenden Aufruf einbauen: [code] MB64_SFB_Handler_01 call MB64_PATCH_Send rgoto MB64_SFB_Handler_End damit steht der Snapshot als SFB #01 zur Verfuegung 3) den AUTO_SNAPSHOT einschalten, so dass der Snapshot automatisch nach einem Bankwechsel gesendet wird Gruss, Thorsten.

Hallo Basti, die Datenblaetter fuer DT6 und Taster3301D geben nicht viel her, deshalb wuerde ich empfehlen, die Belegung einfach auszutesten - man kann hier nichts kaputt machen. Die Belegung fuer die Alps Encoder findest Du in den meisten Schaltplaenen in einem extra Kaestchen (um welche MIDIbox geht es genau?) Gruss, Thorsten.

Hi, in general I wouldn't use the long data type, because it propably (I never used it...) consumes 4 bytes, which means, that each operation takes twice the time, even when only the lower 16 bits are changing. Best Regards, Thorsten.

Thanks for the hint - this can happen when I'm doing special binaries for special users... However, I've updated the package with the correct setting Best Regards, Thorsten.

Hi Ralf/Robert, this is one of the most beautiful controllers I've ever seen - I'm impressed! The design demonstrates your full passion for this baby :) Best Regards, Thorsten.

Hi *, finally the new MIDIbox SID firmware v1.7303b has been released. New features: volume modulation via ENV2 as workaround for the ADSR bug - thanks Jess for this idea "oscillator gates always active" option as alternative workaround for the ADSR bug - again: thanks Jess for this idea :) arpeggiator overworked (constant arp cycle time) - and again: thanks Jess for this idea! filter control curve can now be scaled between a min and max range - hm... idea by Jess, you know ;-) cosmetic LCD changes (patch number now patted with 0, message after Patch upload) In addition, a new preset library is available: new Patches C038-C048 made by Sebastian (aka Rio) new Patches C049-C055 made by TK (they demonstrate the possibilities of the V1.7303 sound engine) A018 (Arpeggio): changed Arp speed from 110 to 70 A019 (Arpeggio2): changed Arp speed from 110 to 70/90 Download: http://www.ucapps.de/mios_download.html ChangeLog: http://www.ucapps.de/midibox_sid_changelog.html New Preset Library: http://www.ucapps.de/midibox_sid/preset_patches_20060820.zip Propably you have to push the "refresh" button of your web browser to see the changes Have fun! :) Best Regards, Thorsten.

In general such local group DIY events are something I want to support, therefore a big plus So long you are building this together with friends, it doesn't require my permission, even if they give you money for your effort. Once you are planning to offer PCBs, kits or prebuilt projects to unknown people (e.g. via ebay), we have to discuss this again... Best Regards, Thorsten.

The only difference between bootloader 1.1 and 1.2 is the different location within the flash memory, and the different code range which is allowed to be programmed. Could somebody please send me one of those defective PICs? I would like to analyse this issue. Best Regards, Thorsten.

I think that the problem is located on your Linux installation, on my computers it doesn't work stable as well, but I don't have the time to spend several hours to find the root cause. I did some debugging ca. 5 years ago, at the end I had to patch the MIDI driver of my soundcard, so that it can send larger SysEx blocks... don't know about the current state, but my Linux version and the drivers have changed in the meantime, and it just doesn't work properly anymore. Did you ever try the upload under Windows? Best Regards, Thorsten.

Die MIDI Events bestehen aus 3 Bytes? Dann hat jede MIDIbox bis zu 960 uS Zeit, das Event zu parsen, ohne dass es zu einem Buffer Overrun kommen kann. Die MIDI bytes werden ja via Interrupts im Hintergrund versendet, bleibt genuegend Zeit fuer den Mainthread - und wenn es mal etwas laenger dauert, macht das i.d.R. auch nichts, denn 64 Bytes auf der MIDI In Seite koennen bis zu 20 mS ueberbruecken. Kritisch wird es, wenn kontinuierlich MIDI Events empfangen werden, dann muss das Parsing in weniger als 960 uS abgehandelt sein. Das ist uebrigens nicht die ganze Wahrheit - es gibt dann auch noch den Running Status, der aus einem 3-Byte Event zwei Bytes macht, somit waeren nur noch 640 uS Zeit. Und die ISRs lasten die CPU zusaetzlich aus, deren Ausfuehrungszeit haengt von unterschiedlichen Parametern ab... doch ich muss hier wohl nicht zu sehr ins Detail gehen, das Systemverhalten ist extrem fallabhaengig. Wenn ein neues MIDI Event eintrifft, bleibt MIOS solange in der "MPROC" (MIDI Processor) Schleife, bis das Event vollstaendig empfangen wurde. Die anderen Hooks wie Tick(), AIN_NotifyChange() oder DIN_NotifyToggle() werden in dieser Zeit nicht augerufen, lediglich die MPROC_*() Hooks und die ISRs Wenn das Event nicht komplett eintrifft (Fehler auf der MIDI Sender Seite), wird nach ca. 2 Sekunden die MPROC_NotifyTimeout() Funktion aufgerufen, und das Parsing wird abgebrochen. Es macht Sinn, in diese Funktion eine Debug Meldung einzubauen, um ueber eine fehlerhafte Uebertragung informiert zu werden. Wenn sich Deine MIDIbox also scheinbar fuer kurze Zeit aufhaengt, dann koennten inkomplette MIDI Events die Fehlerursache sein. Gruss, Thorsten.

Just great! :) Best Regards, Thorsten.

Yes, with MIDIsport devices it works: ground (the middle pin of the MIDI cable) has to be connected to J11:Vs, and the Tx signal of the MIDI interface (compare with MIDI Out of the core module where Tx of the PIC is connected - if you are unsure, try both possibilities) to J11:Rx The optocoupler has to be removed to avoid a short circuit Best Regards, Thorsten.

In MBSEQ V3 you can set the loop start point with a GP encoder, the track end with a second GP encoder... in addition, you can rotate the pattern within the loop in the shift menu. Skip Steps are possible as well, and not to forget: the progression parameters. The possibilities are already endless :) Here some snapshots: Best Regards, Thorsten.

Tip of the day: did you ever check what happens when the two wires to the MIDI In socket are swapped? Best Regards, Thorsten.

Hi, it should work, there is nothing special on this MIDI interface. Best Regards, Thorsten.

Hallo Thomas, das Bottleneck entsteht an der seriellen Schnittstelle - es handelt sich hier um einen asynchrones serielles Interface, das heisst: feste Baudrate und vorgegebene Bandbreite, die sich nicht erweitern laesst. Heisst: wenn am Eingang bereits mit voller Bandbreite empfangen wird, und die Daten zum Ausgang weitergeleitet werden sollen, dann sollte man vermeiden, bei maximaler Auslastung noch zusaetzliche MIDI Events hinzuzufuegen - ansonsten stauen sich die Daten auf, und es kann zu einem Buffer Overrun kommen. In Deinem Projekt ist das vielleicht nicht der Fall (wie ich nach Deiner dritten Mail gemerkt habe), aber die potentielle Gefahr besteht immer. Und diese gilt es zu vermeiden. Doch mir ist eingefallen, dass die vorgeschlagene Loesung am Ziel vorbeifuehrt. MIOS_Delay() ist voellig fehl am Platze, denn sie blockiert den Mainthread. Ausserdem scheint das Problem in Deinem Programm zu sein, dass die Snapshot-Daten gesendet werden, waehrend der eingehende SysEx String noch nicht vollstaendig uebertragen wurde. Sendest Du die Daten vor oder nach dem 0xf7? Wahrscheinlich davor... und so werden sich alle nachfolgenden MIDI Parser (auch MIDI-Ox) fehlerhaft verhalten. U.u werden zusaetzliche Bytes hinzugefuegt oder von MIDI-Ox angezeigt, die gar nicht ueber die MIDI Leitung gegangen sind, weil die "State Machines" auseinanderlaufen (man darf nicht alles glauben, was MIDI-Ox anzeigt...) Eine Loesung, die dafuer sorgt, dass das MIDI Protkoll eingehalten wird, und die zusaetzlich auch die Auslastung des MIDI Out Ports ausbalanciert (so dass ein Buffer Overrun sehr unwahrscheinlich wird), sieht wie folgt aus: Der Snapshot sollte nicht sofort gesendet werden, sondern portionsweise mit jedem Aufruf von Tick() - der SysEx Parser sollte den Snapshot lediglich requesten, den Rest uebernimmt ein separater "Snapshot Handler". Diese Methode hat zwei Vorteile: die Snapshot-Events werden erst gesendet, wenn der SysEx Stream beendet wurde, und durch das portionsweise Senden kommt der Merger nach jedem Event wieder zum Zuge - ist also zwischendurch wieder etwas eingetroffen, so werden die eingegangenen Daten zuerst versendet, und die intern generierten Daten werden verzoegert. Der interne Stream wird quasi automatisch blockiert - und so sollte es im Idealfall auch sein. Hoert sich vielleicht kompliziert an, ist aber relativ einfach zu realisieren. In Tick() folgendes hinzufuegen: (ich nehme an, dass 8 Events versendet werden sollen, snapshot_ctr ist eine globale Variable): void Tick(void) { // send part of snapshot until counter is 0 again if( snapshot_ctr ) { SendMIDIEvent(8-snapshot_ctr); // this function sends a part of the snapshot, selected with the counter --snapshot_ctr; } } [/code] Im SysEx Parser den Aufruf der Komplett-Snapshot Funktion durch folgendes ersetzen [code] // request snapshot snapshot_ctr = 8; das wars. Probiere es mal aus, Du wirst ueberrascht sein, wie gut es funktioniert ;-) Gruss, Thorsten.

With the MIDIsport 4x4 (and 2x2) normaly no problems have to be expected - hardware & driver work very stable Best Regards, Thorsten.