Re: [hatari-devel] MIDI support for Windows & OSX (with PortMidi)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 10/04/2017 01:29 AM, Simon Iten wrote:
> > On 4 Oct 2017, at 00:13, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
> > On 10/03/2017 11:57 PM, Simon Iten wrote:
> > > does or how does portmidi change the way midi is presented to a usb-midi converter?
> > > or in other words, why does portmidi on osx behave differently (“better” in my case) then linux with the standard none portmidi method?
> >
> > PortMidi sends whole MIDI packages while the other one outputs the data byte-by-byte.
> >
> > Which device drivers you use on Linux and which on OSX?
> on osx i use the motu drivers from the support page they have. on linux there is no firmware needed, but i seem to remember the device is not fully class compliant. (a hack of the device id is necesarry). but it works out of the box on my linux system.
> > > this is with the same atari software, same synth and same interface. driver issue on linux? (fastlane-usb motu, not fully class compliant)
> >
> > Are you using the same version of Hatari?
> >
> > You can build Hatari also on Linux with portmidi to compare, whether they still behave the same, i.e. is the issue in the OS / driver level.
> i am using a non portmidi version on linux.
>
> does the github version have portmidi for linux already. or do i have to apply the patch?

You still need the patch.

There are some issues with how Jari's code interacts with SDL GUI + 
there's some state that's not handled properly for emulation resets & 
memory snapshots.  At least first ones need to be fixed before the code 
goes to repository.

I would also like somebody to test the code on Windows to hear whether 
there are any issues on that side.

Portmidi stuff also fails for me with Cubase Lite & Sequencer One, but 
I'm not sure yet whether that's bug in the code or just due to my old 
portmidi 184 version (latest is 217).


	- Eero

> i will try to test this further.
> > 	- Eero
> >
> > > > On 3 Oct 2017, at 22:10, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:
> > > >
> > > > Le 03/10/2017 à 21:26, David Savinkoff a écrit :
> > > > > ----- Eero Tamminen wrote:
> > > > > > PS. Jari has also some questions about jitter he's seeing in MIDI output:
> > > > > > 	http://www.atari-forum.com/viewtopic.php?f=51&t=32344
> > > > > As a MIDI jitter testing experiment, try the following sound options:
> > > > > --sound-buffer-size 10
> > > > > --sound-sync true
> > > > > These options affect emulation rate, and may improve the jitter.
> > > >
> > > > Hi
> > > >
> > > > I'm not sure this would help ; for midi output, you'd want as realtime possible behaviour, which I think is better achieved when emulation speed is not audio driven but using usleep in the main loop.
> > > > In that case if MFP expects a timer to last 1.39 sec for example under STF, then Hatari should take also exactly 1.39 sec.
> > > >
> > > > Plus, MIDI programs don't necessarily use the YM2149 chip, so you would have no audio data to sync with (except playing empty audio buffers).
> > > >
> > > > Put another way, I have more trust in usleep precision in that case than in syncing with an audio driver whose latency might vary depending on output sample rate or buffers size :)
> > > >
> > > > Nicolas