On 17.12.2024 19:34, Will Godfrey wrote:
On Tue, 17 Dec 2024 18:32:09 +0100
Kristian Amlie <krist...@amlie.name> wrote:

My first thought is that you should be able to set part 1 to look at channel
2 (or any other), and this would be saved in the state file. I use this
frequently when running standalone. Have you tried that?

Yes, that works, but the problem is that I don't know upfront which
channel to set it to. Each state file acts as a preset, and can be added
to any channel, so it only works if it matches the one you first saved
with, whether that's 1 or 2 or anything else. Next time you use that
preset, you might be on a different channel.

OK, so it seems for all instances Omni should set all incoming channels to
channel 1. To keep things tidy, maybe it should also mace sure all other parts
are disabled for that instance. A minor annoyance would be that you have to set
Omni independently for each instance.

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:

- MIDI already supports special CC messages to set turn Omni mode on or off (CC 124 and 125).

- When they talk about instruments, they mean "virtual instruments", IOW one synthesizer can have several virtual instruments. This maps to Yoshimi's parts.

- Each instrument can turn Omni mode on or off independently of the other instruments.

- When omni mode is on, that channel responds to messages from all channels, except for the Omni mode messages themselves, they will only be recognized on the original channel.


I definitely think we should try to follow this as closely as possible, so as to not reinvent the wheel, and avoid surprises. Therefore my suggestion is as follows:

- I implement support for the CC 124 and 125 Omni messages.

- In Yoshimi's Controller window I implement two options:

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.

2. "Start in Omni" - Which mode to start in if no Omni messages have been sent. This MIDI standard actually says that it should default to On, but I think this doesn't make sense for Yoshimi, so I will use a default of Off instead to keep compatibility.

This both respects the MIDI standard, is fully backwards compatible, and allows the option to be saved, which solves my original use case.

Sounds good, doesn't it?

Also I'm wonder what affect all of this will have on Vectors or MIDI-Learn.

I need to look into this in more detail, but my gut feeling is that "it
will act as if all the messages came from one channel".

Well that would knock out Vector control so the button should probably either
be hidden, or marked as inactive :(

MIDI-learn should be OK, you'd just have a separate window for each instance.
You might have to do something about the channel number. Without looking, I'm
pretty sure MIDI-learn, is first to see the incoming MIDI.

Just remembered you can set it to see *all* incoming channels, and NRPNs
already are not channel sensitive :)

Yes, I think I will leave this part untouched, since it already kind of supports Omni mode, by using "All" as you mention.

This means it won't react to Omni CC messages, but since MIDI learn isn't bound to specific parts, this would be difficult to implement correctly anyway. There wouldn't be an original channel to tie the message to.

Finally, are you running the basic Yoshimi LV2 or Yoshimi multi? Andrew and I
had quite a lot of discussion about that, but I'm afraid I've almost completely
forgotten it all, so can't say if it's relevant :(

The basic one.

But this is an interesting question, because their integration with
ZynAddSubFX is completely different: It launches it as a standalone
application with 16 stereo Jack ports, and then internally keeps track
of which port to connect to, using OSC to change patches on each
channel. One instance can then span several of the so-called chains,
where they will appear as separate instances, but they're really not.
But keeping track of all this requires a huge beast of a manager in a
python file tailored specifically for ZynAddSubFX. I'd really like to
leverage the fact that Yoshimi has LV2 support and do it in a much more
standard way.

Therefore I feel quite confident in saying that that we cannot (or maybe
rather "should not") use the Yoshimi-multi LV2 plugin, since the LV2
manager expects exactly one stereo pair of output ports. For more
advanced setups you probably could use it, but then you'd anyway have to
use the remote desktop connection and the Yoshimi UI to set up multiple
patches and their routing in one instance, so I consider this an
advanced use case, not the "easy" case which I'm aiming for in this
discussion.

Hmmm - it's difficult to see how this all comes together.

Hehe, I get that. It's hard to visualize without actually having seen a Zynthian unit, and how it operates. But that's why I like the standard MIDI approach above. Then we are just doing what many synths have done before us.


[1] https://www.freqsound.com/SIRA/MIDI%20Specification.pdf, particularly the chapter on "Channel modes".

--
Kristian


_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel

Reply via email to