TK.

A very impressive layout :) Just a note: the touch sensors require an additional DIN shift register which can be connected at the end of the last DINX4 To the box layout: I would add at least one dedicated button for MIDIbox LC specific functions. Currently following functions are supported (see lc_io_table.inc): #define ID_MBLC_DISPLAY_PAGE0 0x80 ; switch to page 0 #define ID_MBLC_DISPLAY_PAGE1 0x81 ; switch to page 1 #define ID_MBLC_DISPLAY_PAGE2 0x82 ; switch to page 2 #define ID_MBLC_DISPLAY_PAGE3 0x83 ; switch to page 3 #define ID_MBLC_DISPLAY_NEXT 0x84 ; switch to next page #define ID_MBLC_SWITCH_LAYER0 0x90 ; switch to layer 0 (like radiobutton) #define ID_MBLC_SWITCH_LAYER1 0x91 ; switch to layer 1 (like radiobutton) #define ID_MBLC_TOGGLE_LAYER 0x92 ; like a "caps lock" key #define ID_MBLC_HOLD_LAYER 0x93 ; like a common "shift" key #define ID_MBLC_SWITCH_LEDMETER0 0x98 ; ledrings are working as normal #define ID_MBLC_SWITCH_LEDMETER1 0x99 ; ledrings are working as meters #define ID_MBLC_TOGGLE_LEDMETER 0x9a ; like a "caps lock" key #define ID_MBLC_HOLD_LEDMETER 0x9b ; like a common "shift" key just pick your favourite behaviour. I think at least a shift button with "hold" function should be used, this enables you to switch the LEDs and all other buttons (in later versions also the encoders and motorfaders) to an alternative layer. Best Regards, Thorsten,.

Hi Dan, this is one of the good ones - as you can see in the datasheet: it stores the pixels vertically. The command set is compatible, so it should work with GLCD mode 1 w/o problems. Would be great if you could ensure this :) 2) yes, this has to be programmed. No problem with MIOS so far, but requires some skills 3) if you want to use it as second GLCD: yes, a second core. For MIDIbox Link just connect the grounds together and MO of the "master core" to the MI of the "slave core". Thereafter the "master core" (your MIDIbox LC) can send special SysEx strings or similar to control the second GLCD via remote (but here again: implementation is easy - routine has to be inserted into the MIDI processor handler - but requires programming skills) 4) no, you would have to program an additional layer Best Regards, Thorsten.

not really, but for myself it's some kind of sport to get it running ;-) It's still usefull for applications which are more relaxed on timings. Best Regards, Thorsten.

Ok, der Optokoppler wird mit Spannung versorgt, aber liefert kein Signal. Nun mal die andere Seite testen: Die LED sollte nun nur dann leuchten, wenn MIDI-Daten empfangen werden. Je hoeher die Datendichte, desto heller. Falls sie nicht leuchtet, solltest Du nochmal die Polung der Diode vor dem Optokoppler ueberpruefen. Falls sich dann immer noch nichts tut, hilft vielleicht noch folgender Trick um die Funktion des MIDI-Interfaces am PC sicherzustellen: schliesse einfach den MIDI-Out an den MIDI-In (Feedback-Schleife) und sende mit MIDI-Ox ein beliebiges MIDI-Event (bspw. das virtuelle Keyboard aktivieren). MIDI-Ox sollte das Event anschliessend sowohl im Output, als auch im Input-Fenster anzeigen. Gruss, Thorsten.

Hallo Johannes, hast Du zufaellig eine LED zur Hand? Damit koenntest Du das MIDI-In Signal direkt am PIC testen: Fuer diesen Test loetest Du am besten zwei Kabel an die Unterseite des Core Moduls. Die LED sollte immer aufleuchten (Polung beachten: das kurze Beinchen ist die Kathode und muss ueber den Vorwiderstand an Vss angeschlossen werden). Solange nur vereinzelte MIDI-Events empfangen werden, tut sich nicht viel, bei einem laengeren SysEx Stream sollte die LED jedoch merkbar flackern. Solange die LED direkt am Rx Pin angeschlossen ist, wird der PIC uebrigens keine MIDI-Daten erkennen (die LED verbraucht zuviel Strom), aber Du kannst auf diese Weise feststellen, ob die Verbindungen zwischen dem MIDI-In Port und dem Rx Pin ok sind. Falls die LED nicht aufleuchtet, koenntest Du das Signal auch mal am Optokoppler ueberpruefen (Pin IC2:6). Falls da nichts rauskommt, ueberpruefe Pin IC2:8 (den +5V Eingang des Optokopplers - vielleicht kommt die Versorgungsspannung nicht an) Gruss, Thorsten.

