On 18.12.24 14:40, Kristian Amlie wrote:
I've been reading the MIDI specification, and as is often the case, someone has thought of this before us! My source is at [1], but my summarized conclusions are:
:-)
I definitely think we should try to follow this as closely as possible, so as to not reinvent the wheel, and avoid surprises.
Sounds reasonable indeed. ...
- In Yoshimi's Controller window I implement two options:
My first impression is that this should be a *Config* option. So probably it should go into the config GUI, not the controllers window. Moreover, taking into account our recent pain with multiple instance config, we should decide if this goes into the /basic part/ of the config, or if this is a /per-instance/ setting. Note, we have already other MIDI-related advanced config options. Will introduced a distinction between the very basic plattform setup options, and all further config, which is per-instance. After having spent quite some effort this summer to sort out problems in the config of multiple instances, I am very much convinced that this is a good route for the future and that we should always try to sort things apart, based on the question: is this for the basic platform setup, or is this something you want to configure different for several instances?
1. "Rcv Omni" - Whether Omni messages are respected at all. It will default to On when starting Yoshimi, but loading an older state which doesn't have the value will default to Off instead, to avoid breaking existing MIDI learn, etc.
As said: we have quite elaborate code to cope with config and to fill in default options and port old configs. We should try to use this scheme, and not invent any new logic here. - the Config object has some static fields. They are thus automatically shared between instances... - all relevant settings are fields in the Config object. These have built-in sane defaults as constructor parameters - there is code to discover if config files are already there for this instance number and otherwise populate a new Config instance. There is only one problem with this scheme: it is centred around standalone Yoshimi. The LV2 version always used the "instances" feature under the hood (I have just slightly streamlined that in the code, but not changed it). The problematic point is that for LV2, instance numbers are assigned automatically and without any user control, just in the way how multiple LV2 instances show up. So this is really a topic which we should discuss and reconsider eventually. -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
