TK.

Hi Christoffer, yeah, the MIDIbox SID *is* cool - yesterday I made my first real song with 2 SIDs (stereo) and I'm very satisfied with the result. :D The binary numbers are a little bit tricky. Don't "translate" them into hex or decimal values, just deal with them like with flags (or think about switches, which can be turned on or off). So, a saw sound is: 00000010 (Bit 1 is "switched on") Triangle and Pulse together: 00000101 (Bit 2 and 0 are "switched on") Sync sound: 00100001 (Bit 5 for sync and bit 0 for triangle is set) Btw.: Sync and Ringmodulation are only working together with Oscillator 3. OSC3 is the "master", OSC1 and/or OSC2 the slave. More details can be found in the 6581 specification. A good start: OSC1 Waveform: 00100010 OSC2 Waveform: 00010000 (off) OSC3 Waveform: 00000010 Now increase the Transpose value for OSC1 and you will hear the difference. A well living sound can be achieved by assigning the velocity to the Transpose CC of OSC1 (CC17). Make it more fat - enable the second oscillator: OSC2 Waveform: 00100100 detune it and and assign a LFO to the pulsewidth Best Regards, Thorsten.

Sure, you just only have to build a circuit which outputs a control voltage of 0-5V. See also http://www.ucapps.de/midibox_ext.html Additions to this page are welcome! :) Best Regards, Thorsten.

Hi Dan, it depends on the used software if a transport section and datawheel can be used or not. As far as I know, it's possible with Logic/Cubase/Cakewalk/Sonar by sending MIDI events to the "MIDI Remote" receiver of the program. Type of MIDI event doesn't matter, mostly Note Events are used. Read out Song data: not possible due to lag of support from the Emagic/Steinberg/Cakewalk. They are using propritary protocols which are only available with a NDA - this kills a public domain project. Additional data wheel for menu options: not necessary, since all menues can be controlled intuitively with the available buttons, pots, encoders, faders, etc... Best Regards, Thorsten.

See http://www.ucapps.de/midibox_sid_changelog.html Have fun! :-) Best Regards, Thorsten.

Hi Frank, I changed the timeout algorithm (slightly): up to now, the current fader value is copied into the "target" register during the timeout state after a fader has been moved. This should fix the problem (?) Link to the new firmware: http://www.ucapps.de/midibox_mf/midibox_mf_v0003.hex.zip Best Regards, Thorsten.

Hi Jurie, ok, now it's clear. It doesn't work due to a misunderstanding. All MIDIbox firmwares with integrated merger don't support a second MIDI In. Only the data stream from the common MIDI In is merged with the internal controller data stream. If you need a second MIDI In, an additional merger is required (see also the diagrams under http://www.ucapps.de/midibox64_tutorial_en.html). You also mixed up the pin names, which confused me. RA4 is pin #6, Rx is pin #26. The MIDIbox Plus firmware doesn't use pin #6 Best Regards, Thorsten.

Hi Christoffer, here some instructions from the Logic Changelog: And here an example: I used the ESP. When you go into the "controller" view (like shown here), you will see all available parameters. The parameter position correspond to the Fader event number - 1 (7 -> CutOff) Best Regards, Thorsten.

Finally I found the bug - the "second level fader handler" did call the MIDI learn routine sometimes, although this routine should only be activated within the MIDI Learn submenu. This error is fixed in v1.002 - Frank: now it should work in your environment :) http://www.ucapps.de/midibox_mf/midibox_mf_v0002.hex.zip Axel: I also checked the SysEx function, it works Best Regards, Thorsten.

Hi Christoffer, to 1) thats ok, currently the 16 last buttons are disabled by default due to compatibility reasons with the old design. I will change it in one of the next releases. Just assign a MIDI event to the buttons with the MIDI Learn function. to 2) yes, the 32 LEDs are automatically assigned to the 32 last buttons to 3/4) I will check it Best Regards, Thorsten.

Hallo Stefan, Die Firmware ist dafuer nicht ausgelegt, und ich moechte lieber nicht damit anfangen, irgendwelche Zwischendinger zusammenzubasteln, die machen naemlich nichts als Aerger. ;-) Deshalb benoetigst Du zwei Cores Momentan noch komplett in Assembler. Anpassungen sind moeglich, setzen aber PIC-Programmierkenntnisse vorraus. Das wird sich mit der MIDIbox NG aendern (siehe News), hier moechte ich die tiefgreifenden Assemblerroutinen von den reinen Handlern separieren, so dass man problemlos seinen eigenen (C-)Code draufsetzen kann. Unter http://www.ucapps.de/mbhp_din.html befindet sich ein Schaltplan namens mbhp_dinx4_32buttons.pdf, in dem die Pin-Zuordnungen eingetragen sind. Gruss, Thorsten.

No, there is no direct connection between Vdd and V0, this is just only a line which indicates the voltage drop Vdd-v0. It would be interesting for me if you see *anything* on the LCD. Black rectangles or something else. To see those rectangles, you only have to connect Vdd, Vss and V0 and you have to adjust the contrast pot on v0. Best Regards, Thorsten.

