|Re: [hatari-devel] MIDI support for Windows & OSX (with PortMidi)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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).
i will try to test this further.
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:
As a MIDI jitter testing experiment, try the following sound options:
These options affect emulation rate, and may improve the jitter.
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 :)