Am 03.09.21 um 17:49 schrieb Will Godfrey:
I've now thoroughly tested all the startup options both singly, and in
groups. I've also merged back into my local copy of master, and tested again
including the null option and making a jack session. Again everything seems
fine, however I'll do more tests over the weekend before pushing this.
Hi Will,
looked again over the accumulated changeset and didn't spot any further obvious
problems. Regarding the std::map, indeed this is a point I didn't consider: does
the order of applying a change matter? In that case, there is no alternative
to using a list (std::unordered_map is a Hashtable, and thus orders elements
in implementation-defined ways for maximum speed). The only thing we could do
is to use a std::pair within the list, to avoid having to parse and split
later. However, this is just cosmetics.
The real question is, why do we have to pass that list down through 2 layers?
This is what I referred to as "unclear dependency and responsibility chain".
It would be desirable that...
- SynthEngine gets a complete const Config& (which is thus read-only)
- and uses a separate, completly private/internal object for the mutable
runtime state.
- and no one else (mind me!) should ever have to grab into SynthEngine's
internals and muck around with some mutable state there behind the scenes.
Well I am just dreaming, we aren't there yet and getting there would probably
require a deep refactoring with some challenges along the road.
The other point is that the behaviour regarding permanence of CLI options is
inconsistent. Most of these make a permanent change, but some years ago
there was one complaint about that as it's apparently not 'normal'. I was
reminded of this when checking the --null option. This will permanently
disable audio and MIDI. Presumably anyone using this would know enough to be
able to reset these as they wanted but I think it shouldn't be necessary.
Fully agreed, this is annoying.
I simply didn't find any easy way to avoid that change getting permanent, short
of making that a completely new and separate config setting, which suppresses
the auto-discovery of a working backend; this could then also be skipped when
saving the config persistently. I was reluctant to do that, mostly because I
don't fully understand all ramifications of such a change.
Overall this is an interesting question ("what does the user need/want").
From a pure logical POV config changes should never be persisted, unless
explicitly requested. However, in practice, when we just start up Yoshimi
and she happens to connect successfully to some backends, you'd typically
expect that to "just work" from now on in the future.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