Hi Jurie, something in your descriptions makes no sense (this isn't a reproach, I know that the docs should be better ;-)) - are you trying the MIDIbox Plus firmware with 2 MIDI Ins? Best Regards, Thorsten.

Update: I was able to reproduce the MIDI Overrun problem with a direct feedback (MIDI Out->MIDI In). Normaly this shouldn't hurt. I will try to find the root cause tomorrow. It isn't a performance problem, but a bug somewhere in the firmware (I hope that only MIDIbox MF is affected ;-)). Best Regards, Thorsten.

Hi Damien, I don't plan to use other LCDs for my own MIDIboxes, but the "Display Plugins" will allow to customize the MIDIbox NG for other display devices: bigger dotmatrix LCDs, graphic LCDs, LED displays --- programming skills are required for such adaptions. Another thing is the display sharing issue. I hope that with the MIDIbox Link (which will also be available for PIC16F) only one LCD will be necessary. Best Regards, Thorsten.

Find the changes here: http://www.ucapps.de/midibox16e_changelog.html And the new tutorial here: http://www.ucapps.de/midibox16e_tutorial_en.html Best Regards, Thorsten.

Initially I planned to nominate only one well-made MIDIbox design per week, but this time it's really difficult.. in the last days I got photos from three outstanding projects which are the dream of everything from us :) So here they are - just choose your private favourite: MIDIbox64 with integrated TB303 synthesizer by Tom303: MIDIbox64 as "typographical synthesizer" by Rob: Multi-MIDIbox environment with a lot of motorfaders/encoders/buttons by Axel: Best Regards, Thorsten.

Hi Andre, normaly there isn't a buzzing sound - just download the schematic from the MBHP SID page and follow the tracks. Check especially the polarity of the rectifier and the electrolytic capacitors! I've no experiences with the MultiPic burner - are you able to verify the flash content? On this way you can ensure that the programming was successfull. Therafter you can do the following test to check if the program is running: start MIDI-Ox and send a program change to the MIDIbox SID: it should response with a lot of controller events (the sound parameters) Best Regards, Thorsten.

Hi Christoffer, the second AINX4 has to be connected to exactly the same pins like the first AINX4, expect for the analog outputs of the AINX4 module - they have to be connected to J5:A4-J5:A7 a connection diagram can be found here: http://www.ucapps.de/mbhp/mbhp_ainx4_64pots.pdf Best Regards, Thorsten.

first check the diodes, if they aren't connected in the right direction, the fader will not move. I think that this pictures explains more than 1000 words ;-) And check the voltage behind the LM317 during the motor is running. It should be stable and shoudln't go down under load. Best Regards, Thorsten.

I cannot recomment it, since the current drain of a LED (ca. 20 mA) is too high for the JDM circuit. It would only work with an external power supply for the LED + a transistor as electronic switch, but do you really want to spent so much effort just for a LED? Best Regards, Thorsten.

Hi Ian, since the current MIDIbox MF design is a realtime system with a defined update cycle, the faders won't be moved slower or faster... but possibly some features will be provided in the next years which are really usefull for the daily work and cannot be implemented with a PIC16F anymore (especially RAM consuming features) Best Regards, Thorsten.

Does the rest of the circuit work correctly? Does your computer receive any MIDI data? Did you adjust the contrast pot so that you see anything on the display after poweron? Best Regards, thorsten.

yes - and with an additional shift register for the DIN, you can control all LEDs with 32 buttons. I will add a more detailed description about the button/LED assignments in the next days. Best Regards, Thorsten.

Hallo Malte, ueber Pin 2 und 3 werden normalerweise keine Pulse gesendet - das sind analoge Eingaenge. Wenn Du schon ein Oszi zur Verfuegung hast (ich hoffe, dass hier nicht der Eindruck entsteht, man koenne die MIDIbox nur mit teuren Geraeten debuggen ;-)) dann schaue Dir mal den XTAL1 an - an diesem Pin muss ein 20 MHz Sinus zu sehen sein. Interessant ist auch die Enable-Leitung zum LCD: die muss waehrend des Einschaltens wackeln. Mit einem PIC-Programmer koenntest Du auch den Flash-Inhalt ueberpruefen. Dazu musst Du lediglich die Firmware, die sich im PIC befindet/n (sollte) in IC-Prog (o.ae.) einladen und den Verify-Button anklicken. Gruss, Thorsten.

Es geht noch einfacher: Du kannst den Tx-Pin des PICs auch direkt an den Rx-Eingang des GamePorts anschliessen --- ohne Optokoppler dazwischen. Zusaetzlich muessen dann auch noch die Masseleitungen miteinander verbunden werden. Im MIDIbox Plus Hardware HowTo findest Du dazu einen Schaltplan (demnaechst wird es auch eine eigene Seite geben, auf der alle Moeglichkeiten aufgelistet sind) Gruss, Thorsten.