NEW: Control-device manager + controller device "drivers"

Could you try adding this:

lib_zyncore.zmip_set_route_extdev(self.idev - 1, 0)

to your init function?

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.

Regards,

1 Like

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… :thinking:

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.

Could you describe the exact steps you follow for testing?
Could you remove the last state snapshot and start from scratch?

rm /zynthian/zynthian-my-data/snapshots/last_state.zss

Thanks

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! :star_struck: 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 :weary:, but thank you very much for your help!

We can chat for more agile communication. The discourse has a chat tool.

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:

1 Like

Ouch, didn’t know that! :woozy_face: Thanks for the info, I’ll burn a fresh image as soon as I can.

1 Like

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! :blush: ). 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… :wink:

  • 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! :upside_down_face:

3 Likes

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.

All the best!

2 Likes

Tell us if you find some issue with it.

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?

1 Like

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.

3 Likes

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.

Regards,

1 Like

The place would be the wiki. Let me create the structure and post a first example or template. I will create credentials so you can edit.

The best,

3 Likes

Hi!

One more question: Is there any way for the controller driver to receive updates about the status of Zynthian state? I’m specially interested on:

  • Receive an update of playing/recording audio/midi status, in order to provide correct hardware feedback.
  • Receive an update when the current UI screen has changed (for instance, when the user moves from Mixer to Admin menu).

That would be awesome! :slight_smile:

You must subscribe for receiving the right signals. As we still don’t have signals for these events, i will add them and tell you how to proceed.

3 Likes

Great! Thank you very much! :smiling_face::clap::clap:

Done! You have to register the next signal/subsignals pairs:

zynsigman.S_GUI, zynsigman.SS_GUI_SHOW_SCREEN => screen
zynsigman.S_STATE_MAN, self.state_manager.SS_AUDIO_PLAYER_STATE => state
zynsigman.S_STATE_MAN, self.state_manager.SS_MIDI_PLAYER_STATE => state
zynsigman.S_STATE_MAN, self.state_manager.SS_MIDI_RECORDER_STATE => state
zynsigman.S_AUDIO_RECORDER, self.state_manager.audio_recorder.SS_AUDIO_RECORDER_STATE => state

The name after the “=>” is the parameter(s) name(s) for the callback function

You need to import zynsigman and other stuff in the driver’s code, like this:

from zyngine.zynthian_signal_manager import zynsigman

The syntax is for registering a signal is:

zynsigman.register(zynsigman.S_GUI, zynsigman.SS_GUI_SHOW_SCREEN, self)

and for unregistering:

zynsigman.unregister(signal_num,  subsignal_num, cb_func)

For instance:

def init(self):
  super().init()
  zynsigman.register(zynsigman.S_GUI, zynsigman.SS_GUI_SHOW_SCREEN, self.cb_gui_show_screen)

def end(self):
  zynsigman.unregister(zynsigman.S_GUI, zynsigman.SS_GUI_SHOW_SCREEN, self.cb_gui_show_screen)
  super().end()

def cb_gui_show_screen(self, screen):
  pass

Good coding!

3 Likes

@jofemodo and I implemented the signals for these events at the same time, independantly. I have left @jofemodo’s signal names and merged my changes which also include signals for audio player and for multitrack recorder chain armed.

I have also added a driver for the “riband Bluetooth” wearable MIDI controller that I have built. It allows pretty much full control of Zynthian with pad control and indication and zctrl control (the four rotary encoders on the zynthian). If I can free up enough space on my phone I will record some video of it in action. The code is in chain manager branch.

6 Likes

Can we call it the “Blue Riband”?

3 Likes

Totally awesome! And very fast! Thank you very much @jofemodo and @riban! :partying_face::clap:

1 Like