TK.

Hi Dan, ok: MIOS is running, it has been configured for a graphical LCD and you see a black screen (means black pixels or just nothing?). So the error must be a missing or bad connection. Best Regards, Thorsten.

Now this issue has been discussed here: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1048075587 Best Regards, Thorsten.

remember that there are still some undocumented features... ;-) Best Regards, Thorsten.

Hi Dan, Not really. The din_touchsensors circuit is just a button replacement. It delivers an active signal to the MIDIbox when your fingers touch the TS contact (therefore it could also be used for other purposes - how about a panel full of touch sensors which trigger different notes or controller message when you touch it? ;-). But the touch sensor function which is meant here is a function which suspends the faders - it has already been implemented in MB MF and MIOS of course. I guess that I have to give a better oversight: the suspend function disables the motor and brings the MF driver into a state which ignores all incoming repositioning commands for the appr. fader until the suspend function has been disabled again the suspend can be triggered by touch sensors or by dedicated buttons for each fader or by one button for all faders host programs like Logic, Cubase and Nuendo provide an additional functionallity for the automation, called "touch" mode, which suppress repositioning events for a certain time (mostly about 200 ms) when it receives a fader event the MF driver stops the motor automatically when it regognizes that the fader is moved manually. But this detection requires some force (for about 100 ms) which isn't good for the lifetime of the motorfader additionally the host application can receive touchsensor events which also disable outgoing repositioning commands. Sometimes these events are used for additional functions, e.g. Logic provides the possibility to select a channel when you touch a fader. Conclusion: if faders with integrated touch track are available, the use of the touch sensor unit allows to send additional commands to the host application for a proper and lifetime saving automation If the fader doesn't come with a touch track, you can either hope that the automatic suspend saves your fader from damage (however, it isn't sooo dangerous, the fader should should work for some years in this way...), or you could use one button to suspend all faders, or 8 buttons to suspend the faders seperately when necessary. Best Regards, Thorsten.

Hi Amando, Great! I'm looking forward to a new contribution for the MIDIbox extensions page! :) Best Regards, Thorsten.

If the vinyl interface outputs the so called "quadrature code", it wouldn't be a problem for MIOS to handle the apparatus like a rotary encoder. Otherwise a selfwritten decoding routine has to be attached to USER_SR_Service_Finish Best Regards, Thorsten.

Sure, that are nearly no limits! :) But keep in mind that you have to program the control software by yourself. I'm only able to provide example codes (more are coming soon, also for multichip setups!) and some applications which are used by myself. And I can give a couple of tips, how to solve particular implementation problems with MIOS... but everything else has to be done by people who at last build the hardware. Best Regards, Thorsten.

Hi Thomas, thanks for the feedback! :) Btw.: Greg's PCB is still compatible to MIOS, you only have to replace the crystal and the PIC. And you have to add Pull-Up resistors to the end of the 74HC165 chain - thats all :) Best Regards, Thorsten.

Most PIC controllers contain only one UART which can be used as a MIDI interface. Alternative DIY friendly chips are hard to find and require different programming (=burner) and development tools. A solution could be a board with 8 smaller PIC derivatives (i.E the 16F627), which are attached to a parallel bus for an uncomplicated and fast exchange of MIDI messages. However, if somebody builds me such a board (based on my schematic) I would be able to realize the appr. firmware very quickly. But so long as I have to build the board by myself, it could take much longer (due to higher priority tasks ;-)) Best Regards, Thorsten.

