On Wed, 11 Oct 2023 at 19:16, Ted Felix wrote:
>
> On 10/11/23 9:30 AM, Lorenzo Sutton wrote:
> > I'm not totally sure of the pros and cons of this though, before
> opening a feature request.
>
>I find this rather disturbing. 🤣
>
>I think the right approach (and a good feature request) would be to
> first clamp down to <=128 everywhere and don't allow out of range
> values. Flag them if encountered and limit them to 128. Once we are in
> full compliance with the MIDI spec, then make this a preference. "Allow
> program changes beyond 128 (not recommended)" or something like that.
> If it's useful and it actually works, we should probably support it.
> Just so long as we make it clear this could lead to instability.
This seems a rather sane approach indeed. After all ALSA midi seems to
support this and the latest version of the MIDI specification v. 1.0
is 1996 so offering this more 'experimental' feature to users (with a
warning) seems a good balance.
.
Another approach would be to leave things 'as is' where <= 128 is
enforced when entering program changes manually and > 128 is only
possible in bank definitions. Like in the case of Yoshimi banks one
could assume that instruments above 128 only exist if the 'instrument'
(soft or not) actually has those.
>After all, it is completely in violation of the MIDI spec. It's a
> "use at your own risk" kind of thing. Any setup that is using the MIDI
> System Real-Time messages will become completely hosed when the right PC
> comes across.
Yes makes sense as well. I tested this e.g. with Pure Data and it
simply seems to set 128 for anything above, but yes I guess there
could be cases where this behaviour would be unpredictable.
Meanwhile MIDI 2.0 is a (recent) thing and there seems to be activity
to add support into ALSA https://lwn.net/Articles/932437/
Lorenzo
___
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
