UPDATE 2: I’ve edited the “Capture MIDI from” setting of a chain, and removed every source (as you said, ‘Key 25 MIDI 2’ is disabled and I can not enable it). Then, the chain does not receive events from MIDI 1 (or any other source), but is still receiving events from MIDI 2
This call should “unroute” the input device from the chains and it’s called from the “setup” function in the base class. I don’t understand why the device is still routed to the chains in your setup!
You can get the current routing by calling this.
lib_zyncore.zmop_get_route_from(izmop, izmip)
izmop is the chain index (well, indeed is the router’s output port index)
izmip is the device index (again, it’s the router’s input port index)
Some thing like this will help debugging:
for i in range(17):
routed = lib_zyncore.zmop_get_route_from(i, self.idev-1)
logging.debug(f"Routed to izmop {i} => {routed}")
The routes should be set to 0 for all izmop from 0 to 16.
Ok, I put that line inside the init function, and I printed the routes immediately after, and everything seems fine (all returns 0). BUT, I also put the print in midi_event, and there, channels from 0 to 15 get routed (zmop_get_route_from returns 1), and only channel 16 get 0.
Something between init and midi_event is changing the routing…
UPDATE: If I set the route again the first time midi_event is called, then it stops sending events, and it keeps that way.
UPDATE 2: I’ve added a print inside the C function zmip_set_route_extdev, recompiled, and tested again. It is called only once, in the ctrldev’s setup(); the re-routing must be donde elsewhere.
That was it! I removed the last_state.zss and started from scratch, and now I don’t hear any note coming from the control keys! I thought that just removing the chains will do, but there were something bad from any older tinkering…
I’m very sorry for wasting your time , but thank you very much for your help!
I’ve gotten the impression that doing an apt upgrade is a seriously bad idea on a Zynthian because it can write over many carefully balanced and interdependent modules with updated but now incompatible ones.
This is one of the places where I got that impression:
An update on this: I’ve switched to branch chain_manager to continue the development, as there are interesting changes on the way control devices work (and I love them! ). So, I’ve updated, fixed and finished the support for the mixer. Now it works this way:
The following is valid only for mixer modes, which are activated using SHIFT + VOLUME or PAN buttons. Modes “send” and “device” are reserved for other purposes…
I’ve extended the bank idea to the knobs, so for every function, you can control the first 8 chains with bank 0, and chains 9 to 16 selecting bank 1. You can change the bank using SHIFT + LEFT or RIGHT buttons.
Pressing and holding SHIFT will show the current mode: “volume” or “pan” (in Track buttons), and the current function: “mute” or “solo” (in Scene Launch buttons).
Each knob controls volume or pan of each chain (depending on the current mode and the selected bank). Each Track button controls mute or solo of each chain (depending on the current function and selected bank). To control volume or pan of main chain, press SHIFT while using Knob 1. To control mute of main chain, or remove all solos, press SHIFT + STOP ALL CLIPS buttons (action depends on current selected function).
And that’s it! Next thing will be the “device” mode, which will send CUIA messages to the user interface. Stay tuned!
It’s great that you are using “chain_manager”. Tell us if you find some issue with it.
Regarding the driver you are writing (and the other ones), i’m thinking that it would we good to have documentation for each one, explaining modes, functionality and how it’s mapped to the controller actuators (knobs, faders, pads, buttons, etc.). Some graphic support will be great too.
I say that because it seems that your driver will be a very good example, having several modes, that include mixer, zynpad and other UI control. I will try to write a little documentation for the 3 drivers i wrote:
Novation Lauunchpad MINI
Novation Lauunchpad MINI MK3
Akai MIDI Mix
Perhaps we could cooordinate our effort and put a good basement that serves as example and guidance for others.
Sure! I’ll use the github issue tracker, I presume is a better place, isn’t it?
…i’m thinking that it would we good to have documentation for each one, explaining modes, functionality and how it’s mapped to the controller actuators…
Totally agree! I was thinking the same, that without proper documentation, it will be harder to use. I’ll do my best explaining the details and functionality. Where should we put it?
Would it be beneficial to have a generic driver that can be configured, e.g. some devices may use MIDI note for state control but just use different values.
Totally agree, but let’s wait until having more driver examples, so we can “abstract” what has more sense.
I.E. perhaps it has more sense to have a “Novation MK3” generic driver because all novation MK3 devices are very similar, etc.
I thought that just removing the chains will do, but there were something bad from any older tinkering…
, but thank you very much for your help!
Thanks for the info, I’ll burn a fresh image as soon as I can.
). So, I’ve updated, fixed and finished the support for the mixer. Now it works this way:
