TK.

Cool! :) I had no luck with a no-name (cheapo) camera connector kit, so that I purchased an iRig MIDI meanwhile, which is available for ca. 50 EUR at amazon Advantage: MIDI IN/OUT/THRU already integrated (no USB MIDI interface required), and an additional socket to power the iPad via USB from an external power source. Best Regards, Thorsten.

I would like to know if you've upload the MBHP_MF_NG firmware via MIOS Studio? (I assume that MIOS V1.9g is already installed, so that you can directly upload the app) If not, nothing will work, because no application is installed... Yes, unused analog inputs have to be connected to ground. The unused digital inputs (touch sensor inputs) can be left open. Best Regards, Thorsten.

Hi Rio, the old mechanism was problematic when the sequencers of multiple SIDs should be synchronized to an external MIDI clock (only a single SID could be played at one time). Therefore it has been changed (in rc19!) Relevant entries from the CHANGELOG.txt file: MIDIboxSID V2 RC19 ~~~~~~~~~~~~~~~~~~ ... o The "note off" function of the SHIFT menu now works as "Note On/Off" (called "Ply") This function is intended as replacement for the optional Play button Patch will be played/stopped on all selected SIDs o Removed button combination "SIDx+MENU" (which was previously used for Play function) This combination could get a different purpose on future [/code] Best Regards, Thorsten.

I'm waiting for the MacOS build, so that I'm finally able to integrate the patch name change function into the panel. :) Best Regards, Thorsten.

It's neither a MIOS Studio issue, nor a MIDIO128 firmware issue, as exactly the same setup is working at my side. It's of course important that the PIC based core uses a different device ID so that it won't be mixed up with the LPC17 core during a Query, but Johnc already considered this (PIC configured for device id 1) I need more log files to find out the root cause. Please do following three tests: 1) connect an IN/OUT pair of your MIDISPORT 2x2 to OUT1/IN1 of the LPC17 module (a common bidirectional connection, nothing special here) Select the appr. ports of your MIDISPORT interface in MIOS Studio and press the Query button -> is the LPC17 core regognized? 2) remove your MIDISPORT (not required for next tests), and select the IN/OUT port of your LPC17 core in MIOS Studio again. Enter following commands in MIOS Terminal: set router 1 IN2 all USB1 all set router 2 USB1 all OUT2 all router save DEFAULT [/code] "set router .." will change the setup of Node 1 and 2 remotely, the "router" command will output the current connections, "save DEFAULT" will store the changes in the .MIO file Please post the complete terminal output here which is print when these commands are entered. I especially need to know the complete router setup. Now connect your PIC core to IN2/OUT2 of the LPC17 core. Is the Query button working now? If not: enter following command in the MIOS terminal: [code] set midimon on Now each incoming and outgoing MIDI message will be printed by the MIOS terminal as well (*) Press the Query button and post the log messages here. 3) enable the MIOS terminal based MIDImon as above, and power-cycle the PIC core - does it send a SysEx message during startup? Print the terminal output here Next instructions once I got the logfiles and once I know in which direction the troubleshooting has to be continued. Best Regards, Thorsten. (*) just to highlight: the MIOS terminal based MIDImon, which is actually running on the LPC17 core, doesn't print SysEx messages send/received from USB1 or MIDI1 (IN1/OUT1) to avoid a clash with MIOS Terminal messages. This might be confusing - and thats the reason why I recommend to test this with IN2/OUT2!

Which MIOS Studio version are you using? I remember that an older version didn't handle the Device ID properly in a multicore scenario (see also ) Please test with the latest version 2.2.3 Best Regards, Thorsten.

I think it's a good idea to integrate the protocol into MBLC as well, especially since it only needs a single 2x40 LCD (just noticed that it's supported by Logic Pro, which means that I will be able to test it by myself) MBHP_MF_NG needs an firmware update to support it properly, because the fader events are different. Best Regards, Thorsten.

It's normal that the application fills non-available entries with default entries. Please continue with the instructions that I gave you! Especially check the router configuration as proposed, and configure the router from the CS because when you editing these entries in the .MIO file you are adding an unnecessary source for configuration errors! Best Regards, Thorsten.

Found via Google, first hit: http://www.mackie.com/pdf/mackiecontrol_pt.pdf Best Regards, Thorsten.

