VOGONS


First post, by mcobit

User metadata
Rank Member
Rank
Member

Hello,

I'm building a SoftSynth box with the Raspberry Pi 3 right now and want to share my progress in hope to get some input from you.
This video explains what is done so far:

https://youtu.be/_VYdw-AfNGc

20180206_114110.jpg
Filename
20180206_114110.jpg
File size
1.02 MiB
Views
5191 views
File license
Fair use/fair dealing exception
20180206_103622.jpg
Filename
20180206_103622.jpg
File size
1001.34 KiB
Views
5071 views
File license
Fair use/fair dealing exception
IMG_0002.JPG
Filename
IMG_0002.JPG
File size
516.19 KiB
Views
5244 views
File license
Fair use/fair dealing exception

2nd video:
https://youtu.be/gAG-GwYeTpc

1st video:
https://youtu.be/xWU0Lvn6ppg

Things done:
- throw prototype setup together
- Configure an USB soundcard for output as the Raspberry's analog out is not that good
- Configure a HD44780 compatible LCD with the RPLCD lib for use in python programs
- Connect some buttons for controlling everything as later there will be no hdmi monitor, keyboard or mouse. It should all be controlled with 4 buttons
- Write wrapper scripts in bash to start Munt in CM32L and MT32 mode as well as Fluidsynth server with a Soundfont and make sure that they always use port 128:0 for input
- Support for automatic search for soundfonts thrown into a directory (sf2 format)
- Set Raspberry's CPU governor to Performance all the time (might need a heatsink later on)
- Recompiled Munt and Fluidsynth with RP3 optimized CFLAGS and CXX Flags
- Build Gameport -> Midi out cable
- Build Midi interface board to use Raspberrys builtin uart for Midi in/out/through (probably test with a simple MIDI -> USB adapter first)
- automatically connect uart midi to port 128:0
- Build a box for all of that

I am open for questions and /or constructive criticism.
Also I will update this post when the next steps are finished.

Last edited by mcobit on 2018-02-17, 16:55. Edited 6 times in total.

Reply 1 of 57, by mcobit

User metadata
Rank Member
Rank
Member

I designed, etched and built a board based on some images from the web.

15169804802591909053162.jpg
Filename
15169804802591909053162.jpg
File size
904.9 KiB
Views
5356 views
File license
Fair use/fair dealing exception

It is a Gameport Midi splitter with Gameport through and Schmitt-Trigger Inverter buffer.
Works, but my Midi to USB cable is not working with Munt. It is working with GM though, so maybe it is just too shitty. May need to buy the original Roland one until I finish my UART midi board to directly interface the Pi.

Reply 2 of 57, by Auzner

User metadata
Rank Member
Rank
Member

Nice demo--so far this looks very cool! Thanks for sharing.
What's the rpi3 cpu load like?
In regards to the demo video, why does switching soundfonts during playback mess up the instrument mapping?
To switch soundfonts during playback, aplaymidi would have to be rewritten to reveal file_offset and also allow starting at a defined input offset?
When there is an input interface added, how would switching soundfonts during a stream differ?

Reply 3 of 57, by mcobit

User metadata
Rank Member
Rank
Member

As I understand it- the sysex messages setting reverb- instrument bank and other properties are sent once at the start of a midi track.
If I restart fluidsynth or munt during playback to switch soundfonts, it is not aware of these settings anymore until the midi starts and sends its settings again.

I only use aplaymidi for testing, but with a midistream from an mpu-401 interface it is the same behaviour.

For the CPU load, I have to check again. When I monitored it with aplaymidi it was up to 50%.
As said, I recompiled fluidsynth 1.1.9 with float support and rpi3 cflags. Before it would cut out after a while and produce garbeled sound in midifiles like the Duke Nukem Theme.

Reply 5 of 57, by mcobit

User metadata
Rank Member
Rank
Member

Tested (well, played through Monkey Island) today and seems to be rock stable with the usb midi interface and softmpu.
I tested a bit with direct uart midi in on the raspberry but it didn't work reliably.
Maybe my raspberry midiboard is not that good. There were problems while etching and I had to repair some tracks.

20180127_172520.jpg
Filename
20180127_172520.jpg
File size
1.02 MiB
Views
5297 views
File license
Fair use/fair dealing exception

Reply 6 of 57, by mcobit

