TK.

Hi James, Such a problem could be related to a unstable (or missing) connection to the SC (serial clock) or RC (capture) to the DIN module(s). In order to troubleshoot this, it makes sense to disconnect the DIN modules, and to connect them again one by one. Either the cables between the modules are faulty, or one module breaks the SC/RC line which goes to all DIN shift registers. Check also for bad solder joints around the RC/SC traces on the PCB. My guess is, that a new installation won't help. But for the case that you want to try it out, you've to be very careful with such an old setup. Exactly 6 years ago (9th April 2006) I introduced MIOS V1.9 with a new bootloader (v1.2) which isn't compatible to Bootloader V1.1 MIOS Studio 2 only supports the "new" (ok, now 6 years old) bootloader. Do you remember which Bootloader version is installed on your PIC? Or: did you buy the PIC from SmashTV? Then it should be written on the sticker. If Bootloader V1.2 is installed, you can update MIOS and thereafter the MIDIO128 application without problems! Best Regards, Thorsten.

I'm a bit confused now. Initially your problem was, that messages from jorgan don't get to the PIC based core, now you are asking for DIN/DOUT matrix wiring. You are writing that "A simple test of the matrix using midiox pressing each keyboard key one at a time shows the correct note number and note for each key. The same holds true for matrix 3 on channel 5." But you are not writing which function isn't working. Accordingly I can't give you explicit hints, I will just stupidly answer your questions... ;-) yes, the channel assignment has nothing to do with the matrix number. In other words: a matrix can be assigned to any MIDI channel, it's even possible to send different notes to different MIDI channels as you might remember. Unused DOUT pins shouldn't be connected, let them open. Unused DIN pins have to be connected via the 10k resistor to 5V. In other words: it isn't recommended to leave out the 10k resistors! I'm sorry, but I don't understand the problem. With the "left window of MIOS Studio" you probably mean the MIDI IN monitor. It shows MIDI events which are received from the LPC17 core (and of course MIDI events which are sent by the PIC core, and which have been forwarded by the LPC17 core) Yes, the version of a MIOS32 based application will be displayed on a query. No, the version of a MIOS8 based application won't be displayed on a query. Best Regards, Thorsten.

Danke fuer die Hintergrundinformationen! Die Hardware sieht ja schonmal ziemlich gut aus! :thumbsup: Ein Tip zum Thema "virtueller MIDI Treiber": der wird zu einer zusaetzlichen Latenz sorgen, die man umgehen koennte, indem USB fuer mehrere MIDI Ports konfiguriert wird. Einfach folgendes in Dein mios32_config.h File einbauen: #define MIOS32_USB_MIDI_NUM_PORTS 4 [/code] kompilieren, aufladen, und danach den USB Stecker raus, und wieder reinstecken. Anschliessend sollten unter Windows 4 getrennte Ein- und Ausgaenge sichtbar sein. Evtl. wirst Du auf den USB MIDI Bug von Win7 stossen, der sich jedoch mit dem Korg USB Treiber umgehen laesst: Fuer mich waere es interessant zu wissen, ob sich die Performance mit diesem Treiber verbessert (auch wenn Du noch nicht auf SysEx umgestiegen bist) Gruss, Thorsten.

There was a problem with the UART sending routine which is fixed. It can't be excluded that common MIDI events were affected as well. But under the assumption that you already updated to MIDIO128 V3.007, the problem must be located somewhere else. In an earlier posting (see this thread) I explained how to debug the MIDI routing. E.g. you can use the internal MIDI monitor which shows incoming/outgoing MIDI events on the LCD. You can also use a MIDI monitor running on your PC to check if OUT1 of the core really sends the MIDI event to the PIC based core. Hope that this helps to solve the issue! Best Regards, Thorsten.

I can help you at least with a link to background informations about the CV option: For additional build instructions, I'm unsure which articles you've already read, what is unclear, etc... Maybe a (ex-)newbie can help you when he describes the build from his view. Best Regards, Thorsten.