short answers: 1) the motorfader handler provides a timeout mechanism which acts like a software implemented fadertouch. Better solution is the use of "MIOS_MF_SuspendEnable" function which can be used to stop a fader immediately. It could be triggered by a button - it saves the live of your faders 2 & 3) no problem to integrate two seperate tables for IO instead of the one in mios_tables.inc. It's also no problem to provide an alternative table for a second layer. I will release a new version tomorrow. It will also contain Alex's display mod. And it will provide the possibility to switch between different display pages without reloading the application. 4) as you can see in lc_mproc.inc and lc_display.inc functions which display custom texts on sysex, CC and note messages (like MTC digits, display of strings on LED events, or Rec/Solo/Mono status displayed as 8 characters) are already provided. However, I will provide no solution which parses incoming LCD strings and extracts values or whatever, because there are too much possible variations (once you've played with the emulation, you will know why ;-)). It's not really useful Best Regards, Thorsten.

Hi Dan, important question: did you wire the graphical LCD based on the updated schematic? Because I changed one connection before the final MIOS release. A simple way to test if the ID has been set correctly is the use of the (undocumented *sigh*) debug message which allows you to call a MIOS function from external. So, when you send: F0 00 00 7E 40 00 0D 01 00 5A 44 00 00 00 00 00 00 00 00 F7 the "MIOS_LCD_TypeGet" function will be executed. The return parameters will be sent back by the MIDIbox: F0 00 00 7E 40 00 0F 00 00 00 00 00 00 00 00 F7 if a character LCD has been initialized F0 00 00 7E 40 00 0F 00 01 00 01 00 00 00 00 F7 if a graphical LCD has been initialized. It's also possible to setup a graphical display after startup by modifiying the init function in lc_init.inc Just add:     movlw  0x01     call   MIOS_LCD_TypeSet at the beginning Best Regards, Thorsten.

The simplest program is the Tx Test: http://www.ucapps.de/howtodebug/test_tx.hex.zip You can connect a LED + 220 Ohms resistor between the Tx pin and ground in order to ensure that the PIC is working (note that the LED has a certain polarity, so just try both directions) Best Regards, Thorsten.

Hi Matteo, oh - I overclocked the chips with 20 MHz and noticed no failures (I had luck!). But ok, so I have to search for another useful job for the chips. Maybe I should build even more SID units ;-) Best Regards, Thorsten.

I'm not sure, the new derivatives could be released in some weeks, or in some months... however, I'm not under time pressure ;-) There will be several pinouts available, one with a small number of pins, and other chips in a 40 pin DIP package like the PIC18F452. But unfortunately 3 pins are allocated by the USB interface itself (the pins which are currently used to serve the DIN/DOUT modules), so that I would prefer the first solution: a small, simple & cheap USB module --- all other solutions would increase my support and documentation effort a lot... Best Regards, Thorsten.

Hi Thomas, fine to hear from you again! :) Sure, MIOS already provides multicore capabilities, but only in one direction (unidirectional). After I noticed that bidirectional transfers lead to a high CPU load and would require additional hardware, I came to the conclusion that the already implemented "MIDibox Link" feature (see Concepts->MIDIbox Link) is sufficient for a "big MIDI system" I just have added some more infos to the page (since this question has been asked several times). Here an excerpt (however, the complete answer could fill a book ;-) "If a big MIDI system with a complete menu navigation for multiple cores should be realized, the use of MIOS is highly recommented, since this operating system is much more flexible compared to the old PIC16F firmwares. Here a possible solution: The first core provides the menu navigation interface. It sends control messages to the last core which handles with the output elements like LCD, LEDs, LED digits. Other core modules between the first and the last one can insert additional output messages into the MIDI stream if necessary. Optionally, the first core could convert incoming MIDI events to control messages and send them to the other cores in order to access the soft-overtake function of pots, to move motorfaders, to change the patterns of LED rings directly. It could also send messages which assign MIDI events to pots/faders/encoders. In this manner, several setups (banks...) can be managed by a single core to reduce the programming effort." Best Regards, Thorsten.

They are connected to the common DOUT chain Best Regards, Thorsten.

FYI: MBHP Projects -> MIDIbox SID -> Control Unit Btw.: the menu navigation has been implemented on a way which allows to reuse the code for other synthesizers. Maybe I should release a "MIDIbox TC V2" with a prepared menu structure for some favourite VST instruments. :) Best Regards, Thorsten.

