Re: [hatari-users] Question regarding Hatari and MANDALA.PRG

[ Thread Index | Date Index | More Archives ]


On 1/30/20 7:44 PM, Michel Tavir wrote:
What you wrote back is probably useful for those in the know, like Robert
maybe, but, sorry to say, I don't understand most of it. So, jumping to the
first place I somehow could relate to, I went and downloaded Qsynth 0.3.6,
which is about the same age as this MacOS, launched it and got this:

17:59:36.096 Qsynth1: Creating synthesizer engine...
17:59:36.115 Qsynth1: Creating audio driver (jack)...
17:59:36.126 Qsynth1: Failed to create the audio driver (jack). Cannot
continue without it.
fluidsynth: error: Couldn't find the requested audio driver jack. Valid
drivers are: coreaudio, file.
17:59:53.144 Qsynth1: Destroying synthesizer engine...
17:59:53.145 Qsynth1: Synthesizer engine terminated.

I don't have no idea what this means, never heard of a "jack" in relation to
my Mac besides the physical ones I plug into the computer.

Jack is a low-latency audio framework / API.

Qsynth is what I use myself on Linux, but any SW
synthetizer that listen on MIDI input should be
fine for testing.

But even assuming that I could get any further, I don't understand this part
of your following instructions either:

* Select "synth input port" from the SDL GUI MIDI output selection

- tried to look up SDL in Wikipedia, and met a bunch of entries that could
or could not mean anything in this context.

SDL is a cross-platform audio, keyboard, mouse, joystick, and graphics abstraction library:

Hatari source code includes several graphical
user interfaces (GUIs), each written with
a different programming language and using
different GUI library:

1. C / SDL GUI which works on all platforms
   and is maintained by the Hatari developers

2. Objective-C / Cocoa GUI which works only on
   MacOS and is maintained by Hatari MacOS users:

3. Python / Gtk GUI maintained by me, which
   controls Hatari externally (and which under X11
   can wrap Hatari's window into its own GUI):

As I don't have MacOS, I have no idea how the MacOS GUI works, I can tell you only how things work with the SDL & Gtk GUIs, and only fix issues
with them.

Normally you can invoke Hatari SDL GUI with the F12 key, doesn't that work on MacOS?

For the rest, of what I do understand:

Hatari defaults for ST.

As I wrote in my first post I haven't had an ST for over two decades, so I
wouldn't know what those defaults are and how to set them in Hatari.

Hatari has specific defaults for each machine
type.  Those defaults are used unless user has
explicitly changed them.

To restore Hatari defaults, it's enough to rename
saved Hatari configuration file (hatari.cfg) to
something else, and re-start Hatari (at which
point it will ask you to provide TOS image).

Looking at the Hatari sources, on MacOS Hatari's
configuration file should be located in:
	Library/Application Support/Hatari

I don't think CPU settings are related to this
issue though.

EmuTOS v0.9.12 release.

Assuming it's the same as the “emutos-512k-0.9.12” -> "etos512k.img" I

That's the one I'm using.

> I also have not a clue as to what
Hatari is naturally built from latest Git commit
which you wrote afterwards actually means.

It means that I have newer version than you,
which may have fixes that you won't have.

In don't think that matters for the issue
you're seeing though, it's likely to be
something with the contributed PortMidi code.

Somebody would need go carefully through the code
converting MIDI data to PortMidi events and vice-
verse, against MIDI spec, to verify that the code
is doing the correct things.

Are there any MIDI experts on the list, that
could look into this:


	- Eero

PS. Git is a (distributed) code version control system:

And Hatari source code is maintained in a Git repository:

Mail converted by MHonArc 2.6.19+