Oh my... it's going to be my second favourite project after the ARGUS! Following the thread from now on!

BloodyCactus wrote:

how are you reading midi? is it external fed into the pi uart?

Nope... I'm aware of the timing and other issues with attempting to use a GPIO pin for MIDI I/O, even a UART on the RPi at non-standard baud rate, and intend to use an Atmega 328 dedicated for that purpose, connected to the Raspberry Pi (or whatever SoC I end up using) UART. I use an Atmega 328 as a MIDI interface on my computer now and it works fantastically.

BloodyCactus wrote:

the onboard audio is really bad to the point one shouldnt use it.

BloodyCactus wrote:

i _ASSUME_ the wavetable l/r output pins are analogue sound...

d0pefish wrote:

I totally agree with disregarding the internal audio - it is dreadful.

The L/R pins on the Wavetable are definitely analog... they go right into a dedicated mixer channel on the sound card (usually). And yeah, I thought about this, and this is one of the items I've counted against using a Raspberry Pi (or, more specifically, the Broadcom BCM2835) for this purpose. In all of the Raspberry Pis the audio out comes off of a filtered PWM output... limited, and not the greatest sound quality for sure. The other SoC I'm looking at (Allwinner H2+) includes a built-in 24-bit DAC with 92dB noise floor... pretty respectable. This is yet another reason to use that SoC rather than the Broadcom, even if the Broadcom has the compute power required (which I'm still not 100% sure at this point).

BloodyCactus wrote:

Id also suggest pulse then you get the whole world of jackd/midictrl and mapping and such.

Wayyy too much overhead and complication. I have to write a custom shim/glue software anyway to interface the Atmega chip to ALSA, as well as the custom host-chip user interface I want to write, so this program will also manage the necessary ALSA patches as required for MUNT.

BloodyCactus wrote:

http://members.chello.nl/~g.lammertink/Techni … vetabl/wave.htm

I've seen a lot of resources related to the WaveBlaster header, but not this one. This looks great. Thanks!

d0pefish wrote:

I'm using a USB MIDI interface, so I'm not hitting the GPIO, and the speed issues are there when outputting with internal audio and USB audio (I have a few different kinds of USB audio device).

The USB MIDI interface might be the issue. Unless you are using a really high end one like a Mark of the Unicorn, or good Roland, buffer and timing issues could be the culprit. This is one of the reasons why I developed my own using an Atmega 328.

RJDog wrote:

d0pefish wrote:

I'm using a USB MIDI interface, so I'm not hitting the GPIO, and the speed issues are there when outputting with internal audio and USB audio (I have a few different kinds of USB audio device).

The USB MIDI interface might be the issue. Unless you are using a really high end one like a Mark of the Unicorn, or good Roland, buffer and timing issues could be the culprit. This is one of the reasons why I developed my own using an Atmega 328.

Have you published information about your homemade MIDI interface somewhere?

Another option would be integrating an FTDI bridge chip to provide the UART via USB. These have been successfully used for MIDI on Pis in the past.

Kamerat wrote:

Have you published information about your homemade MIDI interface somewhere?

Yes and no; I have a half-written blog post about all of the ways I tried to hook up MIDI to my host computer and settling on the Atmega 328, but I just haven't had the cycles to complete it. I'll update in this thread once I finish it hopefully in a day or two.

gdjacobs wrote:

Another option would be integrating an FTDI bridge chip to provide the UART via USB. These have been successfully used for MIDI on Pis in the past.

I have thought of this, and have a FT232RL on order just to test exactly this. The FT232RL has 32kB of buffer so I am hopeful.

RJDog - Take a look at the USER header on the HardMPU schematic- This might be a good use case?

I have been pondering a project like this for a while but only as a GM wavetable option

my thought was a board that goes from wavetable to pi gpio

it could provide power to the pi over the gpio from the sound card, midi to its uart port and then redirect the audio out to the gpio pins on the pi and route it back to the audio in on the wavetable header.

the audio quality on the pi is vastly improved by using the optional alternate audio driver they released a while back, pretty much completely removes the hiss.

my plan for setting up the pi was read only file system on the pi to avoid corruption when the power was cut and have timidity look for the soundfont on the fat32 boot partition. my testing showed a $5 pi zero would be able to handle an 8meg soundfont like 8mbgmsfx.sf2 from the alsa website just fine.

I'm going to sketch up a PCB and get a minimum order made up because i want one for me 🤣 it will probably be 10pcbs and i doubt i will need more than 2 of them. i was going to design the pcb over my christmas holiday break but then Zelda on the mini nes happened.

Super_Relay wrote:

it will probably be 10pcbs and i doubt i will need more than 2 of them

You should check out OSH Park (https://oshpark.com)... pretty sure that's who I'm going to order through, and reviews are good. $5/sq.in of your design which includes 3 pcbs. Biggest complaint I've read is they're slow, which is okay for me.

ospark is expensive once you get over like an inch by an inch. I go seeed studio for my larger boards.

BloodyCactus wrote:

ospark is expensive once you get over like an inch by an inch. I go seeed studio for my larger boards.

Fair enough. I've heard of seeed studio, just don't know enough about them. OSH would be about $70 to get the two boards I need for what I want to do, so it might be beneficial to look somewhere else anyway.

ab0tj wrote:

Take a look at the USER header on the HardMPU schematic- This might be a good use case?

Yes, I noticed that before; I think this would be exactly a use case for it. I may have to put a mating header on my card to plug into it... I'll see if that makes sense.

BloodyCactus wrote:

ospark is expensive once you get over like an inch by an inch. I go seeed studio for my larger boards.

Speaking from experience, seeed is quicker, too.

I think I've convinced myself that powering the unit completely from the WaveTable header or from the DB15 gameport connector is going to be impractical.. unless the Raspberry Pi Zero works out, but I'm not holding my breath. So there's going to be an external power connector -- either floppy power connector (those connectors are cheap) if used as a WaveBlaster card, or external power supply if used as standalone external module.

The other sort-of bonus is, at least during this prototyping phase, the Orange Pi Zero and the Raspberry Pi Zero both have (not coincidentally, on their respective developers' parts) the same GPIO pin-out... meaning one board design = two SoC tests.

If external power is looking like an option, I recommend using a board with at least a Cortex A7 based CPU. NEON gives a significant boost with Munt and is shown to make real time MT-32 emulation possible. A lower powered CPU might also work by offloading some workload to coprocessor units (such as PRU, C6000, etc).

gdjacobs wrote:

I recommend using a board with at least a Cortex A7 based CPU. NEON gives a significant boost with Munt and is shown to make real time MT-32 emulation possible.

Well, I have intentionally chosen the Orange Pi Zero (Allwinner H2+) which is Cortex A7. 😊 I know it will work with this board. The Raspberry Pi Zero is ARMv6, which I am not 100% sure will work but I am hopeful.

I have an Orange Pi PC and FluidSynth would not work well for me. I used Armbian as OS and the MIDI playback was kind of laggy and "off".

It worked flawless on the Pi. I did a write-up on the installation process here a while ago.

The Orange Pi does make a cool retro gaming machine, now with Lakka and RetrOrangePi images available 😀

I'm sure it can be made working, but Linux is just not my thing, if it doesn't work with minimal effort, I give up 😊

PhilsComputerLab wrote:

I have an Orange Pi PC and FluidSynth would not work well for me. I used Armbian as OS and the MIDI playback was kind of laggy and "off".

Now you make me sad 😵 but as mentioned before, I have pretty good experience with embedded Linux, and buildroot was suggested as well that looks promising (I haven't looked yet to see if it can be adapted to the OrangePi but I assume it can) so I am pretty hopefull, but this makes me all the less sure it will work with the Raspberry Pi Zero.

On a related-not-related note, I need a name to call this thing... I don't think I can keep calling it "MT32 WaveBlaster Card" ...?

If it's ok with you, I can merge with the existing "Munt on Pi" thread and move it to Sound?

As for my attempts: http://www.philscomputerlab.com/general-midi- … spberry-pi.html

A pretty detailed write-up of all the steps. I even have a video which I will publish at some point 😀

With the Pi at least it worked flawless and sounded mint!

PhilsComputerLab wrote:

If it's ok with you, I can merge with the existing "Munt on Pi" thread and move it to Sound?

Yeah, I followed that thread pretty closely; definitely good work. My attempts here are to essentially productize that idea into a unique form factor. I don't disagree with merging the two... for sure both belong in Sound.

RJDog wrote:

PhilsComputerLab wrote:

If it's ok with you, I can merge with the existing "Munt on Pi" thread and move it to Sound?

Yeah, I followed that thread pretty closely; definitely good work. My attempts here are to essentially productize that idea into a unique form factor. I don't disagree with merging the two... for sure both belong in Sound.

Looks like I can't because it's outside of Marvie 🤣

Idea for the project's name: "MuntBoard" since you are essentially making a MUNT daughterboard 😁