VOGONS


Crazy Idea - MT32 WaveBlaster Card

Topic actions

First post, by RJDog

User metadata
Rank Member
Rank
Member

So, inspired by the HardMPU project undertaken by ab0tj, as well as the likes of Dreamblaster and especially the recent discussions around the use of a Raspberry Pi 3 as a MUNT host, I have decided to develop and produce (at least some prototypes) an MT-32 WaveBlaster Card.

No, the plan is not to simply attach a Raspberry Pi 3 to the WaveBlaster header... my plan is slightly more involved, but I will admit the thought crossed my mind. I am currently debating between a Broadcom BCM2835 (aka. Raspberry Pi Zero) and Allwinner H2+ (aka. Orange Pi Zero) as the core CPU/SoC. Definitely a Atmega 328 or similar as a MIDI interface, although I will probably try wiring the MIDI signal directly to the SoC, just to see how that works out. Based on my readings, I can expect about 500mA to be available to the card from the WaveBlaster header, which is nothing to shake a stick at, but can be a limiting factor, hence the choice in processor. The Broadcom sips a mere 50-100mA (depending on configuration) where the Allwinner consumes 200-400mA (again, depending on configuration), but the Allwinner has a much better audio output than the Broadcom. The Allwinner also is a quad core... Broadcom a single core, but otherwise nearly identical ARM processor. MUNT is not a particularly multi-threaded process, so I'm not sure if that's much of a deciding factor.

I thought about making a standalone MIDI unit... essentially a modern made MT-32 (albeit somewhat emulated)... but after thinking about it I think the WaveBlaster card is both more challenging (a good thing, in my books) and more versatile. One could simply use a unit like Dreamblaster's WaveBlaster Module MIDI Interface Board to turn it into a standalone unit and, when used as a WaveBlaster board attached to a compatible sound card, it all fits neatly inside your computer case.

I think the really ambitious part of this project is how I'm hoping to allow the user to interact with the card. I could go the same route as the Dreamblaster X2 and provide a USB interface to manipulate files and configuration (which, by the way, very clever, props to Dreamblaster), but I believe I can get it to work via special MIDI SysEx messages from the host system itself (a special interface program would be required on both the host system and card, of course).

One of the main things that would need to be able to be accomplished through the host-card interface is the ability to upload ROM files to it. I'm not 100% sure, but I think there would be some questionable legal issues distributing Roland ROM files with the card.

Anyway, that's my retro-oriented activity that I think is going to occupy me for the next couple of months. Look forward to your thoughts and suggestions.

Reply 1 of 100, by dreamblaster

User metadata
Rank Oldbie
Rank
Oldbie

Excellent idea !!!!

Visit http://www.serdashop.com for retro sound cards, video converters, ...
DreamBlaster X2, S2, S2P, HDD Clicker, ... many projects !
New X2GS SE & X16GS sound card : https://www.serdashop.com/X2GS-SE ,
Thanks for your support !

Reply 2 of 100, by keropi

User metadata
Rank l33t++
Rank
l33t++

really interested to see how this turns out to be, it's a great idea! keep us posted!

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 3 of 100, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

I suspect that the Pi Zero will not be capable of emulating the MT-32 without substantial software development. A Cortex A7 can manage this using Munt, so maybe you can look in that direction?

All hail the Great Capacitor Brand Finder

Reply 4 of 100, by PhilsComputerLab

User metadata
Rank l33t++
Rank
l33t++

Most Roland MPU interfaces don't have a wavetable header though. I would love to see something like the NES mini, but for MT-32.

The display is part of the experience too.

YouTube, Facebook, Website

Reply 5 of 100, by RJDog

User metadata
Rank Member
Rank
Member
PhilsComputerLab wrote:

The display is part of the experience too.

Yeah, I thought that too. Maybe I'll make a WaveBlaster card, and then a custom enclosure the card can be inserted into to make it a standalone unit with MIDI interfaces and LCD..?

