Midi plugin for Jam

[agranlund]

I wanted a simple Gem midi player so I made a plugin for Jam (https://www.creamhq.de/jam)

The plugin binary + source lives here:
https://github.com/agranlund/jamplugins

It was almost exclusively tested on my clone computer but it should, hopefully, work on real Ataris too (tested in Hatari only).
It outputs to the midi port so you'll need some kind of synthesizer connected to get sound out of it of course.

[stormy]

Cheers! Very handy!

[charles]

I see its ability to play out of the midi ports and I've looked at your code just curious does it also have the ability to save the file playing as a midi file

[charles]

I see in your code you also want to make a midi driver you should check out omikron basic they have a example which I'm trying to translate into GFA because by setting the interrupt priority level it will send whatever's in the midi buffer out because it's bi-directional but nobody's done that yet to my knowledge

[agranlund]

I see its ability to play out of the midi ports and I've looked at your code just curious does it also have the ability to save the file playing as a midi file

I'm not sure if I misunderstood the questions, but it's for allowing the Jam player to play midi files (as in, you would already have the midi file on disk).

I see in your code you also want to make a midi driver you should check out omikron basic they have a example which I'm trying to translate into GFA because by setting the interrupt priority level it will send whatever's in the midi buffer out because it's bi-directional but nobody's done that yet to my knowledge

It's actually the opposite, almost

I want to avoid the situation where you have to copy/paste "driver" code for all hardware you know about, into every application you make. (Like in the days of DOS, before Windows came with a unified sound API with device management)

I'm loosely sketching on some kind of higher level system-sound api - which may or may not amount to anything.
Think Amiga AHI, whatever the 68k macs had, what your current Windows/Mac/Linux box has - they all fullfil the exact same need but there's nothing quite like that on Atari. The individual device drivers which are managed by that API are then the small and fun part of the equation.

I wanted it mainly for managing PCM related stuff but it would make sense to have it manage midi too.
(This way you write the Vampire midi code once, in the device driver, and that's it. Same for Raven, or some PCI or ISA card you have in a Hades etc, or any future clone)

For midi out, the application side code should really only need to look something like this - with no care for where that output actually goes. That is entirely up to the sound system and the users setting of it.
adi_midiDevice = ADI_GetDevice("midi", DEV_DEFAULT);
adi_midiDevice->writeBuffer(buf, size);

You could also in theory make a virtual midi-out device driver that doesn't send the buffer to a hardware midi port, but instead plays it directly on some hardware - perhaps a midi->adlib translator that outputs on an adlib card. or even play the midi (badly) on the YM chip (like I did in ScummST)
The point is really to not tie that type of code into individual applications but rather it being a global feature of the computers system sound api + drivers.

But yeah, that thing is in some kind of pre-planning stage based on wanting better support for the Gravis Ultrasound on my Atari clone, but maybe nothing will happen of it

[Eero Tamminen]

or even play the midi (badly) on the YM chip (like I did in ScummST)

Did you take a look at at BadMood code for synthesis? Doom songs are very close to MIDI standard, and BadMood has both real MIDI output, and AFAIK very lightweight & IMHO really good sounding CPU synthesis for those songs.

BadMood does some translation for the song data, and I remember Doug mentioning that the songs + instruments needing some tinkering to sound good with the synthesis. I think that was mostly because songs could have a lot instruments playing at the same time, but the CPU synthesis had much fewer channels available.

[saulot]

BadMood for output uses preprocessed midi data to more compact format, bypasesses os completely (library isn't public atm, because I'm not 100% happy with it and plan to add opl support for it). So, there's no possibility to look into it atm.. It might emerge as some sort of plugin some time..

[charles]

I'm no coding Guru for platforms with mint installed but I think you just have to check the interrupt order to use x bios 12 m i d i w s

[agranlund]

I'm no coding Guru for platforms with mint installed but I think you just have to check the interrupt order to use x bios 12 m i d i w s

I had it working fine in TOS using the normal caution as described in Hitchikers guide to the Bios, but I couldn't get it stable under Mint trying a whole slew of different methods and from different interrupts etc.

Now that you peaked my interest again I had a look in the Mint sources and see that it overrides the relevant bios/xbios routines with a rather large machinery. The midi device is considered a TTY device and with that comes a bunch of code that I have no interest in digging into the details of.
Now, I don't know if it goes into these specific codepaths, but the tty device code checks for tty control characters (which doesn't feel great if you're sending raw bytes to an actual midi device rather than using tty-over-midi-port).
I see a bunch of current-process stuff, potential buffering, yield/sleep and that sort of stuff which again does not feel great being executed from an interrupt.
Perhaps the dangerous bits are not called in my case due to some flags somewhere. I don't know and have no interest in digging deeper into that stuff - the sheer amount of MiNT code happening before it eventually ends up in TOSs "2-liner" hardware code that I am actually interested in, in bconout/stat3 makes me think I shouldn't go there from an interrupt anyways.

It did make me aware of these which I had absolutely no idea existed, and they will probably do the trick just fine

Code: Select all

xconout      LONG 0x57e	Eight vectors for Bconout routines. (From TOS 1.02 on)
xconstat     LONG 0x51e	Eight vectors for Bconstat routines. (From TOS 1.02 on)

(Edit: Yes, that works a treat under MiNT too. The plugin is now using xconout[3] for pushing midi data on clone systems)

[mikro]

Useful info, thanks for the digging @agranlund.

[Eero Tamminen]

I wanted a simple Gem midi player so I made a plugin for Jam (https://www.creamhq.de/jam)

The plugin binary + source lives here:
https://github.com/agranlund/jamplugins

It was almost exclusively tested on my clone computer but it should, hopefully, work on real Ataris too (tested in Hatari only).
It outputs to the midi port so you'll need some kind of synthesizer connected to get sound out of it of course.

Finally tested Jam + your MIDI plugin (in Hatari) under few different machine configurations.

Mostly that works fine except for one song where playing it with FluidSynth caused invalid data for PortMidi (after which one needs to re-init PortMidi i.e. reset Hatari to get MIDI working again), which does not happen with SMF_PLAY:

IShotTheSheriff.mid.gz

PS. I also noticed that timings are all off in Falcon monochrome mode (but not e.g. in STE+mono). That happens for all Jam player plugins, so it's not related to MIDI plugin. Any idea whether that's Hatari or Jam player bug?

[agranlund]

Mostly that works fine except for one song where playing it with FluidSynth caused invalid data for PortMidi (after which one needs to re-init PortMidi i.e. reset Hatari to get MIDI working again), which does not happen with SMF_PLAY:IShotTheSheriff.mid.gz

PS. I also noticed that timings are all off in Falcon monochrome mode (but not e.g. in STE+mono). That happens for all Jam player plugins, so it's not related to MIDI plugin. Any idea whether that's Hatari or Jam player bug?

Oh, interesting finds and thanks for the report! I'll give it a go here too.
The invalid data feels like it has to be the plugins fault - thanks for the midi file, that should help in figuring it out

The timing thing is odd though. It should be playing from a TimerA interrupt it sets up itself and base all timing off of that.
Peculiar that it ends up off specifically in Falcon mono mode - I'll have to test, it's certainly possible I am doing something not quite correct somewhere.

[Eero Tamminen]

The timing thing is odd though. It should be playing from a TimerA interrupt it sets up itself and base all timing off of that.
Peculiar that it ends up off specifically in Falcon mono mode - I'll have to test, it's certainly possible I am doing something not quite correct somewhere.

As it happens with all Jam plugins I tested, I don't think it's a problem in the MIDI plugin. I have no idea whether it's Jam or Hatari issue though, so somebody testing it on real HW (Falcon + mono monitor) would be nice.

[mikro]

somebody testing it on real HW (Falcon + mono monitor) would be nice.

Mono monitor or mono mode? Huge difference.

[evil]

I noticed that Hatari runs very slow with monochrome _monitor_. The JAM plugins stutter like crazy and the entire emulated machine feels sluggish. All fine in RGB/VGA ST-high.

Here's a video showcasing this problem and the Falcon audio regression in 2.5.0.

https://www.youtube.com/watch?v=jkishXK8XaU

Four chapters: RGB PAL 50, RGB NTSC 60, VGA 60 and SM124 MONO.

The RGB/VGA chapters shows the regression as reported on the mail list a few times, very noticeable in VGA 60: https://youtu.be/jkishXK8XaU?t=152).
The SM124 chapter speaks for itself

I've run the emulator with the same parameters for all instances, only changed the monitor type:

Code: Select all

hatari --machine falcon --dsp emu --cpulevel 3 --cpuclock 16 --fpu 68882 --cpu-exact 1 --compatible 1 --addr24 1 --timer-d 0 --memsize 14 --window --frameskips 0 --drive-led false --monitor vga --avi-vcodec png --png-level 2 --sound 49170 --fast-boot 1 --tos 404.img --gemdos-drive c --harddrive Falcon030

Hostmachine is macOS 14.5 with M1 ARM64 CPU.

[thothy]

I noticed that Hatari runs very slow with monochrome _monitor_. The JAM plugins stutter like crazy and the entire emulated machine feels sluggish. All fine in RGB/VGA ST-high.

Thanks for your report - at least the issue with the monochrome monitor should now be fixed here:

https://git.tuxfamily.org/hatari/hatari ... 303d5e8475

[Eero Tamminen]

I've verified that Thomas' Hatari fix got rid of the sound issues in Jam plugins I've tested (for MOD, SND, MID).

[MiggyMog]

Was there ever a JAM > E.P.S.S midi player?