TK.

this USB-MIDI driver is obsolete and doesn't work with the current Linux version, the update has been partly integrated into the kernel, partly into ALSA... I will write something about the required installation steps so soon as I've some time (my own Linux installation is fairly old, I've to update the kernel, some libraries, etc. to get ALSA 0.9.3 or 0.9.4 running..). Best Regards, Thorsten.

Hi Elliot, yes, a rotary encoder allocates 2 DIN pins, therefore "only" 64 encoders can be handled by one core module. In parallel this core could also handle 8 motorfaders or 64 non-motorized faders by using 2 AINX4 modules. However, this isn't your requirement. So, some words to the mutlicore-solution: maybe the port of MB64 will simplify the realization of a solution like discusses here: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1047922838 but so long as I haven't started with this work I cannot provide further details. And please also keep in mind that for a complete customization you need to learn PIC programming in order to modify the application for your needs. The 128 DIN/128 DOUT/64 AIN application is one of the most stable ones ;-) The encoder driver has been improved in MIOS V1.3 (additional speed modes, release maybe tomorrow) The MF driver runs fine with Alps motorfaders, but currently it's unclear if it runs as well with panasonic faders. Best Regards, Thorsten.

The MPU401 input is still mapped to the MPU401 output, you have to delete this routing (right-click on the entry -> delete) Best Regards, Thorsten.

Do you have the 13.2V during programming now, or only during reading? Don't try to increase the voltage above this level, it could destroy the PIC. If it still doesn't work, it's maybe a good idea to try the programmer on another PC (time to visit a friend... ;-) Best Regards, Thorsten.

During programming I get 13.2V, so it seems that the voltage of the titanium programmer is not high enough. If the hardware is similar to the JDM, you are maybe able to adapt the resistor/diode values? However, this wouldn't be a "quick" solution. I've no other idea... Best Regards, Thorsten.

Hi Robin, ok, the keyboard test showed that the input port is mapped to the output port. This is some kind of internal feedback which definitely disturbs the upload. So, go into the Options->MIDI Devices menu, disable the "automatically attach inputs to outputs" switch, open the port map of the MIDI out and remove the MIDI In from this map. This should (hopefully) help :) Best Regards, Thorsten.

Hi Dan, no there isn't an application available for testing the MTC display - just wait some days until I've finished the SID CS... ;-) 2nd core: sure, this works. Just upload the MIDIbox LC application with a different configuration into the second core. Only the MIDI In of this core has to be connected in this case. The GPC option is only an immediate solution, the final one will be more powerfull. It allows you to send up to 128 CC's to another program, i.E to Reaktor. You will see 8 CCs on the display when entering this mode, they can be controlled by the 8 V-pots. With the Jog-Wheel you are able to shift the "V-pot window" to the other CC's. However, the final GPC mode will also support the Motorfaders, customized strings and customized MIDI events. Best Regards, Thorsten.

Alright Robin, thanks for the logfile! So it seems that the bootloader receives anything, but it never returns an acknowledge. Such a behaviour could be related to a MIDI-Ox setup or MIDI driver problem (e.g. the USB-MIDI driver from Microsoft corrupts also the messages if the buffer size is smaller than the SysEx string). Could you please try following settings (SysEx configuration menu of MIDI-Ox): Low Level Output Buffer Size: 2048 Low Level Output Buffer Num: 32 Delay after F7: 750 ms (just to ensure, you could also increase this delay, but 750 ms should work ok) Another usefull test: connect the MIDI-Out of your PC with the MIDI-In (feeback loop). Load a .syx file and start the "Send/Receive" function under "Command Window->Send/Receive SysEx". The number of received bytes should match with the number of transmitted bytes. If this value doesn't match, the driver of your MIDI interface defenitely has a bug (for which the increased buffer size could be a workaround) Best Regards, Thorsten.

You wrote that a copyright message appears, thereafter the PIC will be reset. Is this still the case? This would mean that you were able to upload MIOS itself once. It would be interesting for me, if the complete OS has been uploaded, means: I want to see all the "acknowledge" messages which are sent during the upload of the operating system. You will not be able to upload an application if MIOS is not complete, e.g. because of an error during the first upload procedure (this could also explain why the PIC will be reset) Ok, so just try the MIOS upload again. If this doesn't work anymore, you've possibly problems with the MIDI-In connection (from the Rx pin of the PIC to the MIDI-In of your PC) - in this case I can give you some more infos, how to debug the hardware... Best Regards, Thorsten.

Update: I just have integrated a new function into MIOS which allows to set the "startup speed". Just another value which can be tweaked ;-) Resulting from this possibility, the Up/Down speed can now be decreased to 0x03 (before the change it was 0x10). The Faders are starting faster now, but they are reaching the target position more smoothly. Now I will integrate a calibration menu into the LC application so that the values can be optimized in direct interaction with the host software. :) Best Regards, Thorsten.

I haven't asked for the MRST# voltage without a reason ;-) The measuring result would be interesting, because it would show if it makes sense to improve this voltage for the PIC18F. The Note and CC events can only be assigned with computer, a keyboard or another MIDI controller - sorry. :-/ Best Regards, Thorsten.

Thats a very interesting input! It makes sense to increase the PWM voltage level for the first miliseconds when the fader starts to move. I will try this on the driver side Best Regards, Thorsten.

