Sorry @jofemodo,
is there a right way to send a midi event back into Zynthian? I thought, asking the chainmanager for the right chanel did exactly this. Could you push me in the direction to do this better?
1 Like
I see. But there is no documentation on push 1 how to use the second port and how to program the pad array to use that other port. Does that mean that the driver shouldn’t be take in zynthian repository to prevent disappointment by users expecting more than is possible? Or should I put a message in the welcome screen that this driver is experimental and there is no help about problems.
As I see it, there is no other way to use the Push 1 in Scale / music mode and it would just be a functional controller. Shall I take out the Keyboard part of the driver? Or should I deactivate it as a hidden gem implementing a control var that would have a comment about the problems this hack induces?
I could incorporate the ctrldev_base_scales driver into the Push 1 driver so that I don’t give other developers false hope that it could somehow work this way.
Is that a possible way or is it better to leave my driver out of zynthian repository?
I would prefer the “hidden gem var” way to leave the main repository drivers intact with 100% working drivers in a clean state. But people knowing about the risk could use it for harmony lessons and inspirations. In this use case problems with jitter are not not as important as for live music. I saw a discussions in this board about Wicky-Hayden with pricy hardware tools. Sure, they would work in live mode. But the possibility to try such tools in an emulation environment like this driver could make the such devices more valuable than in theory.
Playing around with this modes gave me new inspirations for using different modes in my own poor composition trys.
What do you think of my thoughts?
1 Like
@tunagenes
Thanks now I understood this failure is normal for push request from developers who have no rights in repository.
I did something right and wrong, but @jofemodo pushed me the right direction in the push request disussion stream.
Thank you.
1 Like
It is not that the ctrl driver should be hidden. It is that time-critical messages like note-on should pass through the realtime path that already exists. Ctrl drivers are to allow more complex integration of control that is less sensitive to non-realtime path, e.g. adjusting a plugin parameter which wouldn’t be noticed if delayed by a few tens of milliseconds.
If you have created some useful processing of note-on messages then that should be abstracted to a LV2 plugin that can be inserted in the real-time path and would benefit all users.
1 Like
Hi @niels and other ctrldev driver developers!
I just implemented and pushed to Vangelis branch a mechanism to allow unrouting a list of specific MIDI channels from the driver. You can specify a bitwise mask with the channels you want to unroute, like this:
unroute_from_chains = 0b0000000000000011
to unroute MIDI channels 0 & 1.
To unroute all MIDI channels, you can still use the boolean value:
unroute_from_chains = True
or specify the bitwise mask like this:
unroute_from_chains = 0b1111111111111111
or this:
unroute_from_chains = 0xF
Good coding!
2 Likes
Do yo mean 0xFFFF? Otherwise, how do you differentiate between 0b1111 and 0xF? 
Yes, of course. 
0xFFFF
Regards
2 Likes
Yep.
Could this be a base lv2 router unit upon which the ctrldev mechanism would operate on an API from python?
Thanks @jofemodo , this helps a lot! I got it to work as intended, but while developing I did encounter weird stuff (which I also already may have had when fiddling with just the Boolean values): a MIDI channel (or the device when using False) staying unrouted even though its setting was not to unroute (gotta love those double negatives). Also after unloading the driver, also after reboots, after removing pycache directories, switching to vangelis to clear any custom driver, switching back to my dev branch… Finally I chose to ‘Remove all’ (Chains and Sequences) from the Main menu, rebooted, and then—poofff—it worked (i.e. MIDI channel 1 was blissfully routed again for 0b1111111111111101).
Any idea what could cause this very perceived stickyness? Note I have two drivers targeting the same device.
Hi @niels !
When unloading the driver, it should reset the MIDI device routing state.
To load a new driver, the old one is unloaded first, so it should work. Anyway, i will check tomorrow and perhaps add some extra line to be sure.
Regards
2 Likes
I looked up the specifications for Push 2. And I can say, yes it would work. CC are mostly the same. Just the display-routine needs to be adapted. That shouldn’t be a big problem having a push 2 to do it.
BUT: it seams that it is not possible to use Push 2 and Push 1 any more as a keyboard like I mentioned. They send Control Information and midi on / off at the same channel at the same device. You just can use it as a keyboard without a driver or as a controller with my driver. Not both together. The “midi send” hack to use the Push as Instrument AND Controller is not supported because of jitter problems. Look in this discussion for that.)
Push 1 (and I suppose Push 2 also) lack the needed own intelligence, because the are developed to be fully programmed by the Software, they controll (Ableton Life). So the instrument part isnt working. It seams not bepossible for my understanding to route full channel 1 information to the chains without driver AND to the driver. But also if that would be possible the driver culdnt change the event note to transpose it to a usefull scales mode. So you would have just a semi-tones controller from Note 36 to note 99 which doesn’t seem very useful.
As I understand that would be possible with LV2, but we are out because Pushs send all Information at the same channel. So the new unroute Function for specified channels doesn’t help for “1-Midi-Channel”-devices.
@jofemodo : Do I see something wrong?
2 Likes
Thanks for coming back. Even as a controller there would be value in it so I’ll keep watching
Hi @brumby !
Yes. This is now possible. You can decide for each ctrldev driver what MIDI channels are routed to chains and what MIDI channels are unrouted from chains (reserved for UI integration).
Please, see my comment above:
Regarding your attempt of using the ctrldev driver as a MIDI processor, this is not the intended use-case for ctrldev drivers.
Of course, what you want to achieve is perfectly doable, but zynthian’s ctrldev drivers are not the tool you need. You can “force things” like you are doing in your current implementation, but it’s not the right way. The right way is implementing the “scales” code into a proper LV2 plugin that can be executed inside the jackd’s Real Time path. Indeed, a simple jack client would do the task, but it would be more difficult to integrate with the rest of zynthian stack.
Regards,
2 Likes
@jofemodo maybe the filter you created needs to be more complex, allowing routing of each type of message on each channel. We could hold a map of MIDI commands that are routed direct with jack and/or routed to Python. A driver could then set the filter for channel and command. (Possibly value, but that maybe a step too far!) The map could possibly be a 8-bit value that indicates the command type and channel, maybe with some helper functions for adding all channels, all commands, etc. so that a python call could request a channel be excluded and the map holds all commands in that channel… but that might add to processing.
Hi @riban !
I already thought about it. Yes, we could add complexity to the filter and some use-cases could be managed in this way. But filter complexity grows easily when you try to cover all use-cases. If we are going to follow this path, i would consider to integrate “mididings”.
Anyway, i don’t think this is going to solve @brumby’s use-case, as he wants to process MIDI in real-time and this can be only done via LV2 plugin or any other jack client.
Wishful thinking: Could we define some kind of minimal MIDI processing unit that can be loaded inside the zynthian router, specifying the insert point?
Regards,
2 Likes
Chiming in here (I feel guilty about suggesting passing on note events to zynseq—although @brumby might also have found out by themselves. I think making the filter more complex could solve some use-cases but not this one, even if there were no scaling involved. Sometimes note events would be real-time jack stuff, sometimes used to control stuff the ctrldev way.
Concerning lv2: nice for MIDI processing, but @brumby also wants feedback in the device itself (lighting up tonica notes etc.). I do not think that’s doable with lv2, or is it?
It seams to me that Push Devices ar completely out, because they don’t send on different midi channels.
Now my hope is your var “unroute_from_chains”:
As I understand:
The driver sets unroute_from_chains” = 0x1 to let the channel_1 events to get Midi-events from chan 1 ot itsself. With that it cuts off the channel 1 midievents coming from push 1 to get through to the sound engines. In thins mode he cound do its control thingy.
The it sets the var “unroute_from_chains == 0x0 to route midi-events from Push 1 again to the sound engines. But it cuts itself from getting any controll event from Push 1
First Question: Is it possible to let the driver switch “unroue_from_chains” on the fly to change routing behavior?
Second Question:Is it possible to get through a feature request to let switch chain_manager by a CC or PC the driver back to “unroute_from_chains = 0x1”.
Third Question: If not number two
Would my scales-LV2 plugin be so powerfull to switch this var in the device-driver on the fly to bring the driver back to control over midi-channel 1 events?
Am I wrong with my interpretation of unroute_from_chains?
My english could be too bad to understand your answer?! Please repeat for dummies. Or are we talking at cross purposes?
I feel a little helpless.
Of course it’s. If it can be conceived, it can be coded 
3 Likes
Not currently, but it could be implemented quite easily.
I don’t see what you want to achieve with this. It’s your driver who should do this switch when you need it.
You don’t need to do this switch, because you can split the MIDI stream into 2 different MIDI channels, so the “processed” MIDI notes would use, let’s say, MIDI channel 2, while keeping the control MIDI events on MIDI channel 1.
Regards,
1 Like
Ah I understand an LV2 can send events which reach the keyboard driver.
1.) Are there global LV2Drivers possible that translate midi events? Or hast the LV2 to be loaded into each chain to do its thing?
2.) Is it possible for a keyboard driver to load the necessary LV2 driver by himself in the necessary places or place (whatever: chains or global)?
I assume a switcher LV2 that filters incoming messages and sends them to the keyboard driver or to the chains would be needed by every keyboard that sends ALL Midi-events on one channel. I assume there are lots old keyboards which do this way.
I could develop such a driver as a gift for this project if you see the usefulness for other developers that fall over this problem.
Secondly I would implement afterwards this eventswitcher to a scale switcher like in my driver which would help any developer with dumb devices to do the same, what my driver hack does.
So I would leave it to you if I should put work in such an extension?
I understand the problems with my hacked driver concept. So that it is in no state to get into our main Zynthian Repository.
So:
- Is there a need for support of devices, that send out midi just on one channel?
- Is there a need for an lv2 that helps to create scales and modes on dumb pad arrays?
I would love to give this a try and spend the work to Zynthian project, but for my own use case the hacked driver fullfils all my requirements. The development of this driver for my personal delight also fullfilled my expectations in learning python and understand some inner parts of Zynthian, so that I can appreciate more its complex beauty.
I would love to get in a discussion if such driver in two states would be of any use for Zynthian project?
1 Like