The reason why I haven't started with a public PayPal account yet is that I want to prevent that people transfer much money to my account in the hope that I would do some individual extra work for them (developing a customized hardware or something similar). Sometimes it's really difficult to explain them that I only want to realize things which are interesting for myself, which brings the running projects forward and which helps me to improve my knowledge about electronic and software development. I guess that most of the people who are working on free stuff are thinking the same. The MIDIbox projects are just my personal contribution to the public domain, my "thank you" for the free stuff which I'm using for my own work. However, donations... hmmmm.... maybe somebody of you know the good old days before internet when public domain names requested to send them postcards. It would be nice to see some pictures of the country/state/city/township from where you are coming from. I'm also very happy with CDs from your own music or from your favourite artist (I remember: Steven started with it some months ago, and in the meantime I own a nice collection of special CDs, donated by MIDIbox users, which I mostly hear during my tinkering sessions :)) Best Regards, Thorsten.

Hallo Johannes, wie sieht denn Dein Powerswitch aus? Hast Du dafuer eine Bestellnummer? Mich wuerde es auch mal interessieren, wie man mit einem Schalter ein Netzteil ueberfordern kann. Zum MIOS upload: bei einem jungfraeulichen Chip ist es normal, dass der "Request for Upload" String alle 2 Sekunden gesendet wird. Waehrend des Uploads sollten jedoch Acknowledges erscheinen. Vermutlich ist der MIDI-In nicht richtig angeschlossen (polung pruefen) Gruss, Thorsten.

danach habe ich bisher leider auch vergeblich gesucht :-/ Gruss, Thorsten.

Hallo Sebastian, die Zuordnung ergibt sich aus der Reihenfolge in der die Shiftregister "verkettet" wurden. Das erste SR, das direkt am Core angeschlossen ist, ist also Nummer 1, das naechste Nummer 2, etc. Gruss, Thorsten.

Hi Steve, yes, should work. By default both CLCDs are enabled in main.asm: #define LCD_USE_SECOND 1 ; the emulation handles with two character LCDs if 1 Best Regards, Thorsten.

Fine :) But what was the reason for the failure? Best Regards, Thorsten.

Hi Gilles, the program change event is the right one to change to another patch. Are you sure that the BankStick has been connected properly? (You will hear a short tune when it is regognized by the MBSID). If the BankStick is not available, every patch number will point to the internal EEPROM (-> to a single patch) Best Regards, Thorsten.

Yes, it is :) Best Regards, Thorsten.

Hi Ian, I'm not sure about the max. PPR rate, it's hard to create an equation that estimates this value, as it depends on different parameters: rotation speed, axis size, pulse width... the only spec that I can give you is that MIOS is able to sample for transitions every microsecond (-> specified with MIOS_SRIO_UpdateFrqSet). However, from my experience rotary encoders which are specified with up to 36 PPR are working w/o problems. I haven't tested "faster" encoders yet. (Note the the resolution will be doubled by the driver to 72 PPR) to the encoder order: at least the prices would be interesting. :) Best Regards, Thorsten.

Yes, KS0108 based GLCDs are already supported, the T6963C controller will be available with MIOS V1.2 --- but the performance of this driver will be very poor. The reason for this is the fact that the T6963C stores the graphical data in horizontal lines and not in vertical lines. This makes it necessary to rotate the fonts by 90° via bitmapping. E.g., for 4x8 chars which are used by the LC emulation, 32 bits have to be copied before the final character can be copied into the LCD memory via Read-Modify-Write. For a KS0108 based display the driver just only have to transfer 4 bytes to the display. So: T6963C controllers are cheap, but not really usefull. I haven't tested yet if the complete LC emulation can already run with only one core module when this GLCD is used. Maybe two cores are required for this configuration. Best Regards, Thorsten.

Yesterday I received the AN2131SC and like every time I couldn't resist to test the chip without creating a PCB. However, this time it was a little bit difficult - soldering SMD on a breadboard doesn't make fun. But finally I was able to create some kind of carrier board with a lot of cables: (it looks like a neuronal experiment ;-)) Some additional logic was necessary for the voltage conversion, the MIDI In/Out ports and LEDs: But this was enough to develop the EZ-USB firmware. After some hours and 100 windows crashes: ...the MIDI ports have been regognized by Windows as "USB-Audioger#t" (USB Audio Device). Unfortunately the M$ driver doesn't allow me to change this name. However, the performance is cool (< 1 ms latency) and I noticed no buffer overruns yet. Hopefully the firmware will also work with other windows versions --- this will be a challenge :-/ Best Regards, Thorsten.

one better than the other... well done! :) Good that you have already some place on the right upper corner. The PIC18F release will support 3 additional rotary encoders for data/menu entry, BPM and pattern selection ;-) Best Regards, Thorsten.