Uebetraegst Du nun einzelne MIDI Events oder SysEx Streams? Mit welchem Programm werden sie gesendet, welches Betriebssystem, welche Updaterate wird angestrebt? Ohne diese Angaben ist es wirklich schwierig, Dir weiterzuhelfen... Gruss, Thorsten.

In Deiner Mail klang das aber noch anders (+/- waren vertauscht ;-) Wie ich bereits schrieb, weiss ich nicht ob die restlichen Chips davon schaden nehmen koennen. Du kannst mir den Core und das OPL3 Modul zum Testen zuschicken. Gruss, Thorsten. P.S.: im uebrigen stimme ich Ilmenator zu, das ist Thomasch' Thread und wie sich bereits herausgestellt hat, wird es bspw. fuer mich immer schwieriger, nach seinen Details zu suchen.

Yes, I can implement it this way for tracks where the Aux layer is configured for Accent. The Aux layer can also be assigned to flam/skip/etc... in this case separate entry will be possible (as known from MB808), and accent can only be controlled via the global accent track #16 (as known from MB808 as well) Best Regards, Thorsten.

ok for me; nice price for such a great build! :) Best Regards, Thorsten.

Du hast vergessen, die Vorgeschichte zu erwaehnen - warum und wie moechtest Du das Display ueber MIDI bedienen? So koennte ich Dir genauere Tips geben. Deshalb erstmal nur ein allgemeiner Hinweis: dein Rechner bremst die Transfers aus wenn zuviele MIDI Events aufeinmal generiert werden, deshalb ist es ratsam, die Display-Befehle zu streamen. Wenn Du bspw. den Display-Inhalt in wenige Sysex-Befehle verpackst, dafuer aber wesentlich mehr Bytes pro SysEx Kommando versendest, sollte der Update ziemlich flott gehen. Unter http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F025_sysex_and_eeprom%2F findest Du ein Beispiel, wie eingehende SysEx-Streams verarbeitet werden koennen (siehe sysex.c). Das EEPROM-Geraffel kannst Du aus dem Code entfernen, dann wird er wesentlich uebersichtlicher. Grundsaetzlich wuerde ich empfehlen, nicht mehr wie 512 Bytes in einen Stream zu packen, da groessere Datenmengen vor allem unter Windows (und hier speziell WinXP) manchmal zu Problemen fuehren. Ausserdem musst Du dann noch beachten, dass in der Payload nur 7-bit Daten erlaubt sind. Deshalb ist es ratsam, die Bytes nibbleweise (untere/obere 4 bit) zu uebertragen. Auch das wird im Tutorial gezeigt (SYSEX_FORMAT == 1) Spezialzeichen werden mit APP_LCD_SpecialCharInit() initialisiert, und mit ASCII Code 0..7 ausgegeben (es sind also nur 8 vorhanden). Die werden nur von CLCDs unterstuetzt. Im Graphik-Modus muesstest Du die Zeichen direkt ausgeben, wie bspw. ueber die APP_LCD_BitmapPrint() Funktion Dieser Modus wuerde Dir dann auch weiterhelfen, groessere Bild-Fragmente im Core zu speichern, und ueber einen speziellen SysEx-Befehl zu platzieren. Gruss, Thorsten.

Machst Du bitte mal ein Foto vom Display wenn folgendes Muster ausgegeben wird: APP_LCD_Data(0x01); APP_LCD_Data(0x02); APP_LCD_Data(0x04); APP_LCD_Data(0x08); APP_LCD_Data(0x10); APP_LCD_Data(0x20); APP_LCD_Data(0x40); APP_LCD_Data(0x80);[/code] So kann ich mir besser vorstellen, wie das Display funktioniert. Gruss, Thorsten.

ok for me. Best Regards, Thorsten.

Yes, the ADSR workaround causes a constant delay which is identical for all modes. E.g. I used it live during the "bassline demo 3" video session - but without other instruments, therefore no compensation was required. No, because the external VCA could only be used for 3 oscillators at once (for each SID output) Maybe somebody has an advice for a good Fx unit which can be used for constant delays? :flowers: Best Regards, Thorsten.

