MIDI on a 4a / mt32-pi

[+dhe]

Looks like PI's are now doing the work of famous synthesizers!

 

https://www.tomshardware.com/news/raspberry-pi-mt32-pi-midi-synth

 

Might be enough for someone here to dust off their old MIDI software.

 

wiki: https://github.com/dwhinham/mt32-pi

[speccery]

Yes I’ve also watched videos about this, interesting stuff. Is there any MIDI software for the TI? Or MIDI interface for that matter? I already built one for the TI myself  

[ti99iuc]

@speccery that I know there is only Midi Master 99 - (by Bruce Harrison and Michael J Maksimik), maybe the last version is the v2.5z.

 

 

I also converted an old VHS video and published on my YT channel in 2014. A demonstration of MIDI MASTER:
 

 

[+jedimatt42]

 

[+arcadeshopper]

4 hours ago, speccery said:

Yes I’ve also watched videos about this, interesting stuff. Is there any MIDI software for the TI? Or MIDI interface for that matter? I already built one for the TI myself  

yes and its just a cable for rs232.. works on regular rs232 and nanopeb.. midimaster99 is on the forum here for playing files it's only output at this point

I make cables and sell in my store but the docs are also in the forum

[+acadiel]

Yep, I built a ClumsyMidi and have the MT32 banks in it. Don’t ask me why but I liked that branch of hardware better.  
 

it works amazingly well!  All through hole components. 

[+dhe]

Via @Atari8guy - A really nice looking hat: https://www.serdashop.com/MP32L

 

[wierd_w]

I will say this again.

 

It is painless to route midi over a UDP socket. One could expose the entire midi stack afforded by a tipi, and have several softsynths, and real synths off USB, quite painlessly. It's very low hanging fruit.

 

(MUNT for MT32/LAPC1, and Timidity++ or FluidSynth for GM wavetable stuff. Linux MIDI stack could present any arbitrary hardware synth the same way, using the PORT:DEVICE addressing schema.)

 

 

Again, you just need a UDP listening daemon that wraps something like aplay. A daemon shellscript could do the work. Have a bespoke protocol that sends 3 words at a time with a termination word. First two words specify device and port on the linux midi subsystem, and the third contains the actual midi message. Termination word keeps the handler in a sane condition.

 

From the TI's side, you just throw the 4 words at the UDP handler baked into the tipi on the specified UDP listen port. Like magic, the tipi responds.

 

 

Edited November 17, 2022 by wierd_w

[+9640News]

As someone not well versed with the MIDI and someone that would like to hear some quality sounds from such a system, I have a question or two with the hope this would stir up some other users to be interested.

 

The first question, I presume one must have a MIDI capable device connected via the USB port to the PI?  Is there any way/option(s) one could plug speakers into the PI and get sound/music without additional hardware?  My thought here is to keep the cost as minimal as possible.  If users would have to spend >$100 to get an acceptable device to plug into the PI, interest is not going to be great.  However, if the cost was only a set of speakers, or a $10 to $20 connectable item, that would have more interest.

 

I think there are one or two MIDI players out there now with Mike Maksimik the author of one.  Is source code whether it was an Extended Basic program, C source code, or assembly program available?  Trying to assess what would be involved.  I know with @jedimatt42 implementation of the UDP protocol, extended basic program support would not be too painful ........ hopefully.

 

Right now, trying to gauge what the investment in time and hardware may be as cost would be a factor for a number of people to get more than a handful of users interested.

 

 

 

2 hours ago, wierd_w said:

 

It is painless to route midi over a UDP socket. One could expose the entire midi stack afforded by a tipi, and have several softsynths, and real synths off USB, quite painlessly. It's very low hanging fruit.

 

(MUNT for MT32/LAPC1, and Timidity++ or FluidSynth for GM wavetable stuff. Linux MIDI stack could present any arbitrary hardware synth the same way, using the PORT:DEVICE addressing schema.)

 

Again, you just need a UDP listening daemon that wraps something like aplay. A daemon shellscript could do the work. Have a bespoke protocol that sends 3 words at a time with a termination word. First two words specify device and port on the linux midi subsystem, and the third contains the actual midi message. Termination word keeps the handler in a sane condition.

 

From the TI's side, you just throw the 4 words at the UDP handler baked into the tipi on the specified UDP listen port. Like magic, the tipi responds.

 

 

 

[+arcadeshopper]

4 hours ago, wierd_w said:

I will say this again.

 

It is painless to route midi over a UDP socket. One could expose the entire midi stack afforded by a tipi, and have several softsynths, and real synths off USB, quite painlessly. It's very low hanging fruit.

 

