Multi-Timbral mode after removal

@lanmower I have updated some of the tickets relating to sooperlooper. I think the crux of the issue for which you seem most vocal is captured by ticket #762 which I have posted a proposed solution. I have also fixed a couple of bugs and made a post in a sooperlooper specific topic where this dicussion may better reside.

I appreciate you have mentioned many bugbares in this topic but they have mostly been presented as proposed technical implementations rather than descriptions of the workflow issue, which has not been as productive as it could have been.

If I understand correctly, you want to have remove control of each parameter of each loop within sooperlooper and I think you also ideally want this to be triggered by MIDI note on/off rather than CC commands. Issue #762 proposes a solution for the first part of that requirement. The second part can already be done by using zynthian’s MIDI mapping and filtering rules, accessed in webconf’s INTERFACE->MIDI Options page by clicking the button below the title: “Midi filter rules” and adding rules to map note-on to CC, e.g. MAP CH#0 NON#60 => CH#1 CC#43 will map MIDI channel 1, note-on 60 (middle C) to MIDI channel 2, CC 43. Note-on velocity is used for CC value. If writting these rules directly into the textbox in webconf remember that MIDI channel is zero based so MIDI channel 1 is represente by CH#0.

You may also be able to do some of what you want already by using the prev/next nudge control to select loops. It isn’t the direct access you crave but it is better than nothing and may fill the gap until we resolve issue #762.

I really hope that this helps you to move forward towards using zynthian’s integration of the powerful sooperlooper and avoids breaking other user’s workflows.

2 Likes

Thats emotional language and directly speculates on some kind of wrongdoing on my behalf, and also wrongfully imagines that I made any demands, even once.

I’ve stated in simple terms facts about the situation and described in detail what matters, how you feel about it is up to you but theres no need to try and soapbox, I’m offering help I’m not making demands, but in order to have a platform with which to actually achieve contributing to zynthian, it has to of course first actually work.

the title of the thread is multi timbral mode after removal :person_shrugging:

in the first paragraph I wrote I stated that I want my different channels to send their original midi channel data to zynthian plugins, instead of translated data, nothings changed.

My pi5 was working headlessly with an early oram, I think it was 7 or 8 months ago (turns out more like a year ago).

The same version had multi timbral mode, I was using that, and I was listening to all channels if I remember correctly.

I was very clear about what I want to accomplish from the start. It’s still the title, and its still the very content of the first post and all the posts after that… I need to get all the midi channels to stay their midi channels as it comes in to the chain, or the whole thing falls apart. I’ll dig around and see if there’s just a simple jack or alsa connection I can script in, it’s not the end of the world.

I just tried the suggested workaround of setting up a midi chain, I set that one up on all channels, and made two dexed channels, one for midi channel 10 and one for midi channel 3, when I played on channel one, the expected silence was replaced with both dexed synths playing, so what all channels does when routed to individual channel tracks does is make them play no matter what the original channel is, and no matter what the output channel is, it is a way to activate them all at once, but its a no-go for activating them independently with midi signals to their channels.

How would I set up an instrument on each keyboard, isn’t that a similar use case?

Ah! Another thin layer of the onion is peeled, revealing a little more of what you want or mean. I re-read the title and inital post and see nothing that indicates you are concerned about changed behaviour. It is not just I who is stuggling to understand what you want and why you want it. Your last post is the first time that I have comprended that you percieve a change in behaviour.

First, I don’t think the “headless RPi5” issue is a regression. I think that RPi5 may never have worked headless. I believe you stated that this was the first time you had used the RPi5 headless and my experiements have proven it is only RPi5 that is affected so, this is a new issue due to new hardware. This needs a ticket in the issue tracker for us to make progress. I have some ideas on how to resolve this.

Next, you say that in a previous version of zynthian (what version?) that MIDI was sent to all chains without any filtering or processing. I do not recognise this behaviour. Since I have known zynthian, MIDI has passed through the MIDI router which filters, processes and routes MIDI. This has undgone some modification over time with some significant work during the Oram development so, behaviour will have changed but MIDI has always been filtered, processed and routed before it hit a chain (or layer as previous version refered to a similar element). If you had started this thread by saying that you do X and that this workflow has stopped working because of some changed behaviour, we would have got to an understanding much quicker without raising the heat of the discussion.