Reply 6 of 100, by RJDog

User metadata
Rank Member
Rank
Member
gdjacobs wrote:

I suspect that the Pi Zero will not be capable of emulating the MT-32 without substantial software development. A Cortex A7 can manage this using Munt, so maybe you can look in that direction?

I'm a little afraid of this as well... I plan on initially trying the Pi Zero to see if I can get it to work, as that is by far the most power concious option. Barring that, I'll try the Orange Pi Zero, which is Cortex A7, and go from there. Anything more I'm afraid I'll get over 500mA.

Reply 7 of 100, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

Why not get a coder involved right now?
Having the emulator run bare bones pretty much any semi-recent RasPi should be enough. This would also help with a potentially 'long' bootup time.

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 8 of 100, by keropi

User metadata
Rank l33t++
Rank
l33t++

I don't see why power is an issue in an internal device - just use a floppy/hdd style molex and problem is solved...

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 9 of 100, by RJDog

User metadata
Rank Member
Rank
Member
shock__ wrote:

Having the emulator run bare bones pretty much any semi-recent RasPi should be enough. This would also help with a potentially 'long' bootup time.

I think so too, which is why I'd like to try the Broadcom/RaspPi Zero first and then have the Allwinner H2+ Cortex A7 as second choice. Good thing I'm a Linux developer by trade! 😎

keropi wrote:

I don't see why power is an issue in an internal device - just use a floppy/hdd style molex and problem is solved...

Yeah, this did cross my mind, and am buying the parts to prototype this method as well, but my thought process is about trying to keep this as simple and self-contained as possible though, and potentially useful with other external modules like the Dreamblaster's WaveBlaster Module MIDI Interface Board... although that said, my idea for bidirectional host-card communication through MIDI SysEx messages wouldn't work with the WaveBlaster Module MIDI Interface Board anyway, so... I dunno.

Bottom line, still trying to flush this out, so these suggestions are quite welcome.

Reply 10 of 100, by badmojo

User metadata
Rank l33t
Rank
l33t
PhilsComputerLab wrote:

I would love to see something like the NES mini, but for MT-32.

This would be the way to go IMO - in my mind a wavetable header is for a GM device, and doesn't really appear on sound cards of the MT-32 era. It would also mean you had to choose b/w your fave GM daughterboard and MT-32 (or physically switch 'em); better to leave the wavetable header for GM and keep any MT-32 device as external me thinks.

Life? Don't talk to me about life.

Reply 11 of 100, by RJDog

User metadata
Rank Member
Rank
Member
badmojo wrote:

This would be the way to go IMO - in my mind a wavetable header is for a GM device, and doesn't really appear on sound cards of the MT-32 era. It would also mean you had to choose b/w your fave GM daughterboard and MT-32 (or physically switch 'em); better to leave the wavetable header for GM and keep any MT-32 device as external me thinks.

I don't disagree with this viewpoint. I have toyed with the idea that you could switch the module from "MT-32 mode" to "GM mode" using tmidity++ or something providing thr ability to upload user SoundFonts... and I still might, but I think for now the focus will be to get MT-32 mode going. I think your point about people have their favorite (non emulated) WaveBlaster card is a valid one.

I think based on this and Phil's comment, I might gear it towards a WaveBalster card (for some reason this idea is sticking with me, but I'm getting less convinced) with an external stand-alone housing the card can be inserted into to provide the famed LCD and standard MIDI interfaces.

One of the reasons I'd like to keep it under 500mA draw is that it could be powered entirely by the host's DB15 gameport connector without the need for external power supply. I'm not hard set on that idea but I think it would be neat.

Reply 12 of 100, by brostenen

User metadata
Rank l33t++
Rank
l33t++
shock__ wrote:

Why not get a coder involved right now?
Having the emulator run bare bones pretty much any semi-recent RasPi should be enough. This would also help with a potentially 'long' bootup time.

