TK.

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.

Yes, thanks for the tip! I will try it also :) Best Regards, Thorsten.

thanks! :) Best Regards, Thorsten.

COOL! An USB controller in a handy DIP package with IIC interface (the same protocol which is used by the BankStick) Maybe this is the solution - especially because MIOS already supports IIC. It is possible to connect multiple IIC devices in parallel! MIOS_USB_* :D Best Regards, Thorsten.

Hi Dan, thats ok, the concept allows to load the application also into the MIDIbox LC (or into a PIC18F based MIDIbox64) so that you can control the SIDs from another MIDIbox via remote ;-) Best Regards, Thorsten.

Hi Phil, yes, thats correct. Rotary encoders are now handled like buttons and have to be connected to the J9 DIN chain. Once the DIN pins have been assigned to an encoder, USER_DIN_NotifyToggle will not be called for these pins anymore. USER_ENC_NotifyChange will be called instead. So far as you don't use the AIN multiplexers, a graphical LCD or a SID module, RC0-5 are free. My suggestion is to add the scanning routine to USER_SR_Service_Finish, this routine is called on every update cycle for the DIN/DOUT chain (update period can be lowered to 1 ms). It guarantees that no event get lost. The timer hook could be used for higher sampling periods. Best Regards, Thorsten.

MIOS has a user hook called "USER_DIN_NotifyToggle" which is called on every change. Generating On/Off data is a piece of cake - see the AIN DIN DOUT example :) Best Regards, Thorsten.

thanks SB :) And thanks also for the warning - yes, I was wrong, the I/PT derivative has another package and is not compatible to the MBHP Core module! Best Regards, Thorsten. P.S.: I had no problems with ordering more than 5 parts, it wasn't clear if Microchip means "5 pieces" or "5 different chip types", so I just tried it ;-)

Hi Kyo, every encoder allocates 2 digital inputs, with 56 rotary encoders you could only add 16 additional buttons Ok, alternatively you could plug some buttons to the analog pins, but this would require a AIN module (since more than 8 analog inputs are needed for this solution) Best Regards, Thorsten.

Hi Dimitris, first question before I write 1k of infos which you already know: did you download the Logic Control Manual from the Emagic site? Because this manual comes with a description of all "button IDs" Best Regards, Thorsten.