Ich habe zwar gerade per EMail geantwortet, hier aber nochmal eine erweiterte Antwort fuer die Allgemeinheit zum Thema MIDI-Interfaces: wie bereits Sly vorgeschlagen hat, macht es Sinn, hierfuer ein kommerzielles Interface zu verwenden. Unter Windows ist die Treiberankopplung (leider) nicht ganz trivial, weil Microsoft quasi mit jeder neuen Windows-Version bewaehrte Konzepte ueber den Haufen geschmissen hat, deshalb habe ich bisher meine Finger von Eigenbauinterfaces gelassen (den Stress tue ich mir nicht an...). Ein kleiner Lichtblick ist zumindest das USB-MIDI Protokoll, zwar hat Microsoft auch bei dieser Umsetzung mal wieder Mist gebaut (darueber moechte ich mich lieber nicht weiter auslassen, weil die Bugs einfach nur aergerlich sind ;-)) aber die Workarounds habe ich mittlerweile herausgefunden. Nachteil: USB ist nur mit einem SMD-Chip moeglich, und der ist sehr schwierig zu verloeten... Deshalb: wuerde ich Dir raten, fuer Dein Laptop ein USB-MIDI Interface zu kaufen. Das beste Preis/Leistungsverhaeltnis bietet MIDIman mit dem "MIDIsport" Interface, bspw. "MIDIsport UNO" fuer ca. 50 EUR neu. Dieses Interface gibt es gerade bei EBay fuer 23 EUR... Zusaetzliche Ratschlaege: wer mit einem "richtigen" PC arbeitet, ist fein raus. Mit jedem Gameport steht ein MIDI-IO-Port zur Verfuegung. Schaltplaene fuer dien notwendigen Adapter gibt es auf meiner FAQ Seite. Aufpassen bei kommerziellen Adaptern: manchmal wird am Optokoppler gespart, so dass sie nicht mit jedem MIDI-Geraet problemlos zusammenarbeiten. Ausserdem koennen so haessliche Brummschleifen entstehen, deshalb wuerde ich einen Selbstbauadapter immer gegenueber der kommerziellen Variante vorziehen. Wer mehrere MIDI IOs benoetigt und noch ein freie Steckplaetze zur Verfuegung hat, kauft sich einfach ein paar zusaetzliche Soundkarten (bei EBay ab 1 EUR) Doch die Gameport-IOs haben auch einen Nachteil: der Standard-Microsoft-Treiber ist leider nicht Multiclient-faehig. Das bedeutet, dass nur eine MIDI-Applikation zur gleichen Zeit auf den Port zugreifen kann, fuer die anderen ist der entspr. Port dann gesperrt. Besonders unpraktisch ist das im Zusammenhang mit dem MIDIbox SID Editor, den man normalerweise parallel zum MIDI-Sequenzer betreiben moechte. Mit den Gameport-Treibern funktioniert das nicht. Abhilfe: seit mindestens 10 Jahren gibt es "Hubis Feedback Kabel", eine Mini-Applikation, mit der sich die MIDI-IOs virtuell verkabeln lassen. Ausserdem bietet dieses Programm virtuelle MIDI-Ports, die dann auch Multiclient-Faehig sind. Alternativ kann man auch die Kombination MIDI-Ox/MIDI-Yoke verwenden. USB-Interfaces: wer mehrere MIDI-Geraete besitzt, sollte sich lieber gleich ein MIDIsport 2x2 oder groesser zulegen. Die Midiman-Interfaces sind Multiclient-faehig und laufen sehr stabil, deshalb kann ich sie waermstens empfehlen. Fortsetzung folgt, wenn ich erstmal mein eigenes MIDI-Interface auf die Beine gebracht habe ;-) Gruss, Thorsten.

> How were the holidays? too short like every time. But my next holidays are in June ;-) Best Regards, Thorsten.

Step by step 'HowTo's and Walkthroughs written by people who don't see the projects from the technical side are very welcome! Best Regards, Thorsten.

Btw.: the main reason why such features are not provided by the old firmwares are limitations of the PIC16F architecture. The "caller stack" has only a depth of 8, therefore it's very difficult (or dangerous -> buffer overrun) to call "button functions" from a "MIDI function", etc. However, with PIC18F these limitations are much more relaxed. Best Regards, Thorsten.

thanks thanks thanks - but please wait with your praises until I've finished the module ;-) I will get two AN2131SCs in the next days, thereafter I will create the layout for a prototype board, Mike will make the PCBs, afterwards I can begin with the firmware development. This procedure can take some weeks. However, I don't expect problems, since I got an example application running on a (borrowed) evaluation kit from Cypress Sephult: it's not clear to me what you exactly mean. Bank and firmware exchange via MIDI (resp. USB-MIDI) is already possible; Drag and Drop is something which has to be supported at the "other" side (e.g. by a windows application) and this is not my job ;-) The basics are already available - you are able to access the flash, EEPROM and BankStick memory via MIDI Best Regards, Thorsten.

An interesting solution - yes, should work :) Best Regards, Thorsten.

Hi, check also this posting for the planned PIC18F port of MB64seq: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1051052087 I don't think that it is possible to realize a RM1x like sequencer with one PIC, the implementation of such an project would be easier with an old homecomputer (e.g Atari ST), but an analogue style sequencer with the possibility to chain patterns is exactly the MB64seq concept :) How to setup a new MIOS application: learn the PIC assembly language by reading the PIC18F452 datasheet from the Microchip homepage, learn the programming style by studying the existing MIOS examples and applications (there are a lot of comments in the source code which will help to understand the principles). Best Regards, Thorsten.

Yes, 6n8 for the 8580 The descriped method (15 V -> 7809 -> 7805) is a good solution for converting the voltage without much heat Best Regards, Thorsten.