(MUNT for MT32/LAPC1, and Timidity++ or FluidSynth for GM wavetable stuff. Linux MIDI stack could present any arbitrary hardware synth the same way, using the PORT:DEVICE addressing schema.)

 

 

Again, you just need a UDP listening daemon that wraps something like aplay. A daemon shellscript could do the work. Have a bespoke protocol that sends 3 words at a time with a termination word. First two words specify device and port on the linux midi subsystem, and the third contains the actual midi message. Termination word keeps the handler in a sane condition.

 

From the TI's side, you just throw the 4 words at the UDP handler baked into the tipi on the specified UDP listen port. Like magic, the tipi responds.

 

 

did you see matt's post a few back? where he did udp midi off the ti?

[+FarmerPotato]

Minor comment:  when I rewrote the FORTI software, I substituted MIDI note numbering everywhere, instead of the author's system.   I hacked together a tool to extract FORTI voice lines from a MID file.  (Used in my 99damashi demo, the Katamari Damashi tune.)

 

I drafted the MIDI interface for Geneve2020.  I've built the circuit and used it with Arduino. It's really very simple, but requires a serial port.  (Which is why you can just use the RS232 card + a cable.)  My sound card is only on the drawing board, but the MIDI interface I put onto the front-panel/power PCB where the 2 DIN-5 ports sit.   When I get the bugs out of my memory board, it's far down my TO-DO list, but I can wire-wrap another 9902 and connect it.

 

I'm excited to see (uh, hear) what ya'll are doing with MIDI here. 

 

[wierd_w]

8 hours ago, 9640News said:

As someone not well versed with the MIDI and someone that would like to hear some quality sounds from such a system, I have a question or two with the hope this would stir up some other users to be interested.

 

The first question, I presume one must have a MIDI capable device connected via the USB port to the PI?  Is there any way/option(s) one could plug speakers into the PI and get sound/music without additional hardware?  My thought here is to keep the cost as minimal as possible.  If users would have to spend >$100 to get an acceptable device to plug into the PI, interest is not going to be great.  However, if the cost was only a set of speakers, or a $10 to $20 connectable item, that would have more interest.

 

I think there are one or two MIDI players out there now with Mike Maksimik the author of one.  Is source code whether it was an Extended Basic program, C source code, or assembly program available?  Trying to assess what would be involved.  I know with @jedimatt42 implementation of the UDP protocol, extended basic program support would not be too painful ........ hopefully.

 

Right now, trying to gauge what the investment in time and hardware may be as cost would be a factor for a number of people to get more than a handful of users interested.

 

 

 

 

A single line edit to the pi's conf file will enable audio off 3 pins on its header strip. This audio device ideally needs a post amp filter, but can abuse the one in the TV/Monitor, if injected onto the Aud line on the TI's sidecar bus. It is fully supported by ALSA back end, and so MUNT, FluidSynth, Timidity++ and pals can cheerily use it.

 

https://raspberrypi.stackexchange.com/questions/49600/how-to-output-audio-signals-through-gpio

 

