TK.

three core modules, some DINx and DOUTx modules and software skills (or somebody who helps you to customize this controller...) Best Regards, Thorsten.

Hi Kieran, well, a simple 1-track/32-step sequencer has already been integrated (the Wavetable sequencer). However, a more complex sequencer should be possible, but it depends on the requirements. A 4-track TB303 style sequencer is very simple and could be added w/o problems. However, there is no place to store more than one pattern, so it would only be usefull for live sessions. A more complex analog style sequencer like MB64seq requires an additional core. Best Regards, Thorsten.

Hallo Stefan, probierst Du mal den RxTx-Test aus? http://www.ucapps.de/howtodebug/test_rxtx.hex.zip Er leitet die eingehenden MIDI events direkt an den Ausgang weiter - damit waeren zumindest die softwareseitigen Fehlerquellen (z.b MIDI Merger disabled und Device Nummer != 00) ausgeschlossen. Gruss, Thorsten.

Hallo Jens, folgende Dateien helfen weiter: http://www.ucapps.de/midibox/midibox_plus_16.pdf (Schaltplan) http://www.ucapps.de/midibox/mplus_pcb_v1.gif (PCB Quickview) http://www.ucapps.de/midibox/mplus_pcb_v1.brd (Eagle Datei, kann mit der Freeware Version eingeladen und ausgedruckt werden) Desweiteren helfen vielleicht auch die Fotos auf der MIDIbox Plus Seite weiter. Gruss, Thorsten.

This requires some kind of "radio button" function (means: one LED active at one time). With MIDIbox64 this can be implemented with meta events, with MIOS you just have to insert the code into an existing application (I can provide an example if necessary) Best Regards, Thorsten.

Fine - so it must be a minor problem. :) Power is ok, contrast also. Let's double check the CS lines, they must be connected to: CS1 -> Pin RD0 CS2 -> Pin RD3 CS3 -> Pin RC4 CS4 -> Pin RC5

My offer is still valid: if you send me a display for one week, I will setup a dedicated driver for MIOS Best Regards, Thorsten.

Just to ensure (due to linguistical differences): does it mean that black pixels are visible, or that the screen is blank. ;-) Best Regards, Thorsten.

Hi Scott, fine fine - one more MIDIbox SID which is up and running! :) Beside of the possible problem which has been mentioned by Ian, another reason could be that you forget to select the filter mode and to route the VCO outputs to the filter. This has to be done with the MIDIbox SID editor, or via CC: CC # | Hex | Description | Range | Reset =====+=====+==============================================+=============+====== 44 | 2Ch | Filter Channels | | 0 | | Bit 0: Filter for Voice 1 on/off | | | | Bit 1: Filter for Voice 2 on/off | | | | Bit 2: Filter for Voice 3 on/off | | | | Bit 3: Filter for Audio In on/off | | 45 | 2Dh | Filter Mode | | 0 | | Bit 0: LowPass on/off | | | | Bit 1: BandPass on/off | | | | Bit 2: HighPass on/off | | | | Bit 3: Voice 3 off | | 46 | 2Eh | Filter CutOff frequency | 0-127: val | 127 47 | 2Fh | Filter Resonance | 0-127: val | 0 -----+-----+----------------------------------------------+-------------+------ Example: CC 44 -> 7 CC 45 -> 1 Best Regards, Thorsten.

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.