Fine! :) Best Regards, Thorsten.

Hallo, schoenes Projekt, unbedingt veroeffentlichen sobald es fertig ist! :) Ich habe mal in das Datenblatt reingeschaut (http://www.crystalfontz.com/controllers/ST7920.pdf) Es gibt schonmal keinen GLCD Treiber, den Du hier wiederverwenden koenntest. Das Protokoll ist zum "CLCD" kompatibel (MIOS32_LCD_TYPE_CLCD), und es gibt einen "Extended Mode", mit dem die Grafikfunktionen freigeschaltet werden. Die entsprechenden Kommandos (die Du aus dem Datasheet entnimmst) lassen sich mit APP_LCD_Cmd() absetzen. Mit APP_LCD_Data() schreibst Du dann in das Display-RAM So koenntest Du erstmal herausfinden, ob die Freischaltung des Grafikmodus funktioniert. In das Display-RAM wuerde ich erstmal ein Muster reinschreiben, bspw.: APP_LCD_Data(0x01); APP_LCD_Data(0x02); APP_LCD_Data(0x04); APP_LCD_Data(0x08); APP_LCD_Data(0x10); APP_LCD_Data(0x20); APP_LCD_Data(0x40); APP_LCD_Data(0x80); [/code] so kannst Du bei der Gelegenheit auch gleich die Bildschirm-Orientierung (vertikal oder horizontal) ermitteln - und sobald das klar ist, kann ich Dir sagen, welche GLCD-Routinen sich wiederverwenden lassen (bzw. ich koennte Dir dann mal schnell einen neuen GLCD Typ einrichten) Gruss, Thorsten.

Hi, good news: I reviewed the code and noticed that the DIN mapping wasn't taken into account. Accordingly, the DIN state was mapped to the wrong MIDI event after power-on. Here a corrected version: http://www.ucapps.de/mios/midibox64_v2_4f.zip Please try it, maybe it helps a bit. This is true for a momentary button, especially if the toggle function is used, as the state (on or off) is stored in software. A workaround would be to store a snapshot before power-off (press&hold SNAPSHOT button for two seconds), and to recall the snapshot after power-on (press the SNAPSHOT button shortly) But if a "real switch" is connected instead, the state is stored "mechanically" and therefore can be recalled after power-on without a manual snapshot (if you are using the new firmware) No, it would be the same problem - you would have to store the state with the SNAPSHOT button. But just to be sure: when you are speaking about a "momentary switch", to you really mean a switch like this one: Or do you mean a momentary button like this one: Best Regards, Thorsten.

The "CV via DOUT" option is implemented, and I tested it on a single DOUT -> works! Now the remaining resistor networks have to be soldered on the PCB + some testing has to be done. Schematic: ;; ;; CV values can also be output via DOUT shift registers ;; This option is sufficient to control the "velocity" of drum instruments, and it's cheap as well! ;; We expect following connections: ;; ;; DOUT ca. 160k ;; D7 ---o---/\/\/\---* ;; ca. 80k | ;; D6 ---o---/\/\/\---* ;; ca. 40k | ;; D5 ---o---/\/\/\---* ;; ca. 20k | ;; D4 ---o---/\/\/\---* ;; ca. 10k | ;; D3 ---o---/\/\/\---* ;; ca. 5k | ;; D2 ---o---/\/\/\---*----o CV Out ;; 220 Ohm ;; D1 ---o---/\/\/\--------o free assignable trigger ;; 220 Ohm ;; D0 ---o---/\/\/\--------o another free assignable trigger ;; ;; The DOUTx channels are matching with the AOUT channels as specified in the DEFAULT_TRKINFO table above. ;; Allowed values: 1-16 (selects DOUT shift register) or 0 to disable ;; Ensure that DEFAULT_NUMBER_SR is high enough so that all DOUTs are updated. #define DEFAULT_CV_DOUT_SR1 4 #define DEFAULT_CV_DOUT_SR2 5 #define DEFAULT_CV_DOUT_SR3 6 #define DEFAULT_CV_DOUT_SR4 7 #define DEFAULT_CV_DOUT_SR5 8 #define DEFAULT_CV_DOUT_SR6 9 #define DEFAULT_CV_DOUT_SR7 10 #define DEFAULT_CV_DOUT_SR8 11 #define DEFAULT_CV_DOUT_SR9 12 #define DEFAULT_CV_DOUT_SR10 13 #define DEFAULT_CV_DOUT_SR11 14 #define DEFAULT_CV_DOUT_SR12 15 #define DEFAULT_CV_DOUT_SR13 16 #define DEFAULT_CV_DOUT_SR14 0 #define DEFAULT_CV_DOUT_SR15 0 #define DEFAULT_CV_DOUT_SR16 0 [/code] Note: more than 16 DOUTs are not (and will never be) supported. 3 DOUTs are used for the 16 GP LEDs + 8 status LEDs. Means: only 13 are really free for velocity outputs... and the PCB has 11 of them! On the other hand, instruments like Open/Closed HH can simply share the same velocity, as they are (normally) not played concurrently. Best Regards, Thorsten.

406 x 81 mm Best Regards, Thorsten.

The MBFM firmware doesn't allow to shift CCs by 1, because sometimes logical operations such as ">>2" or "&3" are used to determine the parameter type and operator number! The only way I see would be to move all 4 OP Attack parameters to an unused range which is dividable by 4, such as 0x34..0x37 0x2b is the correct value. I fixed this and upoaded a new version to the Device Database Not required, it would be more helpful if you would describe the errors so that I can doublecheck if your assumption is correct and do the actual change on the "master panel" which will be uploaded to the device database. Especially since you are doing changes which will only work with your modified firmware (CC moved to different location), your uploaded panel would only confuse people and lead to unnecessary "bug reports" Best Regards, Thorsten.

Yes, the PIC is mounted at the backside of the PCB - thanks to the layout work of kogz23! :thumbsup: It includes everything that you need to get a MIDI + CV drum sequencer running! Current state: sequencer is working, but I've to reorganize some parts of the firmware to allow control over velocity from the "accent track #16" (known from the 808 handling). The firmware wasn't prepared to handle accent *before* MIDI (and CV) events are generated... I hope that I will find an elegant solution. Best Regards, Thorsten.

Junge, wir verstehen uns einfach nicht... ;-) Best Regards, Thorsten.

