TK.

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.

Hi Etko, the firmware will send a lot of random MIDI events when some inputs are open. See also the FAQ under "What is the minimal configuration for MIDIbox64". Under these circumstances the box won't work correctly. Rule-of-thumb: Every open analog input has to be connected to ground, every open digital input has to be connected via a 10k resistor to +5V Best Regards, Thorsten.

Hi Dendy, it seems that your pots are not connected correctly. Maybe the power lines at the outer pins... check also this schematic: http://www.ucapps.de/mbhp/mbhp_ainx4_64pots.pdf Best Regards, Thorsten.

Hi Pay.c I will check this. Best Regards, Thorsten.

Don't buy these encoders, 5-bit coding is good for developers who want to drive discrete logic with the encoders, but useless for microcontrollers, therefore it is not supported by MIOS. MIOS only supports the common 2-bit coding. Best Regards, Thorsten.

Hi Lo, the LCD solution which is descriped under Concepts->MIDIbox Link->Introduction requires MIOS and the support for remote menu control by the application. Currently this is not natively supported by any application, but it's already possible (by enhancing the source codes) and official support is planned for the future. Best Regards, Thorsten.

Hi Lowrider, for vectorboard a layout is normaly not required, it confuses much more than the original schematic which can be found here: http://www.ucapps.de/midibox/midibox_plus_16.pdf Just mount the components step by step and connect the pins with wires. Additional informations for this method can be found in electronic beginners books, magazines and possibly somewhere in the web. Best Regards, Thorsten.

Hi Sephult, the application will be written in assembly language for the best performance. A C frontend could be possible, but it's not planned yet. However, small modifications in the control surface should be possible without much PIC knowledge, for advanced solutions you need to learn the assembly language (but a MIDI project is a really good starting point for this :)) Best Regards, Thorsten.