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.
It's turned up a couple of interesting points.
The fist is that we can use a std::map here as this would lose the sequence
that options were set. An example is where you want to set a state, but also
change one instrument. A normal map sorts the list so would apply the
instrument before the state. I've no idea what the unordered map type would do!
On the plus side this gave me an idea, and in my latest build you can now
specify which part you want to instrument to be sent to.
The implementation is probably not entirely kosher but can cope with everything
I threw at it. Instead of just:
yoshimi -l={instrument} it's:
yoshimi -l={instrument}@{part number} (no spaces)
In view of the issues we had previously with stoi() I've added a leading zero
to the string.
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.
As usual, any thought most welcome.
--
Will J Godfrey
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
