On Wed, 18 Dec 2024 17:46:31 +0100 ichthyo <p...@ichthyostega.de> wrote:
>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. Agreed. Currently the only channel mode messages we support are: 120 78h All Sound Off 121 79h Reset All Controllers 123 7Bh All Notes Off >> - 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. Agree. Should be in MIDI CCs (although being pedantic it's not a continuous controller). >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. I think this command should be an instance one, from the point of view of the comparison with separate MIDI hardware sound generators - Yoshimi doesn't send MIDI out, so that's a complication dodged. Hence we also don't need to consider: 122 7Ah Local Control On/Off As that one simply determines whether a keyboard is connected to its in-build sound engine. >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. This reminds me of the problem one of our users had with Ardour, which apparently doesn't actually release closed instances while it's still running, so FLTK ran out of 'slots'. I'm wondering if they did that so that they could be sure of getting back the same location sequence. >So this is really a topic which we should discuss and reconsider eventually. > -- Will J Godfrey _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
