VOGONS


Emulating MT-32 on an RPi2

Topic actions

Reply 200 of 292, by Srandista

User metadata
Rank Oldbie
Rank
Oldbie

I remember, that I receive error during compilation of 2.3.0 a while ago, so I stayed on 2.2.0. Did you have same problem, or all went smoothly?

Last edited by Srandista on 2019-08-10, 06:10. Edited 1 time in total.

Socket 775 - ASRock 4CoreDual-VSTA, Pentium E6500K, 4GB RAM, Radeon 9800XT, ESS Solo-1, Win 98/XP
Socket A - Chaintech CT-7AIA, AMD Athlon XP 2400+, 1GB RAM, Radeon 9600XT, ESS ES1869F, Win 98

Reply 202 of 292, by appiah4

User metadata
Rank l33t++
Rank
l33t++

2.3.0 was butter smooth. I compiles on Debian 10. QtMobility is no longer in repo for that, but I'm not using the GUI just the daemon called from rc.local at boot, so it wasn't an issue.

I haven't tried with the USB MIDI but it should work fine with a simple aconnect between that and mt32d. I will add the “sleep 5” and the aconnect line to rc.local to automate it.

Retronautics: A digital gallery of my retro computers, hardware and projects.

Reply 203 of 292, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

If you can craft a udev rule that does the aconnect for you, you'll probably be able to dispense with the sleep delay. Similarly, running everything through 14:0 eliminates timing issues with the USB interface or mt32d coming up.

All hail the Great Capacitor Brand Finder

Reply 204 of 292, by Srandista

User metadata
Rank Oldbie
Rank
Oldbie
appiah4 wrote:

QtMobility is no longer in repo for that, but I'm not using the GUI just the daemon called from rc.local at boot, so it wasn't an issue.

This part of the guide wasn't updated on RetroPie, but you can use qtmultimedia5-dev instead as mentioned in OP.

Socket 775 - ASRock 4CoreDual-VSTA, Pentium E6500K, 4GB RAM, Radeon 9800XT, ESS Solo-1, Win 98/XP
Socket A - Chaintech CT-7AIA, AMD Athlon XP 2400+, 1GB RAM, Radeon 9600XT, ESS ES1869F, Win 98

Reply 205 of 292, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

I used the Pi 3 base image for Devuan 2.0[1] and compiled with the dependencies listed in the OP. Everything worked swimmingly -- although my wall adapter was acting stupidly, but that's another story.

[1] Download devuan_ascii_2.0.0_arm64_raspi3.img.xz from https://files.devuan.org/devuan_ascii/embedded/

All hail the Great Capacitor Brand Finder

Reply 206 of 292, by appiah4

User metadata
Rank l33t++
Rank
l33t++
gdjacobs wrote:

If you can craft a udev rule that does the aconnect for you, you'll probably be able to dispense with the sleep delay. Similarly, running everything through 14:0 eliminates timing issues with the USB interface or mt32d coming up.

I'm unfortunately not well equipped to do this but I started looking at this: https://linuxconfig.org/tutorial-on-how-to-wr … -rules-in-linux

I guess I need to add a udev role that does the aconnect once mt32d is started and the USB MIDI interface modules are loaded?

Srandista wrote:
appiah4 wrote:

QtMobility is no longer in repo for that, but I'm not using the GUI just the daemon called from rc.local at boot, so it wasn't an issue.

This part of the guide wasn't updated on RetroPie, but you can use qtmultimedia5-dev instead as mentioned in OP.

Ah, makes sense I guess. It was probably installed by default on Buster.

Retronautics: A digital gallery of my retro computers, hardware and projects.

Reply 207 of 292, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
appiah4 wrote:

I guess I need to add a udev role that does the aconnect once mt32d is started and the USB MIDI interface modules are loaded?

If you use the MIDI-through device, mt32d doesn't have to be started when you connect the USB MIDI interface.

All hail the Great Capacitor Brand Finder

Reply 208 of 292, by appiah4

User metadata
Rank l33t++
Rank
l33t++
gdjacobs wrote:
appiah4 wrote:

I guess I need to add a udev role that does the aconnect once mt32d is started and the USB MIDI interface modules are loaded?

If you use the MIDI-through device, mt32d doesn't have to be started when you connect the USB MIDI interface.

SMH.. SO I aconnect the USB Midi to Midi Through (14:0?).. And how does that connect to MT32D (128:0) exactly?

Retronautics: A digital gallery of my retro computers, hardware and projects.

Reply 209 of 292, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

You connect 14:0 to MT32D. Both links can be established independent of each other, so you don't need to worry about the other side of the equation when adding a device or synth.