I have absolutely no idea on what I am about to say... How about porting munt on a barebone linux kernel?
(this might not be possible)

Don't eat stuff off a 15 year old never cleaned cpu cooler.
Those cakes make you sick....

My blog: http://to9xct.blogspot.dk
My YouTube: https://www.youtube.com/user/brostenen

001100 010010 011110 100001 101101 110011

Reply 13 of 100, by RJDog

User metadata
Rank Member
Rank
Member
brostenen wrote:

How about porting munt on a barebone linux kernel?
(this might not be possible)

Essentially what I feel I will need to do in oder to get it to run well on the RaspPi Zero is to have running the Linux kernel, and only what is required for it, and then the only user space applications that will be running is MUNT, ALSA, and my modified ttymidi for host-card control and monitoring; probably a shell running on ttyS0, but definitely nothing beyond that (especially nothing related to X or any GUI). I may have to modify MUNT to decouple it from Qt (and therefore decouple it from X) but there is a library version of MUNT that may prove useful in this regard.

EDIT: Even then I'm not sure how well it will run..Time to get started I guess...

Reply 14 of 100, by keropi

User metadata
Rank l33t++
Rank
l33t++

Isn't there a thread here about munt and Pi boards? IIRC only the Pi3 is powerful enough for it...

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 15 of 100, by d0pefish

User metadata
Rank Newbie
Rank
Newbie

I can probably help give you a head-start on this on the software side.

I've put together a MUNT/Raspberry Pi 2 system with Buildroot, which is a tool that lets you easily create embedded Linux distributions stripped down to the bare minimum and customised however you like it. With it, you can create a small SD card image that boots a Pi in about 5 seconds to a working MUNT.

I've got it so that you can download Buildroot, clone a Git repository, put some MT-32 ROMs into a designated folder, run 'make', and a flashable SD card image is produced. It takes quite a while to build because the entire toolchain and system needs to be compiled, but subsequent modifications are faster. It makes building a totally custom Linux very straightforward.

It needs work to deal with MIDI ports, sound output device (e.g. when using USB audio and MIDI interfaces) - but it's a good starting point. I'm wanting to get the latency down to the absolute minimum possible, and there's even the option of using a PREEMPT_RT (realtime) kernel, but I'm having pretty good results without that so far.

My intention was to make a standalone 'appliance' type setup with a 3.2" LCD touchscreen sitting on top of the Pi to act as a UI and control method for MUNT, but you can simply omit this for an internal Waveblaster project.

I'll put this project up on GitHub shortly - I got sidetracked with University exams (still ongoing 🙁)

US1wUaR.pngg
💾 Download | 📚 Documentation | Support

Reply 16 of 100, by RJDog

User metadata
Rank Member
Rank
Member
keropi wrote:

Isn't there a thread here about munt and Pi boards? IIRC only the Pi3 is powerful enough for it...

Yes, this thread was quite recent and I've followed it quite closely. The requirement for using the Pi3 was I think both out of convenience as well as necessity, as the people that were trying this out were running default Rasbian images with full GUI, other applications simultaneously, etc.. A full GUI (nor default Rasbian image) is required in this case. I'm reasonably confident it will run sufficiently on a Raspberry Pi Zero using an extremely cut-down image. But, as mentioned in the original post, I am not putting all my eggs in one basket, so to speak; I will also try the Orange Pi Zero (Allwinner H2+ Cortex A7) which I am sure will run MUNT without breaking a sweat, especially on a cut-down image.

d0pefish wrote:

I've put together a MUNT/Raspberry Pi 2 system with Buildroot, which is a tool that lets you easily create embedded Linux distributions stripped down to the bare minimum and customised however you like it. With it, you can create a small SD card image that boots a Pi in about 5 seconds to a working MUNT.