Hallo, na da laeuft ja wirklich schon ziemlich viel! Super! :) ja, die ungenutzten analogen Eingaenge sollten auf Masse gelegt werden, ansonsten wird die Firmware permanent MIDI-Daten senden, weil die Spannung an den an den Pins quasi "undefiniert" ist und sich dadurch immer wieder Werteaenderungen ergeben, die von der MIDIbox dann brav weitervermittelt werden. Nach Deiner Beschreibung wuerde ich aber vermuten, dass entweder die Potis oder die AIN module nicht richtig angeschlossen sind. Am besten ueberpruefst Du mal mit einem Messgeraet, ob vielleicht einer der Masse/+5V Anschluesse der Potis und AINs keine Verbindung zur Versorgungsspannung hat. Visuell kann man das natuerlich auch checken, aber das dauert meistens laenger ;-) Gruss, Thorsten.

Hi, the LEDs can be accessed by the same events which have been assigned to the buttons. Unfortunately it isn't possible to control them by alternative MIDI messages, unless you are using a BankStick (in this case the LED events are always the events which have been stored in internal memory), or the MIDIO128 firmware --- or MIOS of course ;-) Best Regards, Thorsten.

Hi Dan, it seems that I've removed this pdf by fault - also on my harddisc :-( So it could take some days until I find the time to create the diagram once more. However, the required interconnections can already be found in the MF schematic. The simplest test program for the MF module is the "mf_calibration" application. Touch sensors: I don't own panasonic faders, therefore I cannot say if there is a solution Best Regards, Thorsten.

Yes, thats a good tip. It seems that there is an soldering error in the power supply section. Under http://www.ucapps.de/howtodebug/test_tx.hex.zip you will find a test program which just sends a MIDI event every second. Best Regards, Thorsten.

It's a great pity! :-( If you own a C64, you could test the SID with the computer, otherwise I see no chance without a PIC. However, when I look into my shelf which is full of electronical components I see a lot of PIC16F877-04 which I got as samples from a german distributor. He sent me the 4 MHz version by fault but never wanted them back. I used two of them some weeks for my SID modules (overclocked!), but now I've replaced them by PIC18F452. Since I've no use for these PIC16F chips anymore, I could give you one for free, just email your postal address :) In the meantime you should try to find the root cause for this failure, so that it never happens again! Best Regards, Thorsten.

In the meantime I noticed that the DIP version of this chip has been discontinued. It seems also that the availability is not so good as expected (see the http://www.findchips.com results). But at the Beyond Logic page a short introduction about an upcoming PIC18F device with integrated USB support can be found - well, this will be the solution! :) The USB interface allocates some pins which are used by the core module for other functions, but at least a "MBHP USB" module just only for the data transfer (and maybe also as reduced MIDIbox core) could be created. Estimated price: about 15 Euros! :) Now we only have to wait for the release of the PIC18F2450 . There is already a firmware available for this derivative, which can be extended for MIDI transfer very easily! Best Regards, Thorsten.

Well, how about a code generator which generates the PIC assembly instructions which are necessary to map and process data streams. Could also be provided with a graphical user interface. But this won't be my job (too much effort) Best Regards, Thorsten.

Hi Dan, Currently this option isn't supported, therefore you have to connect the MIDI INs of the other SIDs to J11:MI and J11:Vs As soon as the "through" option is available, the slave SIDs have to be connected to J11:MO instead so that the control surface is able to insert additional events. Please don't start with the panel before I've finished my own panel (I will begin in 1-2 weeks). I don't expect problems, but if I notice that the handling could be improved by adding more buttons (or encoders/pots), the layout could be completely changed. Yes, definitively! I just have finished "Step A" of the control surface (see download section, documentation will follow this evening). It's so flexible, that every parameter (also wavetables!) can be edited by using some buttons and an optional rotary encoder (for faster data entry). It supports 2x16, 2x20, 2x40 LCDs w/o loss of any possibilities Everything else will be optional stuff for an improved direct access to the parameters. Best Regards, Thorsten.