TK.

okok, before you've to wait endless for the complete documentation, you will find now all the stuff which is required to get this module running under Concepts->MBHP->USB Please read it carefully, this projects isn't suitable for beginners (because of the SMD chip) Best Regards, Thorsten.

Ja, richtig, der Optokoppler muss nur am ersten Eingang der MIDI-Kette bestueckt werden. Bist Du schon am basteln? :) Gruss, Thorsten.

Hi Duggle, MB64, MB16E, MBMF and MIDIbox64SEQ will be ported to MIOS as soon as I finished my running projects. In the meantime you could use the ain64_din128_dout128 test application which don't come with a menu or defined SysEx structure, but already supports 64 pots and a lot of buttons and LEDs. All the known MB64 features will be available with the ported firmware, but if you want to start with some experiments, an upgrade would already makes sense. :) Best Regards, Thorsten.

Than lower the R*C value, than shorter the delay time of the monoflop. However, it's not clear to me why 100k wasn't working, maybe you are using a bigger capacitor? Best Regards, Thorsten.

I never tried the Kawai driver by myself, another user noticed that the Yamaha and Roland driver don't work with his windows installation, but the Kawai did run... however, I'm using Windows ME (and don't plan to switch to any newer version ;-)) therefore I cannot help if the failure is caused by a driver issue. Rx pin: yes, you can disconnect this directly on J11, this should help. It's only important to know if the continuous stream is caused by a feedback loop, and this can be determined by "breaking" the loop. Best Regards, Thorsten.

Hi Pilo, Jack sent me a KS0104 based display some time ago, but I wasn't able to write a driver because of a incomplete spec. Later I realized that such kind of displays will eat so much performance, that they cannot be used with a single chip. A second PIC will be required with a tricky firmware which emulates a KS0108 protocol or something similar. Too much effort for me (yet), so: forget this display :-/ Best Regards, Thorsten.

Hi Dan, to 1: only two layers are provided. So, you could assign Mute to the first, Solo to the second layer, and use two layer buttons to select the layer. And of course also a shift button if you want. :) It isn't possible to assign a function of a second LC, because the protocol doesn't support channels or Client IDs. Only a trick could help: if you've experiences with the Map-Feature of MIDI-Ox and MIDI Yoke, you could try to route the MIDI events to virtual MIDI ports depending on a MIDI channel or whatever. I never tried this (because I've no need for this), so you have to make your own experiements ;-) to 2: the MBLink port of the USB module is nothing else than a direct connection to J11 of the core module. It replaces the LTC. MBLink "Forwarding" and "Endpoint" are features which don't help for the LC protocol, because it requires a direct Point-to-Point connection (like mentioned by you) 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 LED digits: possibly simmilar to the MTC from the MIDImon, the additional digits will also be connected to the first and third SR (so that 6 digits are on the left, and 6 digits on the right side). The 4 additional anode lines will be connected to the 4th register. You are right, due to the 128 DOUT pins limitation it's not possible to use so much LEDs like without the meters and MTC display. A Possible configuration: o 3 SR for 8 LED rings o 3 SR for 8 meters o 4 SR for the MTC display (4 spare pins) makes 6*8 + 4 = 52 free DOUTs for LED functions Best Regards, Thorsten.