User metadata
Rank Member
Rank
Member

Turns out the board was fine and I was just too stupid and didn't turn off the serial console on ttyAMA0. The different baudrates of Midi and terminal interfered but didn't completely stop it from working intermittendly.

One more thing learned.

Today I want to program a visualizer for the channels, notes and velocity with some APA102 leds. Let's see how this turns out...

Reply 7 of 57, by mcobit

User metadata
Rank Member
Rank
Member

New Video.

https://youtu.be/gAG-GwYeTpc

Now with experimental frontpanel and a connection from my P75's SB32 via mpu-401.
I installed a 20x2 lcd now instead of the 16x2. I want to display sysex messages from the munt emulator in the lower row later on and the mt32 had a 20x1 display, too.
The LEDs Indicate the Channels. The louder a note is, the brighter it will flash. Notes are indicated by color. Low: Green, Mid: Red, High: Blue.
Also the volume can be changed with the keys while not in edit mode.

Reply 8 of 57, by mcobit

User metadata
Rank Member
Rank
Member

Now I finished the box and put everything inside.
Redesigned the front a bit to accomodate a fourth button for reset and shutdown of the raspberry.

The "fixed" chinese midiinterface seems to do its job. For correct operation I have to restart munt before playing a new game though. But even sysex messages work.

20180206_114110.jpg
Filename
20180206_114110.jpg
File size
1.02 MiB
Views
5191 views
File license
Fair use/fair dealing exception
20180206_103622.jpg
Filename
20180206_103622.jpg
File size
1001.34 KiB
Views
5191 views
File license
Fair use/fair dealing exception
20180206_103601.jpg
Filename
20180206_103601.jpg
File size
756.4 KiB
Views
5191 views
File license
Fair use/fair dealing exception

I will do another video when I find some time.

Reply 9 of 57, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

This is a really cool project (and congrats for getting it working). I am interested in building one myself. Few questions below.

mcobit wrote:

- Configure an USB soundcard for output as the Raspberry's analog out is not that good

May I ask what USB soundcard you used?

mcobit wrote:

- Connect some buttons for controlling everything as later there will be no hdmi monitor, keyboard or mouse. It should all be controlled with 4 buttons

How do you redirect buttons (read from input pins) to MUNT/volume controls?

mcobit wrote:
- Write wrapper scripts in bash to start Munt in CM32L and MT32 mode as well as Fluidsynth server with a Soundfont and make sure […]
Show full quote

- Write wrapper scripts in bash to start Munt in CM32L and MT32 mode as well as Fluidsynth server with a Soundfont and make sure that they always use port 128:0 for input
- Support for automatic search for soundfonts thrown into a directory (sf2 format)
- Set Raspberry's CPU governor to Performance all the time (might need a heatsink later on)
- Recompiled Munt and Fluidsynth with RP3 optimized CFLAGS and CXX Flags

As someone asked before does it look like the RPi3 can deal performance wise? However since you said that aplaymidi was only using 50%, and you playtested with Monkey Island, I presume all is fine.

mcobit wrote:

- Build Gameport -> Midi out cable
- Build Midi interface board to use Raspberrys builtin uart for Midi in/out/through (probably test with a simple MIDI -> USB adapter first)
- automatically connect uart midi to port 128:0

The last 3 steps are so that you go from gameport to UART on the RPi3 right? Can you not go from Gameport to one of the USB ports on the RPi3 ? You have 2 USBs so you could use one for the USB sound card and one for Midi input. I think I could easier find a gameport to midi (those are quite available) and can you not go from MIDI to USB (also using an off the shelf cable)? Does MUNT support midi input via USB?

mcobit wrote:

The LEDs Indicate the Channels. The louder a note is, the brighter it will flash. Notes are indicated by color. Low: Green, Mid: Red, High: Blue.

What did you have to write to support that?

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 10 of 57, by mcobit

User metadata
Rank Member
Rank
Member

There are some things that I changed:
I don't use an usb soundcard anymore. The cheap stuff you see in the first videos gave me buffer problems and distorted sound. All that is fixed by using the onboard sound. I decided that the relatively noisy and compressed sounding onboard sound of the raspberry would fit perfectly with the soubd of older soundcards that are not much better in this regard anyway.
Not that more expensive usb soundcards could not be better, but I wanted to keep it as cheap as possible.

