On Thu, 2 Jan 2025 14:48:16 +0100
ichthyo <p...@ichthyostega.de> wrote:
>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!)
yoshimi.config is the very limited amount of config that is common to all
instances.
yoshimi.instance{n} is the rest of the config for that numbered instance.
yoshimi.state{n} is the instance data
plus a complete patchset
plus a vector set
plus midi-learn
For LV2 it also includes yoshimi.config - although a lot of the settings are
irrelevant and ignored.
>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...
I appreciate your viewpoint, but it's what we call a "Marmite" issue in the UK
(people love it or hate it)
>> 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.
Unfortunately I've never been able to get my head round Ardour - it seems to be
the most complicated DAW (although I don't actually use anything other than the
Rosegarden Sequencer).
>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.
Our implementation of Solo came about to support a very specific live workflow
I wanted, duplicating what I used to have setup on an all-in-one synth years
ago. i.e. to seamlessly change instrument *including* the full note tail of the
last one. I don't know if there's anything else that does that. Like most
things Yoshimi, it later expanded.
>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.
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.
>
>-- Hermann
Indeed. Also different instances can have different MIDI sources and Audio
destinations.
--
Will J Godfrey {apparently now an 'elderly'}
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
