Multi-Timbral mode after removal

Using Zynthian
41

@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.

1 Like
42

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.

43

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?

44

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.

45

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.
46

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
47

(post deleted by author)

48

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
49

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

50

JESUS CHRIST

1 Like