All hail the Great Capacitor Brand Finder

Reply 210 of 292, by ElBartoME

User metadata
Rank Newbie
Rank
Newbie

Hey everybody,

I've been a lurker for quite some time but today I decided to register as I have a problem.

Recently I found my old Intel Pentium PC in the attic of my fathers home and I decided to bring it back to life. It still works fine but didn't have a sound card. So I boughta ESS1868 soundcard and it also works fine. I always wanted a MT32 but the prices seem quite steep nowadays so I decided to go with Munt on a Raspberry Pi 3B+.

I got myself the Raspberry, compiled Munt and it works more or less. I decided to use the serial input of the Raspberry for the midi input together with ttymidi. That seems to work as well. But I got a problem:

Everything works fine if I boot up the Pi and then log in via ssh and start Munt and ttymidi and use aconnect to connect the output of ttymidi to the input of Munt manually by typing the commands by hand. But of course I don't want to do that every time. So I made a script that will do that for me and launch that script during boot. When I boot the Pi now I see that ttymidi and mt32d is running but when I now play something I see the CPU load immediately going to 100% and the Pi more or less locks up. If I kill ttymidi and mt32d and start it again it works perfectly. I have no idea what the problem might be. I put a delay in my script but that didn't help either.

Does anybody have an idea what might cause the problem?

Thanks!

Reply 211 of 292, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Are you trying to SSH to the Pi? That's going to be tough if you have pegged CPUs. What if you install htop first then send it a MIDI stream? You might learn if ttymidi or Munt are going nuts.

All hail the Great Capacitor Brand Finder

Reply 212 of 292, by ElBartoME

User metadata
Rank Newbie
Rank
Newbie

Yes, I'm on the Pi via SSH and use top to see the CPU load.

I found that if I start mt32d and ttymidi manually right after the Pi booted the same problem happens. It seems I have to wait some minutes. After that mt32d and ttymidi seem to work correctly.

Is it normal to wait that long?

By the way: Munt and ttymidi both are going crazy as the load for both processes is very high (funnily enough it sometimes shows a load of >100%). If everything works the load from ttymidi is <5% and Munt ~40 - 50%.

I also have another unrelated topic. I'm planning to hook up a I2C 16x2 display to the Pi and display messages from Munt on it. You planned implementing that feature. Looking into the code I see some code for a LCD display but I guess that's for the simulated one. I would like to extend the code in order to enable Munt talking directly to the display.

Reply 213 of 292, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Yes, I patched in support for serial displays via WiringPi, although it's in no way ready for upstream, nor will I stay with that approach, I think. Others have implemented a sniffer process that monitors the MIDI port for the appropriate SYSEX messages which doesn't require coordination with Munt upstream. This is the approach I recommend.

CPU load more than 100% is possible for top as the RPi >= 2 is multicore. Still, it's unusual that it takes so long to stabilize. One gotcha with the RPi 3 is the relationship between Bluetooth support and the serial UARTs. Definitely make sure that both Bluetooth hardware and Linux Bluetooth system services are disabled given that the UART will be reclocked for MIDI input.

All hail the Great Capacitor Brand Finder

Reply 214 of 292, by ElBartoME

User metadata
Rank Newbie
Rank
Newbie

I like the approach to monitor the MIDI stream. I then may do the monitoring in Python as I also want to implement some other features that are not necessarily connected to Munt. Thanks for the tip.

I know that the UART for Bluetooth is changed in order to be able to get the baud rate for MIDI. I will disable Bluetooth completely and see if that helps.

Reply 215 of 292, by ElBartoME

User metadata
Rank Newbie
Rank
Newbie

Unfortunately it didn't really help.

I just found another problem with ttymidi. If I read correctly ttymidi does not support SysEx messages. So I have to find another solution...

EDIT: I was able to modify ttymidi so it handles SysEx messages correctly. Now Monkey Island sounds correct as it should! I was wondering all the time why the sound seemed off. If anyone is interested I can upload the code to Github.

Reply 217 of 292, by ElBartoME

User metadata
Rank Newbie
Rank
Newbie

I think I found the culprit.

I had to disable the serial port terminal shell like it is described here: https://www.cube-controls.com/2015/11/02/disa … ut-on-raspbian/

After that it works if I start my script after a restart.

Reply 219 of 292, by appiah4

User metadata
Rank l33t++
Rank
l33t++
gdjacobs wrote:

You connect 14:0 to MT32D. Both links can be established independent of each other, so you don't need to worry about the other side of the equation when adding a device or synth.

Great success 😀

MUNT-Pi3-01.jpg MUNT-Pi3-02.jpg

Retronautics: A digital gallery of my retro computers, hardware and projects.