I have quite a bit of experience with assembling custom Linux installations for both embedded and non-embedded deployments, so I'm pretty confident in my own ability, however I've not ever used Buildroot (I only have one Raspberry Pi that I've played with so far). I'm curious to try it now to see how it compares to what I would do manually. My suspicion is that it would be about the same, maybe a bit better. I'm interested to see what your build looks like as well; if MUNT runs well on the Raspberry Pi 2, that makes me all the more confident it will run well on the Zero.

Reply 17 of 100, by d0pefish

User metadata
Rank Newbie
Rank
Newbie
RJDog wrote:

I have quite a bit of experience with assembling custom Linux installations for both embedded and non-embedded deployments, so I'm pretty confident in my own ability, however I've not ever used Buildroot (I only have one Raspberry Pi that I've played with so far). I'm curious to try it now to see how it compares to what I would do manually. My suspicion is that it would be about the same, maybe a bit better. I'm interested to see what your build looks like as well; if MUNT runs well on the Raspberry Pi 2, that makes me all the more confident it will run well on the Zero.

Fair enough. I'd highly recommend looking at Buildroot, it is very flexible, and you can structure your project so that it's easy to maintain. You can start with a basic Pi kernel and that gets you a bootable BusyBox image, and work from there, selecting what gets built, adding things to your rootfs, changing kernel config, and so on. I added custom packages to pull in MUNT and build the command-line daemon with the toolchain (I don't build any GUI stuff at all in this).

There are template configs in Buildroot for all Pi models including Zero.

Here's what I have so far. It's just a proof of concept, and I've listed some notes in the README:
https://github.com/dwhinham/mt32-pi

Current problem is that MIDI note timing is off; the sound generation itself doesn't experience any underruns but when a bunch of MIDI notes come in quick succession they seem to lag behind. I don't know if anyone else experienced this in the original thread, as the MIDI code for Qt MUNT may be better, but I haven't dove into the mt32d code yet (it's supposed to be deprecated anyway).

US1wUaR.pngg
💾 Download | 📚 Documentation | Support

Reply 18 of 100, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie
d0pefish wrote:

I don't know if anyone else experienced this in the original thread, as the MIDI code for Qt MUNT may be better, but I haven't dove into the mt32d code yet (it's supposed to be deprecated anyway).

how are you reading midi? is it external fed into the pi uart? if so, make sure the pi uart is the correct speed, in order to get it so, you have to (on the pi3) disable the bluetooth on main uart,, switch gpio with a boot loader overlay to get full uart back on gpio, and change the clock speed so you can get correct midi speed with much less margin of error (than if you hadnt changed the uart clock speed)

if your just feeding it data internally it already has, there should be no speed bumps. when I tested, I didnt have any speed issues but I was using external usb-audio card (aka a pcm1704). you can get something like this ; https://www.adafruit.com/product/1475 (i have a variant of this https://www.amazon.com/dp/B00FEDHHKE/ )

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

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

but that is irrelevant for making pi into a wavetable daughter card..

still need to feed midi in to uart, then feed the wave l/r back out...

problem being all raspberry pi GPIO are digital, none are analogue. i _ASSUME_ the wavetable l/r output pins are analogue sound...

anyway this might help;
http://members.chello.nl/~g.lammertink/Techni … vetabl/wave.htm

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 19 of 100, by d0pefish

User metadata
Rank Newbie
Rank
Newbie

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).

I totally agree with disregarding the internal audio - it is dreadful. There's a nasty aliasing hiss even when MUNT is idle, whereas even the most basic USB soundcard produces much nicer output. Additionally, it can't operate at lower latencies because of its design. I have been using MUNT at 5ms buffers without any clicks or pops with USB audio, but internal audio needs something like 10 to not underrun.

I think this is a software issue - remember I'm not using the desktop Qt version of munt; I'm using mt32d which is inside the 'mt32emu_alsadrv' directory of the MUNT repository. It hits ALSA directly and has no JACK/PulseAudio support. I'll try and debug this at some point.

US1wUaR.pngg
💾 Download | 📚 Documentation | Support