You would need to add a 'monaural downmix' directive to the alsa configuration to force it into a single channel, but that is also just a config setting. (Then you would have synthesis being piped out of the pi and into the TI's sound chip mixer natively).

 

I think 2 little wires is not that big of an investment in hardware.

 

you would need access to mt32 roms to use MUNT, and would need a fairly beefy (not a zero!) Pi to use FluidSynth. Both are software provided synths that are FOSS. No additional hardware required.

 

@arcadeshopper

 

Yes, however he is not communicating with the alsa midi chain, but with a bespoke hardware device.

 

The ideal solution would leverage the alsa midi chain, and thus allow access to ANY arbitrary midi device you might have, be it a softsynth, or a hardware one. 

Edited November 17, 2022 by wierd_w

[+9640News]

32 minutes ago, wierd_w said:

A single line edit to the pi's conf file will enable audio off 3 pins on its header strip. This audio device ideally needs a post amp filter, but can abuse the one in the TV/Monitor, if injected onto the Aud line on the TI's sidecar bus. It is fully supported by ALSA back end, and so MUNT, FluidSynth, Timidity++ and pals can cheerily use it.

 

https://raspberrypi.stackexchange.com/questions/49600/how-to-output-audio-signals-through-gpio

 

You would need to add a 'monaural downmix' directive to the alsa configuration to force it into a single channel, but that is also just a config setting. (Then you would have synthesis being piped out of the pi and into the TI's sound chip mixer natively).

 

I think 2 little wires is not that big of an investment in hardware.

 

you would need access to mt32 roms to use MUNT, and would need a fairly beefy (not a zero!) Pi to use FluidSynth. Both are software provided synths that are FOSS. No additional hardware required.

 

Is this 2 wires only something that would work for the sidecar TIPI/PI or can two wires be run from the PI to the edge card connector?

 

While two wires are relatively simple, you have a limited number of people with soldering skills to update things.  A simpler solution is to plug something a bit more expensive than two wires but less than $20 into their PI without soldering.  That would get more interest in my 2 cents.

 

Beery

[wierd_w]

Iirc, AUD-IN is exposed on the JediMatt 44pin header, as is GND.

 

It may have issues being used in conjunction with the speech synth, due to lack of chained mixing, but a small 44pin dummy extender that is orientation labelled, and has the 2 wires coming off as DuPont jumper pigtails would fit your bill.

 

Personally, I would just wire wrap AUD-IN and GND from the already exposed JediMatt connector, but for say, 'speech synth enclosure' tipi, that might not be doable. You would have to solder onto the far edge of the card finger or onto the through hole of the downstream connector.

[+jedimatt42]

It stops being 'simple' for most of the community pretty quickly.

[wierd_w]

6 hours ago, jedimatt42 said:

It stops being 'simple' for most of the community pretty quickly.

True enough.

 

I am more than happy to dabble in the water of trying to write a python handler/arbitrator for the ALSA midi subsystem.  There's already a community created python library for doing that, so I would just have to scribble out some glue between that and a UDP socket handler.

Also more than happy to do the mucking around on modifications to the stock TIPI raspbian image to turn on Audio over GPIO, set the ALSA config to monaural downmix, and set up fluidsynth/compile MUNT.

 

The obscurity of messing with linux under the hood like that is daunting to a fair number of people, so documenting what needs done, so it can be pre-baked as a flashable option would reduce the user burden quite a lot.

There are potential issues with needed user accounts so that the daemon has proper permissions to the sound device. This is a common issue with getting software synth daemons configured on desktop linux.

 

Do you know if raspbian is SYSV-INIT, or is it disgustingly Systemd?  I am a decent hand at writing a sysv-init style daemon script for init.d, but getting systemd to play nice is still something I struggle with.

 

Actually connecting the Pi to the AUD-IN line is really just 2 wires off the JediMatt connector to 2 pins on the Pi's GPIO header. A ghetto wire wrap on the jedimatt side before pushing the TIPI on, is really all you need. It's JUST audio.

 

 

 

[+9640News]

@wierd_w

 

One suggestion if this comes to fruition.  Have some type of command that can be sent through the messaging system of the TIPI that would return a Yes/No (On/Off, True/False) type response whether PI.CONFIG has a MIDI=ON or MIDI=OFF setting.  This way, if individuals do not have the ability and have not make the modification or addition of gadgets, there is a way to skip over or abort that portion of the code.  Just my 2 cents.

 

From your comments, it sounds like you are going with a mono sound. I would have liked to seen a cheap gadget with stereo 😀.  And, from some of the other comments, PEBox TIPI's are out of the picture for this modification for the mono system?  Thinking here regarding Geneve users.  I am asking because I do not think my last update to the TIPI XOP on the Geneve has the UDP messaging system in place as I had not seen or knew of where it may be applicable, and I had no way of testing any code written to support UDP.

 

[wierd_w]

If you slap the small post amp circuit on, you can put a stereo out port off 3 of the gpios. AUD-IN is monaural. The default is stereo.

 

Without the post amp, the audio sounds like garbage, because it's logic level signals, not audio level signals. The circuit diagram for the post amp is readily available online.

 

Since geneve is all internal to the PEB though, AUD-IN would be on the backplane, and is how 'peb speech adapter' works. Getting the signal safely from the bus would probably need bodge wires on the tipi card, and that is probably beyond the scope of a safe user mod.

 

Doing a grep of the pi.config file to see if gpio audio is on, then a grep of alsa.conf for the mix mode should be doable.

 

I had been considering using 'device' 65535 as a reserved device used for sending such control messages to the listener daemon, which would then allow numbered queries on the next two words before the termination word.  This way you could query what ALSA midi devices are present, note-off on all devices, etc. 

 

Alsa midi api allows up to 65535 unique sequencer devices, each with up to 65535 'ports' (unique io stream channels) per device.

 

for instance, the MUNT synth offers 2 ports, on a default 'device' id of 128.  

 

Eg,  128:0 and 128:1

 

These are normally used for 'gm emulation' and 'mt 32 native' instrument presets.  The 'device' is 128 for both. 

 

Softsynths on linux default to 128, but will enumerate after that if the id is taken. Eg, if you load MUNT, then Fluidsynth, munt will be 128:0,1 and Fluidsynth will be 129:0.

 

It's analogous to a 'midi chain'. Midi devices that are chained together on a daisy chain setup. Device is then analogous to the physical midi uart, and the port is the device ID on that chain.

 

Since the protocol would accept alsa device and port as words, you could work with hardware devices, as long as the Alsa subsystem has enumerated them. It's very mature, and detects such devices automatically in most cases just fine. There are USB cables for vintage midi devices, like authentic roland sound canvas, korg keyboards, mt32 and pals. You could put them on a usb hub, and connect that to the pi. The alsa midi subsystem would detect them, assign them DEVICE:PORT ids, and you could then use them just fine. However, the program running on the TI is not clairvoyant, and would need to be able to query for a list of sequencer devices and presented port ids.  Hence the need for the backchannel commands.

 

This would allow the single UDP service to arbitrate and handle IO to every midi device. That would allow whatever software you write or use, to define or use instruments from different devices. Useful if you want complex audio, multiple drumsets, etc.

 

 

[+9640News]

3 hours ago, wierd_w said:

If you slap the small post amp circuit on, you can put a stereo out port off 3 of the gpios. AUD-IN is monaural. The default is stereo.

 

Without the post amp, the audio sounds like garbage, because it's logic level signals, not audio level signals. The circuit diagram for the post amp is readily available online.

 

Since geneve is all internal to the PEB though, AUD-IN would be on the backplane, and is how 'peb speech adapter' works. Getting the signal safely from the bus would probably need bodge wires on the tipi card, and that is probably beyond the scope of a safe user mod.

I don't know what is involved, or what kind of price for the components would be necessary here if nobody hasn't already made something already for the PI unless you can already route the sound out on the audio port of the PI.  Myself, I think more people would be receptive to plugging in a few wires to the GPIO port to get stereo sound to a post amp than soldering wires to bring the sound output back into the 4A sound channel.

 

Please keep in mind my thoughts are for simplicity for the end user to have access.  Plugging wires into a connector is one step many users are likely to do, but any soldering is likely to knock out 90 to 95% of the potential TIPI base. 

 

Having said that though, I don't know what percentage of TIPI users have a PI Zero versus a PI 3 or PI 4 that may not require extra hardware but may make the post amp circuit setup a more logical solution.  While all my PI's are 3+ or a 4, I do recognize Greg has I think sold quite a few TIPI/PI setups with the PI Zero so greater use may not be a completely software solution.  I'm going back to your earlier comments where MUNT and FluidSynth may require a beefier PI.

 

Also, from what I gather from your reply, a PEBox TIPI would be more difficult to modify and that by itself, would eliminate all PEBox users and/or challenge the few that may consider that route.

 

 

 

 

[wierd_w]

Indeed, that's why I suggested the post-amp.

 

The component count on the post amp is very minimal, and the components needed are inexpensive.

 

The Pi3+ and co have a filter circuit on the board, but that is what drives the speaker jack. going off the GPIO header, you would still need to provide the amp. Putting it on any and all Pis would just make it a universally applicable solution, IMO.

 

It's arguably not needed if you send the logic level signals to the TI's sound chip for mixing, as the TI's sound hardware would provide the amp on its output. (and driving more than logic level outputs on that thin of a trace is probably not a good idea anyway. I doubt the speech synth outputs greater than logic levels itself.)

 

For a PEB Box setup, I would strongly encourage putting a stereo audio jack out the back somehow.

[+9640News]

What I am thinking is someone builds for the community that circuit on a mini board with a cable to a speaker jack or some kind of configuration where an extension can then be brought out to wherever they want. Then, it is just a matter of plugging that post amp board to the GPIO connector on the PI.  Preferably, it is thin enough it can be secured to the TIPI inside the PEBox for PEBox users. 
 

if this is something @wierd_w does not want to build, perhaps @Shift838 might be interested in the project if someone can demonstrate this works and the code can be incorporated into something @jedimatt42 would be then willing to support if he has the interest. 
 

There are several “IF’S” of people needed to make this happen, so it is more than just a single individual needing to support this idea. 

 

That is my thoughts to get community behind wide support. Again, there are several people needed.  Maybe in the future when the existing blank TIPI boards are built and sold, this circuit could then be added to updated boards. 
 

just my thoughts. 
 

Beery