> Will there be a chance for a driver update someday? > Especially the multiclient thing is not so good for me... This isn't in my hand, the Microsoft driver isn't multiclient capable... However, if somebody has experiences in writing an own USB driver for the OS site, he is welcome for doing this! Best Regards, Thorsten.

Stealth mode? Hm.... maybe too much coffee ;-) The results given by the monitor are showing that you've no jitter on the AIN lines, this is very good! This means also that you can decrease the AIN deadband to 1, and the MF deadband to 3 or higher (but I think that you've already tried this). But it makes sense to use these settings and to vary only the motorfader voltage AND the calibration value (motor speed) for upward and downward movements. Maybe I should integrate the calibration feature also into  the LC application so that you are able to start some experiments with the settings without reburning the PIC. Best Regards, Thorsten. P.S.: the described effect (fader stops ca. 4 mm beside of the target position) means that the faders are too fast, so that they never reach the exact position. A timeout will happen after 5 retries, thereafter the MF driver will send the "real" position. You can slow down the fader with a lower MF module voltage and with the Up/Down calibration value.

Alright, did you also try the "Windows API" setting. And which voltage level do you measure at the MRST# pin during programming? Note that you can increase/decrease this level with the I/O delay, maybe this already helps Best Regards, Thorsten.

Could you please make some snapshots of your IC-Prog configuration and post it here (or just send me the snapshots via Email) Sure, you can also use the MBPlus to control the SID. The CC table can be found here: http://www.ucapps.de/midibox_sid/sid_cc_implementation_chart.txt Best Regards, Thorsten.

-> http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=mios;action=display;num=1055947907

Ok, switching to the Gameport.... no, it isn't possible to change the default baudrate without reburning the PIC, it can be changed from the Application, but since the upload doesn't work.... however - now it's maybe better if you would check the Rx/Tx line of your Gameport first just to ensure that MIDI-Ox has been configured correctly. Desolder the MIDIbox connections from the Gameport plug and solder the Tx pin to the Rx pin so that you have a feedback loop. Start MIDI-Ox, send a MIDI-Event (e.g. with the virtual keyboard). You should see the outgoing as well as the incoming MIDI event on the screen. If not, please post your MIDI-Ox configuration here (the port setup) - and maybe also the SysEx configuration (hope that you've set the delay between two F7 to 750 ms?) Best Regards, Thorsten.

Hallo Jimy, Du kannst das Core Modul dazu hernehmen, das Layout findest Du unter Concepts->MBHP->Core Module, eine fertige Leiterplatte gibt es unter http://www.mikes-elektronikseite.de fuer 6.50 EUR Gruss, Thorsten.

Na immerhin sind die genialen KS0108 GLCDs noch erhaeltlich - wie lange hast Du gebraucht, um den Distributor zu finden? Kannst Du mir das .pdf mal zuschicken? Ich wuerde mir gerne das Pinout ueberpruefen bevor Du bestellst. Gruss, Thorsten.

A very clean setup! :) No, the bootstrap loader isn't the problem. I guess that the application fails since the open analog pins are not connected to ground. Did you also try another application, for example the DOUT test, just to check if anything is running ok? Which messages appear during the MIOS upload, do you see any "...0E xx F7" error message? Regarding the MB64 application: see http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=mios;action=display;num=1055947907 Since the SID control surface is nearly finished, it cannot get that long ;-) Best Regards, Thorsten. P.S.: are you able to increase the input voltage to the core module? Maybe the backlight consumes too much power that Vdd sinks below 5V and the PIC will be reset!

Hi Sephult, the 2*40 display is a common CLCD (character LCD) which requires no additional configuration. Just use the default type (0x00) and it should work :) Best Regards, Thorsten.

Hi Dan, > > External Meters: will work in exactly the same way like the LED rings, > > so you could change LEDRINGS_SR_CATHODES and *_ANODES_* setting to > > test the LEDs > change these to what? I just wired them up as described for the led > rings pdf...i hope that was right Shocked... yes, this was correct. The midibox_lc application allows you to specify where these shift registers are located. Just take a look into the main.asm file of midibox_lc > So the 4th register would have 4 brdiges and 4 resistors stuffed for an > additionl 4 LED inputs right? yep! > Can i use the spare inputs on the shift registers used on the LED meter > rings for the MTC display digits, or just a regualr LED assigned to a LC function? Would be cool, but I cannot support the shifting of multiplexed pins as a general solution, such a flexible routine would cost a lot of performance. However, after I've implemented this stuff, I could tell you how to modify the firmware so that the anodes/cathodes pins can be assigned to any pin (hardcoded solution). Best Regards, Thorsten.

Hi Pearl, yes, you have to solder all power pins, in most cases they are not connected together (unfortunately!). I will send the PCB to Mike next week when he is back from vacation. Note for people outside germany: the PCB can also be ordered from SmashTV from the US for about US $7 (Tim: please correct me if I'm wrong)! He made the PCB layout and only his board will have the DIY friendly laser print (the part names and outlines are printed at the top side) Best Regards, Thorsten.

Mike is currently on vacation, but I will ask him next week. Btw.: the PCB layout has been created by SmashTV - thanks a lot!!! :-) And of course, you can also order the board from him (he should be back on friday) Best Regards, Thorsten.