MIDI1 selects IN1 if an input port, and OUT1 if an output port MIDI2 selects IN2 if an input port, and OUT2 if an output port Your configuration seems to be correct. You can doublecheck it by entering the "router" command in MIOS Terminal, it should output: [596720.708] MIDI Router Nodes (change with 'set router <in-port> <channel> <out-port> <channel>) [596720.709] 1 SRC:IN1 all DST:USB1 all [596720.709] 2 SRC:USB1 all DST:OUT1 all [/code] So, it looks like a hardware issue. The integrated MIDI monitor of MIDIO128 helps you to debug this: enter the "Mon." page to get following screen: Whenever something is received via USB1, the USB1 in the left upper corner should show the MIDI event for ca. 1 second Whenever something is transmitted via USB1, the USB1 in the left lower corner should show the MIDI event for ca. 1 second Whenever something is received via MIDI1, the IN1 item should show the MIDI event for ca. 1 second Whenever something is transmitted via MIDI1, the OUT1 item should show the MIDI event for ca. 1 second Accordingly you are able to test: - if MIDI data is received at IN1 - if MIDI data is sent through OUT1 - if MIDI data is forwarded from USB1 to OUT1 (because in this case the USB1 and OUT1 will show the event) - if MIDI data is forwarded from IN1 to USB1 (because in this case the USB1 and IN1 will show the event) If IN1 doesn't change if something (e.g. a MIDI note) is sent from the MIOS8 core, the most simple test would be to try IN2 -> does IN2 show the MIDI event? Yes: adapt your router settings accordingly, is the bidirectional communication with MIOS Studio working now? If neither IN1 nor IN2 show an event, check the MIDI OUT circuit of the MIOS8 core, because it's unlikely that you have the same (soldering?) error at IN1 or IN2 of the LPC17 Core. If IN1 (and even IN2) are working ok, then the problem is probably located at the MIDI OUT1 port of the LPC17 core, or the MIDI IN port of the MIOS8 port. In order to exclude, that the problem is located at MIDI OUT1 of the LPC17 core, you could try MIDI OUT2 instead and change the router settings accordingy? Does it help? If none of these tests help to find the problem, you could use your MIDI interface for similar checks. Best Regards, Thorsten.

Yes, but now you should also swap ground and +5V on the fader. Best Regards, Thorsten.

I looked into my records and noticed, that you are not using a customized version, but the precompiled version. Therefore please ignore the answer, and just upload the .hex file -> it will work for you! Best Regards, Thorsten.

I checked this under Windows and noticed an incompatibility in the float->integer conversion which caused the wrong SysEx command. A workaround has been added to v1.4 - please try this version. Best Regards, Thorsten.

Could you please create another snapshot so that I can doublecheck the output? Please also check that you are using the new panel: right-click on panel, select edit mode -> at the right side you will see the major (1) and minor (3) version number. MIDI Interface: of course, you have to select you own IN/OUT ports again whenever you've updated the panel. Best Regards, Thorsten.

If you are already using a customized version, you could just update your (complete) repository to get the latest changes under $MIOS32_PATH/mios32 - thereafter recompile your application -> done! You have to store your changes in the SAVE menu, thats the problem. After boot MIDIO128 will always load the DEFAULT setup. This means in other words: you have to rename your setup to DEFAULT if you want to get it active after boot. You can determine the router setup values by yourself after you've changed them on the CS, stored the setup, mounted the SD card and opened the file with an editor. Best Regards, Thorsten.

If 5V/GND are swapped, the motor connections have to be swapped as well - from this point of view Roellis diagram is correct. I think that it doesn't matter if the motor is at the lower or upper side, it depends a bit on the case that you are using. But usually it's better to have the motor at the upper side, e.g. if the panel end is lowered (german: "wenn die Unterseite der Frontplatte abgesenkt ist") @Roelli: could you please change your diagram accordingly to give a better "best practice" example? Best Regards, Thorsten.

Thank you! The MIDI log was very helpful as it shows, that you are using the Stereo Link (WOPT=1) and changed the right OSC3. The SysEx address should point to the left OSC1 in this case, but it pointed to the right OSC1, therefore the left OSC1 wasn't updated by sammichSID (although it was updated on the panel). Both OSCs were updated correctly when the left OSC1 was changed - and this is what I'm usually doing, therefore I haven't noticed this. Same issue was with the filter parameters for all engines. This is now fixed in V1.3, which can be downloaded from the DDB I wasn't able to reproduce the drum instrument issue, could you please give more details how to reproduce it? Best Regards, Thorsten.

You have to update your gpasm installation, see also Best Regards, Thorsten.

I really like this connection diagram, thanks for the inspiration! I will link it to the MBHP_MF_NG page once the connections have been proven at your side. :) They look correct. I'm not 100% sure if the polarity for the motor is correct, but if it runs into the wrong direction just swap the cables (and please also update the diagram in this case) Best Regards, Thorsten.

Ctrlr provides an integrated MIDI monitor - are MIDI messages sent when you are moving the sliders/knobs? Which MIDI events? Could you please post a log? Best Regards, Thorsten.

A SysEx transfer issue at port OUT1 and OUT2 has been fixed in MIDIO128 V3.007: MIDIO128 V3.007 ~~~~~~~~~~~~~~~ o corrected SysEx output for LPC17 [/code] Best Regards, Thorsten.

DOUT: I fixed the screenshot in the documentation. Coding of source/destination ports in .MIO file: USB1:0x10, MIDI1: 0x20, MIDI2: 0x21, OSC1: 0x40, OSC2: 0x41, OSC3: 0x42, OSC4: 0x43 SysEx forwarding issue: I remember that somebody else had the same problem with his MIDIbox SEQ, and it turned out that it was related to a problem in the UART handler. I forgot to release an MIDIO128 update, so here it is (V3.007): http://www.ucapps.de/mios32_download.html Please download it to get SysEx transfers working. Sidenote: it's possible to use a MIOS8 based core with device ID 0 if it's connected to MIDI2 (IN2/OUT2) But since you've already changed the ID, it should also work at MIDI1 (IN1/OUT1) -> continue with this setup. Best Regards, Thorsten.

Der Optokoppler liegt nicht im MIDI Out Pfad, vergleiche auch: http://www.ucapps.de/mbhp/mbhp_core_lpc17.pdf Moegliche Ursachen: MIDI OUT Sockel, R21, R22 oder LPCXpresso Modul nicht sauber verloetet -> ueberpruefen. Gruss, Thorsten.

Ok, passt - ich darf mal aus der Dokumentation zitieren: MIDI events are output on MIDI OUT1 and USB. The remaining MIDI OUTs only output a MIDI clock. Nun schliesse mal den MIDI OUT1 an den MIDI IN Deines MIDI Interfaces - jetzt sollten die Noten angezeigt werden. Gruss, Thorsten.

Machst Du bitte noch ein Photo von der MIDI Verbindung zwischen Core Modul und MIDI Interface? Gruss, Thorsten.