On Sat, 4 Jan 2025 11:37:39 +0100
Kristian Amlie <krist...@amlie.name> wrote:
>On 02.01.2025 16:51, Will Godfrey wrote:
>> On Thu, 2 Jan 2025 14:48:16 +0100
>> ichthyo <p...@ichthyostega.de> wrote:
>>> So maybe it helps if we consider "Omni" to be some kind of
>>> temporary change in channel mapping / routing?
>>>
>>> What does it mean then?
>>>
>>> Is "Omni" something global?
>>> ==> then it would mean that all input is remapped into one single channel
>>> ==> this would then also imply that all other channels are disconnected,
>>> i.e. parts configured to another channel would become muted
>>>
>>> Or is "Omni" a property associated to some channel?
>>> The MIDI messages (CC 124 and 125) might point into that direction right?
>>> ==> then it would mean that a specific channel gets connected to all input
>>> ==> while other channels still listen only to MIDI events with that channel
>>>
>>> NOTE: with this flavour, several channels could be in "Omni" mode.
>
>Exactly!
>
>>> Another question is if we even want "Omni" to be some kind of mode,
>>> similar to "Solo". As you know, modes are sometimes a nice concept,
>>> but there is also a tendency for confusion, especially when a mode
>>> has the potential to override settings made elsewhere.
>>>
>>> Thus we could also consider to make "Omni" more like a static additional
>>> choice in the mixer / part configuration, so that a part reacts to events
>>>from all MIDI channels. Wouldn't that address your specific case?
>
>Yes, it would. How I first envisioned it is that the dropdown could just
>gain one additional "All Channels" choice, in addition to the existing
>specific channels.
>
>The reason I didn't advocate for this is because it conflicts with how
>Omni is defined in the MIDI standard. If you set it to "All Channels",
>then that part would no longer know about any specific channel, and thus
>it would not be possible to implement the CC 124 and 125 correctly.
>
>But if we made Omni a separate checkbox, then it would be compatible.
>And I think that's what you meant, right?
>
>The question is: If MIDI CC 124 and 125 are used to change Omni mode,
>should it be temporary, or should it change that checkbox?
>
>To be completely open, I don't need Omni CC 124 and 125 support for my
>use case. I suggested this mainly to tie the whole feature more closely
>to the MIDI standard. But I would be ok with simply omitting that for
>now and implement Omni purely as a checkbox. It would still be "future
>compatible", so we could add the 124 and 125 support later. The upshot
>then is that we don't need an answer for the above question.
>
>And it is less work, which I certainly won't object to either. 😄
>
>>>
>>> As we all know, there is a multitude of usage styles for Yoshimi,
>>> which are sometimes difficult to reconcile.
>>
>> This hits on something I consider very important. Every musician I know has
>> a different preferred way of working, so with all the work I've done I've
>> tried
>> to maintain as much flexibility as possible - maybe that's sometimes too
>> much :/
>>
>>> Up to now, Yoshimi tried to keep out of the topic of routing and left
>>> that to the sequencer or DAW, or Jack.
>>> Yet still, in fact we /do/ have some kind of routing, since several strips
>>> in the mixer (i.e. several parts) can be set to receive the same channel.
>
>Indeed. And even caring about channels in the first place means you are
>doing some kind of routing. Only pure "any channel" instruments can be
>considered non-routing, I think. Yoshimi is far past that point.
>
Overall I'd be quite happy with this. However, I still have questions.
How would it relate to MIDI-Learn?
What effect would it have on Vector control - or indeed, any of 32 or 64 parts?
These come before any of the normal routing. Indeed, MIDI-learn has the ability
to block any further access to a CC/CH pair.
--
Will J Godfrey {apparently now an 'elderly'}
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