With the information provided, I thought I had understood the issue and gave a detailed response (see my last post) describing how the issue may be resolved. Zynthian does process, filter and route MIDI. That is a core feature and we are not going to change that. If changes in Oram have led to a workflow being broken, then we want to know about it so that we can identify a resolution which may be modifying the workflow or may be a code change. Please do not assume that we know what is inside your head. (I only know what is inside @jofemodo’s head!) You have to tell us. And please don’t assume that we make changes without careful consideration. We spent an inordinate amount of time testing Oram and proving previous workflows continued to be possible with engagment form the community. We then spent some frantic weeks resolving unexpected issues immediately after release. We listen and respond but we need the information.

If you can raise a ticket in the issue tracker that describes the workflow that is broken then we can respond. We want to hear about broken workflows before we hear proposed solutions. We cannot guess.

Saying that there was an…

is not describing a workflow. It is describing a percieved feature and that perception (or at least the description of it) is flawed. The reason I picked up on sooperlooper is that you mentioned it as one of the workflows that was broken but it took a while to drill down to the detail and even now that I think we are there you still don’t confirm or deny.

Please engage with the same level of respect of others that you would expect for yourself. This is a very friendly and often forgiving community and it is rare for there to be heated discussion. Even when that occurs we do our best to focus on the issues rather than personalities.

I have done as much as I can to guide you towards giving us the info we need to help you but, maybe through language, maybe through misundertsandings, we are still not seeing things from the same perspective.

ok then, lets keep it very simple… multi timbral mode is the workflow I’m describing…

many midi keyboards have pads and notes, they play out of individual channels, the pads for instance should only control the drums, and the notes only play an organ, otherwise you get organ pads and organ keys

in reggae you set up two keyboards and play them alternately, each on a channel, to make alternating stabs…
{D86E5C91-0268-4646-95CF-A49BA70BA922}
usually ep and organ, is the only way to kind of imitate this split keys?

having multiple plugins available at the same time is incredibly useful!

should I list more scenarios where you may want two instruments permanently listening, but have one respond to one channel and another to another?

what about bass on a pedalboard and organs on keys? or one of those drum pads that people play with drumsticks? like in this video?

is everything just always going to play till you switch the preset? do you have to select channels in the gui between organ stabs or pedal presses?

Even when my synthesizer is not plugged into the audio I’m always jacking it into midi to get a second sound off of its keys, beacuse otherwise you’re stuck with just one sound at a time, my arrangement will usually have me having drums, a sample keyboard and a synth keyboard all plugged in at the same time.

Here is a thread where someone appears to have done just that…

  • MULTI => MIDI events are not translated at all. They reach routed chains that match the event’s MIDI channel. Zynthian behaves as Multi-Timbral Mode for this input device and the assigned chains.

aaaaand I just found it, if you hold on the midi input device you can enable multi timbral mode :partying_face: exactly what I needed

I felt like the dead parrot guy in the monty python skit lol

cool so now I that I can separate midi channels, mod-ui, puredata, everything is an option again :face_exhaling::smiley:

Is there anything I can do to make this change better known? It cost me a week, I can probably post a reddit about it and make a youtube video

1 Like

Blimey! So your question was, “how do I enable multitimbral mode?” If only you had asked that at the start we could have avoided so much discussion.

2 Likes

Anyway, i plan to allow listening ALL MIDI channels on synth chains. This could be useful for implementing specific workflows and It wont harm.

@lanmower comments make me to reconsider this and now It"s a low hanging fruit. Ready to collect.

Regards

1 Like

JESUS CHRIST

2 Likes

I agree wholeheartedly that’s what I’m trying to go for, sift through the program and find exactly that, low-hanging fruit that wont cost a lot of time but will help the end user :+1:

I feel you man, but the documentation that you linked, in the comment that you referenced with your capitalized explative doesn’t actually detail how to do it at all, and if you look at the forum, recent posts said and I quote GLOBAL STAGE/MULTI-TIMBRAL MODE IS DEAD!

I couldn’t find the menu and so I made a post called ‘Multi-Timbral mode after removal’, since I’m using the testing version after all.

After specifying the title, I described that I want my channels to be able to respond to any midi channel at any time, which is what multi timbral mode does, a feature I knew and loved, lol.

Turns out, after multi-timbral mode was removed in favor of four options, but it appears that the four options was after that removed, and the words multi timbral mode was placed back in, but under a long-press submenu, I have read all of the development threads, but the one guy complaining about it recently had a suggestion to bold-press the menu item, the thread is here, and it’s the only way on the internet right now to find out how to get there, even this thread didn’t help for 22 days, so I’m as surprised as you are.

Ironically its strongly encouraged in the thread with the answer, to ask lots of questions because v5 is new. And his problem was resolved after 5 monts, we’ve gone from 5 months to 22 days that’s big progress.

