I have made changes in zynthian_layer.py to handle the bank selection (MSB) midi events, to enable a DAW to select a bank. Since Jose seems the only person currently developing the software, how can I ensure that the code is reviewed, discussed and if accepted included in the trunk? I saw some guidelines in the wiki, but want to be sure about your current wow.
Simply make a PR, @Jan
Regards,
Will do that.
Want to do a PR. Is this still the use practice? Collaboration guidelines for Github projects - #6 by riban
Although that was only a proposal without any further comment, it is good practice and I would recommend following that path. Let’s take the lack of response as tacit agreement .
Ohhh! You shouldn’t be thinking like this. There are other intrepid developers that have contributed to zynthian code, and some of them have made HUGE contributions. To mention some of them:
-
Mr. @riban => He implemented the VU-meter and the sequencer from scratch. Also he re-implemented the MIDI recorder and have made lot of improvements, bug fixes, intelligent proposals, etc.
-
Mr. @mheidt => He contributed largely to the webconf, including the websocket stuff and much more!
-
Mr. @C0d3man => He implemented the native port of Dexed to LV2 that we are currently using. He also implemented the Pianoteq engine and has contributed lot of “install recipes” used by the image-building scripts. Did i ever mentioned that he is the second person that built a zynthian? ;-D
-
And many more. You can check the github commit list.
Regards,
Hi!
I’ve encountered some little bugs here and there, I’ve submitted the corresponding issue, and also I’ve made some PR to fix them But I’m concerned that in the github issues’ repo they will be stalled; I can see there is much more activity here!
So, just to press a little but more, here they are:
- Add Audio chain fails:
- zynthian_ctrldev_base:
init()
not called on multiple inheritance: - zynthian-ui: zynthian_gui_zynpad.py throws IndexError when updating pad status:
- zynthian-ui: Zynpad, last pad not updated:
I’ve added a link to the PR inside the Issue (commented) as well.
Thanks for reviewing!
Hi @oscaracena !
Thanks a lot for your reports & PRs!!
I just merged 1 & 4. I found a simpler solution for 3
Regarding 2, it’s an interesting “problem” and i would like to think deeper about it. Read my comments.
The best!
Great! Thanks a lot for reviewing & merging! That was super fast again!
Let’s think about 2 a little bit more.
Cool! I agree that the solution offered for the second issue felt wrong but I haven’t had time to investigate. (Maybe it is right!?!?!)
I had noticed 3 a few times but have always been too busy to investigate. (Some things look like they may be simple to resolve but you know you will be sidelined from the task at hand so don’t investigate!) Thanks for engaging in these issues and resolving them. Now… there is a long list of issues in the tracker .
It solves this issue, but it’s not a general solution. We should try to understand how the python gods envisioned this “cooperative multiple enheritance” for us, the poor python users. Fully understanding the super() function seems to be the key for this.
Regards
The question may be " Why does Python call both super-classes’ unit()
methods?" It should call just one… or not?
I uploaded a minimal example and it is how Python is implemented, why not use it if it solves our problem?