The rpi is ok performance wise. Munt uses one core at about 50-80%.

Fluidsynth for GM can vary with the soundfonts you are using. It may spike up to 100% and could miss a note or two then, but with sf2 of the size up to 500MB it is fine.
You cannot load sf2 files larger than about 800MB because of ram limitations of the pi.

For the rest of the software I will give a rundown tomorrow. There I will also explain how I get the inputs going and the leds to light.

I am not using the uart of the rpi anymore as the sysex messages were a problem even with the patched ttymidi.

I am using a cheap chinese usb midi interface cable I modified to adhere to the midi hw standards by putting a diode, resistor and optocoupler as well as a capacitor to the prepared but not populated spaces on the board and I removed a bridge resistor. Unisolated stuff may not be the best to plug into retro gear anyway.
There are a lot of sites online dealing with those modifications.
If money is not inportant you can get a roland um one mk2. That will work out of the box.
You can also use a bought gameport to midi cable. I just like doing stuff myself for selfeducation and fun. Also I don't think the standart ones are buffered.

Stay tuned for the software stuff tomorrow. I used python for most of that.

Reply 11 of 57, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

DId you use raw ALSA or a sound server? Also, what polyphony are you running in Fluidsynth? I reduce this to avoid sound buffer under runs.

As far as MT-32 message SYSEXs, I modified mt32d to display them on a 16x2 (will be 20x2) LCD display via WiringPi.

All hail the Great Capacitor Brand Finder

Reply 12 of 57, by mcobit

User metadata
Rank Member
Rank
Member

Yes. I also display them in the lower line of the lcd as you can see in the photo with spacequest 3 running.
I did not lower any polyphony settings or alter anything else in fluidsynth and I run on raw alsa hardware device as that is what fluidsynth suggests for best performance.
Also this is a custom fluidsynth 1.1.9 build with all the raspberry cflags and most unnecessary things removed.

I will post the libraries I used for the lcd and leds as well as the full python code tomorrow. I split the various tasks into multiole python scripts to distribute them over the cores of the raspberry.

Reply 13 of 57, by mcobit

User metadata
Rank Member
Rank
Member

Almost forgot: here is a picture of the inside. With connected lan cable for debugging and also the cable management is not final 😉

20180206_094853.jpg
Filename
20180206_094853.jpg
File size
1.29 MiB
Views
5157 views
File license
Fair use/fair dealing exception

Reply 14 of 57, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

What is the power supply you are using?

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 15 of 57, by tpowell.ca

User metadata
Rank Member
Rank
Member

Great work. That really looks awesome, and I love the wooden case.
I tried to get something similar working myself based on a previously posted rpi2 project, but kept getting annoyed at the midi ports changing randomly at each bootup for some reason.

I must admit that I just don't know linux well enough.

Maybe you could post a compressed disk image of the final build?

Cheers

  • Merlin: MS-4144, AMD5x86-160 32MB, 16GB CF, ZIP100, Orpheus, GUS, S3 VirgeGX 2MB
    Tesla: GA-6BXC, VIA C3 Ezra-T, 256MB, 120GB SATA, YMF744, GUSpnp, Quadro2
    Newton: K6XV3+/66, AMD K6-III+500, 256MB, 32GB SSD, AWE32, Voodoo3

Reply 17 of 57, by mcobit

User metadata
Rank Member
Rank
Member
tpowell.ca wrote:
Great work. That really looks awesome, and I love the wooden case. I tried to get something similar working myself based on a pr […]
Show full quote

Great work. That really looks awesome, and I love the wooden case.
I tried to get something similar working myself based on a previously posted rpi2 project, but kept getting annoyed at the midi ports changing randomly at each bootup for some reason.

I must admit that I just don't know linux well enough.

Maybe you could post a compressed disk image of the final build?

Cheers

Yes, I can do that. But I need to clean it up a lot before doing so. This image is quite messy because of experimentation.
The ports normally don't change if you give the applications time to close properly. I have code in place to watch what application gets what ports and if they are restarted properly.

Reply 19 of 57, by mcobit

User metadata
Rank Member
Rank
Member

Right now I am starting/killing processes.
Also helps with hanging notes if a specific synth doesn't get a note off after switching.
Having all synths running seems too resource hungry and more unreliable.