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.
>> 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 :)
>> I've never tried either with LV2.
>
>This would not be in the LV2 specific part of the code. In fact, there
>is nothing you can configure specifically for LV2, and I think it should
>be kept that way.
>
>> If an 'Omni' option is the way to go, then I think an extension to Solo
>> would be
>> the simplest route - it already does quite a bit of channel/part
>> manipulation.
>
>Alright, I'll take a look at that section if Omni sounds like the best
>idea, and no one has any other suggestions.
>
>> 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.
--
Will J Godfrey {apparently now an 'elderly'}
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
