Well, that is too simple. For input, you need a mechanism to convert the MIDI current loop to the voltage levels required. This is generally done with an optocoupler along with a high speed diode for reverse polarity protection.

So I need an optocoupler to fix the Chinese midi cable and then another on the pi side? I don't know much about optoisolstors, is the sfh618a-4 an appropriate chip?

MIDI cables for your sound card have all the necessary parts built in to connect with another MIDI device. If you get two plus a 15 pin dsub connector (like for a joystick), you can use one for your Pi. As far as discrete optocouplers, the rise time on the Vishay part you linked is too slow. You need a rise time of < 2 microseconds as per the specification and a significant coupling ratio (although this can be improved by, for example, an additional transistor in Darlington configuration). Usually, the part of choice is the 6N138.

Just out of quriosity... Has anyone had any luck getting Munt running on an OrangePI-PC board?
If so. What are the steps to get it running? If it is possible to do so, then I need to test an idea that I have.

What stage are you at? I'm assuming you're using ARMbian. Any problems building it using instructions for the Pi 2? What do you intend to use for MIDI input?

gdjacobs wrote:

What stage are you at? I'm assuming you're using ARMbian. Any problems building it using instructions for the Pi 2? What do you intend to use for MIDI input?

Well. I came as far as to make it, using "cmake", yet it could not find any QT5wigdets or something like that.
I cant remember what that exact package/software was named, that it did not find.
So I have blanked the SD card and thought that when someone here had it running, he might have a list of all
the steps to follow. I am using an OrangePI and not RaspberryPI, and I think I read something about that being
able to run Munt too. I think that I saw it on page 3 in this tread.

Yeah, the OrangePi should work. If you use ARMBian, the install should point to the Debian package repository. Please update your package list (sudo apt-get update) and install the dependencies for the RPi2 listed in the first post of this thread before retrying cmake.

Well, so why do you need Qt5Widgets? AIUI, you want the library and the "light-weight" ALSA drivers. It's easy to bypass unnecessary components during the build. The easiest way would be to just run cmake in the library directory, i.e. do

1cmake -DCMAKE_BUILD_TYPE:STRING=Release <path-to-munt>/mt32emu
2make
3make install

By default, the library itself only depends on cmake and the C++ runtime.

Speaking for myself, I included both QtWidgets and Xaw because one might want to run the Qt client via tunneled X11.

Hmmm.... On Armbian on the OrangePI. It can not install the qtmobility-dev package, using apt-get.
Does it serve any purpouse as such?

Yup.... This is as far as i get:

-- Found GLIB2: /usr/lib/arm-linux-gnueabihf/libglib-2.0.so -- Found MT32EMU: $<TARGET_LINKER_FILE:mt32emu> -- Looking for c […]
Show full quote

-- Found GLIB2: /usr/lib/arm-linux-gnueabihf/libglib-2.0.so
-- Found MT32EMU: $<TARGET_LINKER_FILE:mt32emu>
-- Looking for clock_nanosleep in rt
-- Looking for clock_nanosleep in rt - found
CMake Error at mt32emu_qt/CMakeLists.txt:114 (find_package):
By not providing "FindQt5Widgets.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"Qt5Widgets", but CMake did not find one.

Could not find a package configuration file provided by "Qt5Widgets" with
any of the following names:

Qt5WidgetsConfig.cmake
qt5widgets-config.cmake

Add the installation prefix of "Qt5Widgets" to CMAKE_PREFIX_PATH or set
"Qt5Widgets_DIR" to a directory containing one of the above files. If
"Qt5Widgets" provides a separate development package or SDK, be sure it has
been installed.

-- Configuring incomplete, errors occurred!
See also "/home/john/Desktop/munt-master/CMakeFiles/CMakeOutput.log".

Cant seem to find out what that qt5widget is. What munt version should I try? 1.5 or something else?

First, let's sort out if you want to use the Qt app. Even if Qt5 is unavailable in your configuration, you can also switch to use Qt4 by setting CMAKE property mt32emu-qt_WITH_QT5 to FALSE. Basically, package names in Linux distros is what I could never guess...

QtMobility (qtmobility-dev) appears to not be available in the current stable release. You can include the oldstable release by creating a file in /etc/apt/sources.list.d named debian-oldstable.list with the contents

1deb http://ftp.dk.debian.org/debian/ jessie main contrib non-free
2deb-src http://ftp.dk.debian.org/debian/ jessie main contrib non-free

Run update with apt-get then install the library.

Or just exclude mt32emu-qt and compile xmt32 and mt32d by modifying munt_WITH_MT32EMU_QT.

Well.... Got the missing packages installed.

Still have a problem though, and it is related to me not being a programmer. I simply have no clue on to how to write code.
So the thing about disabling QT5 in order to ude QT4, is something that I simply have no idea on how to do.
I have been searching within the files inside my "munt-master" directory, and I do not know what to look for and were.

So I guess, it is time to give this up. As I know just too little about coding in order to get this going. 🙁
I just wish that I was more of a programmer wizzard.

EDIT:
Should I try with an older version of Armbian? If so, then what version?

Try and see if CMake will work with Qt4 libraries.

Been digging around a bit, using google.
As I previously mentioned, I am not strong in programming, hence I need to use google a lot for these sort of things.
Just to clear it up, I need to change true to false in line 17 on this example here?
It might not be that exact same file that I am trying to compile, though this is the best example I can give
in explaining that I am not strong in programming...

https://github.com/munt/munt/blob/master/mt32 … /CMakeLists.txt

1) Cmake should use qt4 if it's installed and qt5 isn't.
2) Doing cmake -Dmt32emu-qt_WITH_QT5=FALSE ... (with all the rest as per the OP) should override the default, although you can run into trouble if options are cached.

Sergm, feel free to jump in if I have everything wrong. I'm by no means a guru with cmake.

@brostenen
You don't need to edit CMakeLists.txt in this case. This is only a matter of setting a configuration property. I listed 3 common ways of doing so in the README.txt, btw 😉

@gdjacobs
Nether am I 😀 But this looks totally correct. Best to always start with an empty cache if unsure.

However, I think it'd be a saner default behaviour to fall back to search for Qt4 in case Qt5 is unavailable.

Well, one thing is weird to me: why there is no Qt5? Perhaps, we should better figure the naming of Qt5Widgets and Qt5Multimedia dev packages instead. Qt4 seems to be completely unsupported for over 2 years, and Qt5 does provide a few tasty features I plan to use further on... Since this is a Debian based distro, I'd expect these packages to exist: qtbase5-dev and qtmultimedia5-dev. They seem to have proper binary packages as dependencies (libqt5widgets5 and libqt5multimedia5). Though, these well may have some screwed names 🙁

Hmmm.... I will test it out on sunday.
No time before that. 🙁

sergm wrote:

However, I think it'd be a saner default behaviour to fall back to search for Qt4 in case Qt5 is unavailable.

I definitely agree.

sergm wrote:

Well, one thing is weird to me: why there is no Qt5? Perhaps, we should better figure the naming of Qt5Widgets and Qt5Multimedia dev packages instead. Qt4 seems to be completely unsupported for over 2 years, and Qt5 does provide a few tasty features I plan to use further on... Since this is a Debian based distro, I'd expect these packages to exist: qtbase5-dev and qtmultimedia5-dev. They seem to have proper binary packages as dependencies (libqt5widgets5 and libqt5multimedia5). Though, these well may have some screwed names 🙁

As qtmobility was available, I didn't look further. I'll take another look using the qt5 dependencies and see how the cmake module responds.