Yes, they are encoders, and yes, four are used as zynswitches, and behave much like the V5 hardware. The key25 encoders do not have a push button, though.
1 Like
I have a question, I hope it’s not too much of a detour from the topic:
Looking at the PR for the key25 above, * oscaracena /* zynthian-ui the message:
This branch is 431 commits ahead of, 433 commits behind zynthian/zynthian-ui:testing
What does that actually mean, and are some commits counted as both ahead and behind? Is it just a coincidence that they are so close (431 vs 433) or does that say something about this PR? Please point me at some git doc if this question isn’t making sense.
And thanks for the key25 PR @oscaracena !
1 Like
It looks like the comparison is between branches derived from different parent branches, e.g. one is derived from testing whilst the other is derived from chain_manager. Testing may have moved 431 commits forward since chain_manager was branched from it and chain_manager may have moved 433 commits forward. There would be no chance of us merging those two branches. The PR would need to be merged to the similar branch. In this case the PR has been merged with chain_manager branch where there were only minor differences.
The fact that 431 & 433 are similar is coincidence but influenced by the amount of manual merging that has been done to keep testing and chain_manager aligned, i.e. changes applied to testing were subsequently manually applied to chain_manager as appropriate, hence a similar quantity of changes.
2 Likes
Thanks @riban !
Just like crossing the streams in Ghostbusters…
So is this the end for the wraiths and strays living a precarious existence out on the extremes of testing and recent stable…?
Perhaps code bound for drivers deserves it’s own entrance of some kind… ?
There is always the success problem of way too many drivers to carry in the source which DOS managed with printer drivers . . .
All development should be done against the testing branch. We are about to merge chain_manager into testing which is a substantial change. I would recommend any developers wait for a while until that is done.
Each driver should be developed in a seperate development branch then a pull request made to merge into testing. It would be good to (maybe at some time in the future) consolidate some of the drivers so that we have common code with configuration to reduce the quantity of drivers and avoid the issue that @wyleu mentions. (Too much codebase.)
2 Likes
Just written up some stuff on the wiki.zynthian.org Development section…
Contributing_to_Zynthian_Development
It’s a walk throu’ of the development process for First time developers presented as an FAQ. Hopefully there are answers to allow people unfamiliar with the process but with a desire to do something like device driver coding to get answers to many of the questions that aren’t perhaps immediately obvious.
Comments , praise, and brickbats all welcome.
5 Likes
Hi guys!
Is there any way for a device controller (driver) to store some information (like settings) in the snapshot when it is saved? It would be awesome to have some persistence… 
1 Like
What do you want to save? We could implement hooks for snapshot saving/loading.
It’s just a simple python dictionary with basic types. A callback for saving/restoring would be perfect! 
I’m working on the sequencer, and I would like to assign a note to certain pad. That’s the mapping I need to save.
1 Like
There is a generic midi learning mechanism for assigning notes to trigger pads. And it’s already saved in snapshots.
We should avoid duplicating functionality. Did you test it?
Regards
Regards
2 Likes
I don’t want to trigger the note, I still need to handle the pad in the driver, but configured with an specific note. I’ll check the MIDI learning mechanism, it may be used in the way I need.
Thanks!
Check it and if it doesn’t fit your need we could add hooks so every driver can save/restore its own config dictionary inside snapshots.
Regards
2 Likes
We would need to understand why this is required so that any possible solution is extenisble and purposeful. The snapshot is the state of the system and some configuration. It doesn’t want to bloat needlessly. Have a look to see if there is an already implemented solution and if not, please describe what workflow you are trying to achieve - what, why, etc.
1 Like
Thanks @riban, I’ll review what @jofemodo said about the MIDI learning mechanism, it may be enough.
As a bit of context, I want to implement a driver that works like an step sequencer for the APC Key25. This device does not have a large amount of pads, only 40 (unlike the 128 of the awesome OXI one), so I take the same approach as many other sequencers (like the Digitakt): 16/32 pads will be used as the steps for the bar, and then the remaining pads will be configured with the instrument/notes that you will use. Thus, you can change the “steps pattern” of each note/instrument easily (much like the workflow in the Digitakt).
And, what I want is to persist that mapping. These pads will not trigger any note, they will just be used to change the shown steps (in the pad grid).
I’m not sure if I explained myself… 
I’ve checked it out, and I think that the MIDI learning mechanism is well suited for what it was designed for. But I feel that trying to force it to store what I think is the settings of a driver is not a good solution 
A proper solution would benefit drivers for more complex hardware, IMHO.
8 Likes
I hit the same problem that unroute_from_chains = True in my ctrldev was seemingly being ignored (playing around with a possible AKAI MPD26 device driver).
To confirm to others removing the last_state.zss resolved the issue
1 Like
Hi @chrismat !
Is your driver already working? Please, give some details about what are you doing, please…
Launchpad X doesn’t show colors of ZynSeq anymore. Is there a change to make to the driver ? now we are in Osram version ?