Nomical: in the meantime I've decided to integrate the encoder functions of StepC into the "assign map" of StepD. This simplifies the implementation and doesn't consume that much memory. In other words: StepC will be skipped (I won't use it anyhow), StepD will be renamed to StepC, the feature of the previous StepC will be a subfunction of StepC sooner or later... Pay_c: yes, it took three months until I found this very robust solution. ;-) However, if somebody is able to find some nice knobs for the micro buttons, he can also mount all elements to one board. But it seems that such button caps are not available on the free market (since they are very customer-specific) Rowan: I got the knobs from TzanhZsu, he made a special deal with Waldorf (the makers of the Q synth). Thanks again to Tzz btw.! Ilmentator: a good question! No, I'm right hander, but I think that I'll mostly handle with the buttons with my left hand during the right hand operates with the encoders :) Best Regards, Thorsten.

Ich habe leider keine Datenblaetter fuer die Panasonic Fader... Zur Aufteilung der Spannungen: beides ist moeglich, ich weiss allerdings nicht, welche Loesung die bessere ist, dazu fehlt mir die Erfahrung. Fuer das MF Board waere auf jeden Fall eine Eingangsspannung von 12V besser geeignet, weil am Gleichrichter ca. 1.4V abfallen und der LM317 ein wenig Spielraum braucht. Gruss, Thorsten.

Fine - so the burning procedure was successfull. Yes, you could remove the Rx line for this first test. But before you try the gameport, you could also check the other COM MIDI drivers (there are three different ones from Yamaha, Roland and Kawai... not every driver works correctly with the different Windows versions) Best Regards, Thorsten.

Hi Che, the power supply input pins for the +5V voltage domain are J2:Vs (ground) and J2:Vc (+5V). When you follow these tracks from the core module, to the SID module, to IC2 and IC3, with the probes of your multimeter you should be able to find the error Best Regards, Thorsten.

I mean a manual which lists the functional possibilities and gives you the required schematics. For a complete construction manual I don't have the time anyhow. And if somebody wants to help me (for example with the MIDIbox LC construction guide), step forward! This will speed up the whole development. However, also documentations like construction reports, "walkthroughs", "HowTos", etc. by other people are very welcome! To both questions: no. Like everytime the control elements are mounted on breadboards. This is much easier and goes faster. So fast, that I've already completed most modules today! (Just to ensure that everything fits well before the frontpanel will be produced by Schaeffer Apparatebau :) Best Regards, Thorsten.

Hi Nomical, here my private schedule Step B update: maybe in 2 days, after I've implemented two new features into MIOS (addressing up to 8 BankSticks & improved encoder driver) Step B documentation: until friday Step C: this weekend, after I've built the first encoder modules Step C documentation: unsure Step D: next weekend, after I've built the complete control surface Step D documentation: hopefully this year ;-) Best Regards, Thorsten.

This time a MIDIbox64 sequencer from DriftZ (Belgium) (more pictures: http://users.pandora.be/DriftZ/DriftZ_MBHP_pics.html) and a Traktor2 controller by Zekill (France) (more pictures: http://membres.lycos.fr/zekill30/album/)

Den AN2131SC gibt es neuerdings bei Reichelt fuer 10 Euro. :) Gruss, Thorsten.

By shifting the Inc/Dec states I finally found a solution which should also work with the Alps STEC11b without an additional encoder type ID. Chriss: could you please try this new MIOS version: http://www.ucapps.de/mios/mios_v1_2c.zip with encoder type 0x80? Best Regards, Thorsten.

Ja, diese Konfiguration ist mit einem Core moeglich. Ich wuerde allerdings 96 buttons und 64 LEDs bevorzugen, da die MIDIbox LC ein paar zusaetzliche Funktionen bietet, die man dann auf die zusaetzlichen Buttons legen kann (bspw. verschiedene Display Modi. Verbindung zwischen den Boxen: ist in diesem Fall nicht notwendig. Gruss, Thorsten.

addendum: I just have realized that the output signals of the STEC11 are different - I compared the waveforms from the datasheet with the waveforms traces with Rasmus' encoders. So - it isn't your fault, it's an imperfection in MIOS. I have to integrate some additional encoders types (0x82, 0x83, etc.). Best Regards, Thorsten.

Hallo, ja, Du benoetigst leider 3 freie MIDI IOs um drei MIDIbox LC's zu betreiben. Diese Vorgabe kommt nicht von mir, sondern von der Host-Applikation. Im Uebertragungs-Protokoll ist eine adressierung von verschiedenen Clients ueber eine MIDI-Leitung nicht vorgesehen. Abhilfe schafft vielleicht das MBHP_USB Modul, das hier schon seit ein paar Wochen bei mir herumliegt und das ich irgendwann einmal dokumentieren muss. Es bietet zwei MIDI IOs und ist sowohl kompatibel zum Standard USB-MIDI Protokoll, als auch zum MIDIsport 2x2 interface. Den Schaltplan gibt es hier: http://www.ucapps.de/mbhp/mbhp_usb.pdf Netzteil: 8 Motorfader benoetigen im Worst-Case bis zu 1 A, die Backlights der 6 LCDs ca. 600 mA, somit wuerde ich ein 4A bis 5A Netzteil empfehlen - oder 3 x 1.5A Best Regards, Thorsten.

Hi Steve, I've just programmed the "jitter monitor" which allows to measure the signal noise. It would be an important input for me how much noise influence the AIN results of your MIDIbox. Could you please check this? The application can be found under Concepts->MIOS->Download Best Regards, Thorsten.

Hi again, I've compile the PIC16F based firmware with the to-com option, it can be found in the http://www.ucapps.de/midibox_sid/midibox_sid_v1.4.zip Archive (untested!) Best Regards, Thorsten.

Hi Chriss, it's not clear to me why 0x81 behaves exactly like 0x80, are you sure that you did compile and convert the firmware correctly? Do you see the same results when pin A and B are exchanged. Just for clarification reg the non-detented encoders: Until some weeks I used OEM encoders from Alps without type number (I guess that these are customized types, Alps offers this option if you order more than 1000 pieces). I got them for a few bugs from Ebay. I guessed that these are the same like STEC16B, but this was wrong. They have the same size, but the pinning is ACB. Also the resolution is different, they are sending 12 ticks per revolution. And with the interpolation feature I get 48 ticks per revolution. Also the statement made in the MIDIbox16E introduction page is not correct (STEC16B from RS sends 36 pulses) - a misinformation (I never used the encoders from RS...) so I should update this page. Ok, to make it clear: STEC16B are non-detented (type 0x00) and they are sending 24 pulses. The MIDIbox16E and MIOS driver detects every rising and falling edge, the result are 96 pulses per revolution Detented type 0x80: every second edge, result: 48 pulses per revolution. I know only one detented encoder (a jog-wheel) from Rasmus which works correctly with this type Detented type 0x81: should be the default setting for detented encoders, 24 pulses per revolution are sent like known from the specification. Another encoder from Rasmus needs this setting. I guess that this is also the case for Alps encoders. Best Regards, Thorsten. P.S.: hope that I get the detented encoders from Ian soon so that I'm able to test the driver by myself ;-)

yes, there are several ways to test the MIDI In by using a LED. First step: For this test you have to solder two cables to the bottom side of the core module. The LED should lit (take the polarity of the LED into account, the short leg is the cathode and has to be connected via a resistor to Vss). So long as single MIDI events are received, you won't notice a difference, but with a continuous SysEx stream the LED should begin to flicker. Note: so long as the LED is connected directly to the Rx pin, the PIC will *not* receive the MIDI data due to the power consumption of the LED. This method is only usefull to test if the MIDI signal is available at the Rx pin. If the LED doesn't lit, connect the anode to the optocoupler (Pin IC2:6). If it still doesn't lit, connect the anode with the +5V rail of the optocoupler (Pin IC2:8 ) If this doesn't help you to detect the error, continue with the next step: In this configuration the LED should only lit when MIDI data is received. Than more MIDI events are received a time, than brigther the LED. If the LED doesn't lit, check the polarity of the protection diode before the optocoupler. Also check the polarity of the MIDI cable. If both tests didn't help, ensure that your MIDI interface is working correctly: take a MIDI cable and connect the MIDI Out with the MIDI In of your interface in order to get a feedback loop. Send a MIDI event with MIDI-Ox (just use the virtual keyboard..) and check if the data at the input and output monitor is the same. disconnect the LED after the tests, otherwise the PIC will receive no MIDI data. Best Regards, Thorsten. FAQMARKER

Hi Psytron, ok, lets analyse the problem step by step. I guess that the bootstrap loader has been burned into the PIC correctly - do you see the same effect when the MIDI In is not connected to your PC? Best Regards, Thorsten.

Hi Steve, this delay is already available: the MF driver doesn't trigger events for about 50 ms after the fader has been moved. The only case where events are sent is, when the fader didn't reach the target position. Ok, I will think about some new analysis applications which will help to narrow down the root cause. For example a "jitter monitor" which visualize the signal noise. Please hold the line ;-) Best Regards, Thorsten. P.S.: programming the flash more than 1000 times is no issue, I assume that most PICs can be burned more than 100k times without problems