This is not yet detailed in the manual very well, this is why the thread exists, and now that the information is documented in the community to the degree that it was documented, sparsely, in another thread I found last night, I’m sure it will be included in the very rtfm you referenced :+1: I’d add it myself but there doesn’t seem to be a way to make an account on the site…

Next time you get offended when someone asks a question, write a song about it! I will listen to and thumbs up anything you make

1 Like

For anybody scrolling down to the bottom with the same issue, please long-press your midi device in the admin menu, it has multi-timbral menu options and device ui mapping options inside

Maybe if you’d mentioned you still couldn’t find it after looking at my link you might have found me more helpful.

1 Like

OK! This is done in vangelis branch. Now you can select “ALL MIDI channels” in all chains.
Obviously, when selecting “ALL MIDI channels” for a chain, the router ignore the “ACTI/MULTI” flag for this chain. All MIDI messages from the selected MIDI devices are passed untranslated to this chain. Be aware that this could have undesired/unexpected effects. We need to test this for a time.

Enjoy!

3 Likes

@jofemodo, it turns out that this is not what @lanmower was requesting. Yes, I know we all thought this because that is what he kept saying but in fact, he just wanted to know how to enable multitimbral mode for a MIDI intput device as described in this post that is easily found with a search of the forum with the phase “mutitimbral”. All that wild goose chasing around getting chains to handle multiple channels so that sooperlooper will work how he wants was in vain. It didn’t help that the title of this thread makes little sense to most of us. With hindsight and the benefit of many hours wasted trying to help here, I can now translate the title to something like, “How do I do my workflows when multitimbral mode has been removed?”. With such a title we would have immediately (within minutes (not months or days) have responded saying, “It has not been removed…”.

So, kudos to @jofemodo for rushing out a fix for a very different (almost exactly opposite) issue but let’s be sure that it works well before we release it. We don’t want to introduce issues, especially when the requirement was not actually as urgent as suspected!

3 Likes

I think @lanmower would like to receive ALL MIDI channels untranslated in the sooperlooper chain, so he can use his favorite pre-defined MIDI mapping for SooperLooper.

He probably would need to replace the “default MIDI mapping” by his own. Perhaps we could add some code in the sooperlooper engine to load a “user custom” MIDI mapping when it does exist in:

/zynthian/config/sooperlooper

we already do the same for setBfree user custom config.

Regards

1 Like

I would prefer to avoid adding too many ways to skin each cat. We already have a mechanism for mapping CC to processor parmeters and a way to map note on/off to CC. We may wish to add a way to map note-on directly to processor parameters and we certainly want to add a way to bind MIDI CC to each channel/loop in sooperlooper (which is a wip).

This is very exciting news, thank you :pray: it will help reduce extra channels and routing

or at lest maybe just an instruction somewhere that everybody lands if that’s not possible

Yes note-on features would help for the gui, those are sorely missed… of course they should be untranslated so that they dont flip on when you play drums etc, and also survive different plug orders, and be global mapping capable, so they should ideally be midi channel specific. I’d say both that an a note about the folder path or option somewhere for those wanting to load sooperlooper configs would be first prize, I remember seeing somewhere you put the file somewhere specific but that was after a lot of digging.

If note on mappings to the gui automatically block its midi output to the chains that would be amazing, because then one could take the worlds simplest midi controllers, map keys and those keys stop being notes and start being UI, as long as it doesn’t block further mappings for the same thing

But yeah all of this is fairly easily worked around in this case by mapping to the plugin.

This morning I was thinking about maybe introducing a midi translation phase instead, so that one could say a note on channel 1 note 127 is a cc toggle, it could work from a simple text file, and it becomes that for chains and the gui, maybe that’s a nice tradeoff, allowing advanced setups, not changing the existing code in a big way, and not losing any features or functionality but adding more versatility, and killing a few birds with one stone e.g. emulating toggle etc

A really big part of my effects setup is buttons that you hold for an effect, for instance sending an insert of the voice into a 3/3 delay is very common for dub music, so I usually have a button that you hold and all the inputs feed into a delay or reverb for a moment, I’ve just gotten a midi controller that accepts some mapping so I can finally set this up, but up until now I’d been pretty stuck with my apc25 sending midi notes for its buttons, wishing I could make them momentaries and toggles for effects

Oh yeah and one thing is can the mappings take different mapping for one button for instance? that’s something thats used quite often, like unmute the reverb input while the reverb knob is up, and switch off when the knob is low