On 19.12.24 12:04, Kristian Amlie wrote:
I see your point, but unfortunately this won't work correctly for the intended
use case. Which channel you play on is tied to which environment you run in, so
it needs to be saved in the state, otherwise the channel setup may be wrong the
next time you load up a project.
But I agree that my proposal, and especially the "Start in Omni" option, does
sound like it belongs in config. So maybe we just need to take a step back and
rethink that option... Hmm, tricky, but this is why I asked! 🙂
Somehow I get the feeling that it's not really clear what the difference is
between "config" and "state". I mean this generally.
Maybe there even is no difference -- and we try to make a distinction which
does not actually match the way we're thinking (from an users POV!)
Note furthermore, that since last release we implicitly save changes
immediately into the persistent state. We had a discussion, and this
was rather clearly the preferred way, based on the feedback we got.
Personally, I tend to dislike this change. But I can live with it,
since we've still got the option to save a state snapshot explicitly
and to re-start yoshimi with the --state= option
So I can save my state files without xml compression and check them
into Git. Because I was hurt so much in past by saving unintended
changes somewhere...
Let me attack this from a different angle: Let's say I have a project with a
Yoshimi instance in it (LV2 or standalone loading a state file, it doesn't
really matter), and three enabled parts. I want all three to sound
simultaneously, so I set them to all to channel 1. It seems obvious that this
setting must be saved in the state data, so that the next time I load it, all
three instruments will again respond on channel 1. And indeed, this works today.
On a related note, Ardour has some interesting configuration,
which you can set individually for each MIDI-Track:
It is called "MIDI Channel selector" in the context menu and brings up a
modal pop-up window with title "MIDI Channel Control"
Inbound
[ ] Record all channels
[ ] Record only selected channels
[ ] Force all channels to the following channel
...and a row with 16 buttons
Playback
[ ] Playback all channels
[ ] Play only selected channels
[ ] Use a single fixed channel for all playback
...and a further row with 16 buttons
Why am I bringing this up? Because this can be used to emulate
some kind of "Omni" behaviour. You can have a MIDI strip respond
to all events on all channels, re-map them and send them out on
one channel at the output side.
Obviously, a DAW is something different than an instrument,
especially since there is the additional twist with MIDI files
being recorded or placed into a track.
But all of this makes me think that actually we are looking at some
kind of routing or mapping problem.
Furthermore, there are striking similarities to "Solo",
which also has its whole bunch of notorious problems.
In a DAW, you can implement Solo in quite different ways.
- you can make it mute all other tracks
- but you can also create a new direct monitoring link from one track
to master and at the same time disable the rest of the mix.
"Solo" is typically something that is saved in a project.
And I'd say in 50% of all cases this is what you want and in the
other 50% it is annoying and confusing, especially when the DAW
supports some kind of multi-solo, then you can get really lost.
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.
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?
As we all know, there is a multitude of usage styles for Yoshimi,
which are sometimes difficult to reconcile.
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.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