The documentation at ucapps won't really help you on such issues with a customized firmware. Maybe Wilba can jump in here? Best Regards, Thorsten.

Open the Lua source code viewer, select the "receiveMIDI" tab. It shows you a program that I wrote to map incoming SysEx data to the controllers. This part is relevant for the Attack controllers: assignModulator(mem_block:getByte(0x20), "OP1Attack") assignModulator(mem_block:getByte(0x21), "OP2Attack") [/code] as you can see (when you read & (!) understand the code a little bit more), the controller name is relevant. So: your experiment will work if you change the controller names in these function calls as well. Best Regards, Thorsten.

Gut versteckt (und falsche Keywords verwendet... ;-) Ich revidiere meine Aussage - es ist wohl doch "Expertenwissen" notwendig (und dabei habe mit extrem viel Aufwand versucht, die .hex Generierung so einfach wie moeglich zu machen... die detailierten Infoseiten sind jedoch alle auf Englisch, und wie Du bereits schriebst, helfen sie Dir nicht weiter. Andererseits habe ich keine Zeit, zwei Seiten fuer solche "Kleinigkeiten" zu pflegen) Hier eine speziell fuer Dich generierte Release. Ich druecke die Daumen, dass ich nichts vergessen habe: http://www.ucapps.de/tmp/midibox_fm_v1_4d_for_thomasch.zip -> in setup_pic18f4685_mbfm_v1.asm wurde MIOS_ENC_MODE_DETENTED3 selektiert. Gruss, Thorsten.

Thats probably the reason why nobody noticed this typo before. yes, the LEDs are a bit brighter without the 220 Ohm resistor connected to the cathodes (because 220 Ohm resistors are already connected to the anodes) Best Regards, Thorsten.