I need to get my different midi channels to send their original midi channel data to my zynthian plugins, and they should all send to all of the instruments without selection… Reason being that I need to send one channel to one plugin and another channel to another without choosing
This is the same behavior as ‘arming’ multiple channels in ableton, so if I could select multiple channels as the playing channel it would also solve the problem as long as it relays the notes as original midi channel to the plugin.
If you set a MIDI input to multitimbral mode then each chain will receive the MIDI commands received from that MIDI input only on the channel that the chain is assigned. How does this differ to your various requirement?
My apologies for the perceived ambuguity. I’d like the channel that the chain is assigned to to keep playing the channel its assigned to while sending other midi channels to other chains, both working as assigned. E.g. various chains receiving various channels, no translation applied and every channel always receiving, regardless of ui selection
That will happen for any MIDI controller that you have set to multitimbral mode in the zynthian MIDI input configuration.
Go to admin menu
Select MIDI Input Devices
Bold SELECT the MIDI device you want to act as multitimbral
Enable Multitimbral mode for that input
Now, MIDI data from that controller will act on the chains based on the MIDI channel of each message. This works for note-on, note-off, pitchbend, etc. Zynthian handles MIDI continuous controllers (CC) and differently. These are bound to specific controllers. To get similar multitimbral control of CC you need to map/learn each control in absolute mode so that the CC number and channel are used to map (other wise just the CC is used and the active chain is controlled).
It is not clear what is not working as what you describe is how zynthian does work.
lanmower’s response is indeed a bit ambiguous. But I think that he’s asking the same question that I was about to ask: Is it possible for one chain to receive multiple MIDI channels untranslated?
The use case is this: I have a plugin which accepts notes on multiple MIDI channels. Simply using several instances does not work, because there is interaction going on between each channel as well, and the final output is just one stereo audio signal.
Yes I want one chain to receive multiple midi channels untranslated, if possible, I would also like those multiple (or single) and untranslated inputs to be available for multiple chains at the same time… in ableton you can select ‘all’ as a midi channel, and then control click on ‘arm’, and whatever channels you armed, some being ‘midi channel 1’ some midi from being another chain, some being ‘midi all’ will take midi input at the same time.
Now to get my personal basic setup working probably only need a single chain to be able to receive untranslated midi (multiple channels) so that one part of the chain can listen to midi channel 1, and another effect can be set up to listen to another midi channel, as you can imagine if I want to move some of this activity to its own chain, I would still want that activity to listen to its respective midi, regardless of which interface selections and browsing i’m performing, or which menu or mixer I’m busy configuring, so ideally I want to be able to do that with multiple chains at once, all receiving untranslated midi that has selected channels or ‘all’ (or some), the act of arming them to turn them on and off is a nice touch that ableton has, but is not a must-have.
I apologise for the comparisons to a daw, but I really think ableton mixer is a good analogy for zynthian’s layout
The architectural design of zynthian is that each instrument chain receives note on/off and pitchbend on a single MIDI channel. A module called, “zynmidirouter” processes and filters MIDI data and presents it to the appropriate chains. MIDI CC and PC messages are handled differently, being sent directly to control parameters. We don’t expose each soft-synth’s multitimbrality but instead, we use this to split such instruments across several chains, e.g. we run a single instance of fluidsynth, using MIDI channel splitting to target each of its internal voices / channels. So, for instrument chains (soft-synths) we don’t provide “All MIDI Channels” option.
For MIDI only chains we do allow the selection of “All MIDI Channels” so that multitimbral processing and MIDI routing works. So for MIDI processing and routing to external synths you can do this.
You could put this in a MIDI-only chain then route that chain to other chains using the “MIDI Out” option in the Chain Options menu.
Aha, yes, I think the first multitimbral approach you describe will work…
So if my synth is multitimbral, I can “spread” one instance over several chains? I think the only slight oddness is that only one of those chains would have any audio output, since only a single stereo signal comes out. But that’s probably fine since the other chains will just be silent (but still receiving MIDI). Have I understood it correctly?
What determines if a plugin itself is multitimbral? Its number of outputs?
We have a few synth engines that are natively multitimbral which have separate audio outputs. Fluidsynth is a good example. We use its MIDI and audio routing to configure it as several different processors, each listening on a different MIDI channel and outputing audio to a different audio output. If we want several chains with Fluidsynth then zynthian configures the single running instance of Fluidsynth to act like several different instruments. The user sees multiple chains, each with a different Fluidsynth processor but under the bonnet there is really just one instance. The user does not need to worry about Fluidsynth being multitimbral. In zynthian it is presented as multiple, single channel Fluidsynth processors.
There are a few other engines we do this with.
It may help if you describe what you want to do. Talking in the abstract is difficult to describe workflows. Give us a concrete example of what you want to do and we can advice the best way to achieve it.
I’d like to migrate my mapped sooperlooper setup and companion lighting control app from my existing linux setup to zynthian, my controller for this is the apc25, it has buttons that can only send note on/off, but I want sooperlooper which is already mapped for it to listen to it while the instruments ignore it, however the instruments receive notes over a different midi channel which plays audibly, while this is happening I want my 8 dials to control an effects stack that’s ideally on its own chain, but that part is just CC
the lighting companion app lights up the controller when sooperlooper is recording or overdubbing etc, giving me feedback on whats going down, on my old setup I just used jackctl to set up mappings so that the little alsa midi app connects to the controller and sooperlooper every time
I’m using one of these to play this admittedly somewhat confusing setup. But bear with me.
The instrument produces MIDI output on six channels, which corresponds to six virtual “guitar strings”. The reason that different channels are used is that the response on each “string” is slightly different.
Despite having six channels, the strings are rendered together, as one coherent instrument, and the final output is just one stereo audio signal, not six.
Finally, just to be clear, I’m talking about a custom LV2 synth. It’s not any of the preinstalled engines.
If we compare it with my setup on the computer with just a simple Jack setup, and a plugin host, this is what it looks like:
1x plugin instance
1x MIDI input port, connected to System MIDI Input
6x channels are transmitted on that port (untranslated directly from the instrument, basically)
2x audio out (IOW stereo), connected to System Out
If I could configure my custom installed LV2 synth to also be treated like this, then I believe this would work more or less like I need.
Okay, we have two different topics, both related to private custom plugins. I’m not sure how much we can help if we can’t see there systems you want to use.
I can show you anything you need to see, I think I’ve described what I’d like to do fairly well, what I’ll try to do is create a midi only channel and see if that does the job, then the easiest way to express what I want it to do might be what that already does
The custom lighting program is not neccesary for the system to work, there’s nothing unconventional about my linux setup, I just had some custom mappings in slgui, those arrived on one midi channel, on the midi instrument I had it only responding to a different channel, on the apc25 the keys arrive as one channel, and the top buttons arrive as a different channel, its channel 1 and 2 cant remember which is which
OK krakile! You are talking about kind of MPE. Zynthian currently doesn’t support MPE but it’s a long awaited feature we would like to implement. Indeed, the internals are ready for it.
FYI, zynthian already includes a MPE capable synthesizer, Surge XT, but It can’t be used for MPE until chains can listen several MIDI channels.
Indeed Surge XT has been choosed by Roger Linn as the official synth for his LinnStrument:
Please, open a feature request and i will prioritize this as soon we land current opened tasks. Perhaps we could have basic MPE support by 2025’s springtime.
@kramlie - I will join @jofemodo in moving MPE forwards as soon as we have some capacity in our development effort. I have a MIDI guitar interface that can provide separate MIDI channel per string which would benefit from MPE.
@lanmower - Regarding sooperlooper MIDI mapping… we don’t use it. This has been discussed elsewhere. The subject comes up occasionally because those who already use sooperlooper have implemented their requirements using MIDI mapping within SL but zynthian does not use this feature. Instead, it controls SL with OSC. We present most SL parameters as zynthian controllers which can be bound to MIDI CC in the zynthian way, using zynthian’s MIDI learning. There are a few SL parameters that are not exposed, either because we (I) felt they were not useful in the zynthian integration or because they are challenging to present in the zynthian UI. This too has been discussed and there is this feature request (which I think I added during the SL integration) that may be relevant to your requirements.
I suggest you consider the workflow you require and either raise a ticket for it or add notes to existing tickets. (There are 14 open tickets that mention sooperlooper.)
