search

mcallegari / qlcplus

Q Light Controller Plus (QLC+) is a free and cross-platform software to control DMX or analog lighting systems like moving heads, dimmers, scanners etc. This project is a fork of the great QLC project written by Heikki Junnila that aims to continue the QLC development and to introduce new features.
Apache License 2.0
921 stars 349 forks source link

MIDI Out Rework #1514

Closed kernel-machine closed 4 months ago

kernel-machine commented 5 months ago

Actually how QLC+ works with midi out is not the best. QLC+ actually can use only a MIDI out for the entire midi device, but if you use a controller like the Akai APC mini mk2, in which the brightness and the flashing rate of the RGB pads depends by the MIDI channel, you have to choose only one MIDI channel for the entire controller, loosing al the LEDs functionalities. Some developer have release tool like that https://github.com/revilo196/mk2apc_4light to mitigate this problem, in which the different velocity are mapped on different channel, but if this kind of controllers can work directly with QLC+ is better.

My idea is to add in the custom feedback section of the widget proprieties two SpinBox, one for lower channel and another for higher channel, that will be used together with the two old SpinBox. immagine

THE PULL REQUEST IS NOT FINISHED, il will remove the draft state once the implementation is end. I have open a pull request just to have a feedback if this kind of feature will be merged, otherwise i will not spend too much time to finalize it, maybe other people likes the current working principle,

The missing parts are:

Finally another parts which i like to modify is the how the values are send in out, actually they are in DMX format [0-255] but before to be sent as MIDI packet they are converted by #define DMX2MIDI(x) (uchar(x >> 1) & 0x7F), and in the case when i have a tables with the velocity related to the pad color by the controller manufacturer like this

immagine It is a nightmare and the users need to calculate the right value to match the color, so i would like to do this conversion only when needed, in a way that the user can enter directly midi values [0-127] if in the current universe the feedback is midi, otherwise for OSC and Loopback [0-255] But this can broke the compatibility with the previous saved projects.

yestalgia commented 5 months ago

Thanks for the suggestion! I can't wait to hear @mcallegari's thoughts on this.

On the official Instagram, I get many requests for support using these types of controllers.

I know you said it was a draft but please don't forget to also implement the QML V5 version if you can.

I wonder if doing an overhaul of the way we do midi feedback will one day be necessary. May I be so bold as to request support for selecting the colour in a dropdown menu to fill the values automatically?

In any case, thanks again for contributing to the project.

mcallegari commented 5 months ago

The problem of this (and many other PRs) is that they focus on a single use case. QLC+ needs to be and stay generic for any usage case (even future ones). One would say this is a life saver for AKAI devices, some other would say QLC+ is too complicated because it has too many options. My point of view is to make changes where they actually make sense. I need to think a bit more about this but a solution is to be found in some dedicated class (eg. a new feedback class) or at input profile level. Will get back to this later

mcallegari commented 5 months ago

I see more commits are going in this open PR. Can we please discuss it or at least can you tell us what you're doing exactly? I still haven't decided what's the best place for this, so your efforts right now might be in the wrong direction.

kernel-machine commented 5 months ago

I think this is a really needed for QLC+, i hope once my code is finished you idea about it will be clear. But if you think that this feature will be never implemented and my effort are useless, tell me now in a clear way!

For now i'm moving in that direction: When the input of a vcbutton is a MIDI device, then in the custom feedback section two new SpinBox are visible to change the lower and upper midi channel (as in the previous pictures). By default these values are the same of the MIDI input values received for that button, but they can be also changed by the user.

While if the button is triggered using a Input different than MIDI, like OSC, everything is as before, so for no MIDI user, this implementation is completely transparent,

Then to have the UI coherent i have implemented the custom midi channel also for profiles, also in this case only on profiles for MIDI devices.

Your idea to implement this feature only on input profile is not a valid option for me, if i have a green button in my virtual console, i should be able to change the color of the controller pad from the button proprieties, and not from the pad settings inside the midi profile.

mcallegari commented 5 months ago

I get the idea and I too think a solution is needed. Being also the architect of this project, I have the whole picture (and 12 years of history) of all the usages people make of this software, so if you don't mind, I am the one deciding how a big change like this should be implemented and where in the code. Yesterday I told you I had to think a bit more about it so I expected you to stop the development until I decided what is the best solution for the project, also not to waste your efforts on it. For sure I don't want to add complexity to Virtual Console widgets just for the AKAI devices. Also, please don't draw conclusions in my place.

kernel-machine commented 5 months ago

Ok, i understand your point of view. I hope that the code written until now can be useful for a future implementation of this feature by me or by somebody. For now i'm stopping to work on this.

yestalgia commented 5 months ago

I get the idea and I too think a solution is needed. Being also the architect of this project, I have the whole picture (and 12 years of history) of all the usages people make of this software, so if you don't mind, I am the one deciding how a big change like this should be implemented and where in the code. Yesterday I told you I had to think a bit more about it so I expected you to stop the development until I decided what is the best solution for the project, also not to waste your efforts on it. For sure I don't want to add complexity to Virtual Console widgets just for the AKAI devices. Also, please don't draw conclusions in my place.

Hey gents I don't think this is a bad step, it seems to be in the right direction.

@mcallegari can we maybe use this as a starting point before a complete ground-up approach is possible? I know there's nothing more permanent than a temporary solution but we will need to remake profiles and this would give us a way to test.

mcallegari commented 5 months ago

@mcallegari can we maybe use this as a starting point before a complete ground-up approach is possible? I know there's nothing more permanent than a temporary solution but we will need to remake profiles and this would give us a way to test.

Short answer: no. Long answer: This would mean:

Is this really what you're proposing?

Guys, let's write this once and final.

mcallegari commented 5 months ago

The latest build covers color translation. Now I'm gonna decide how to do double feedback. It's gonna be quite tricky. Today I'm gonna pick up an APC Mini MK2 so I can do tests myself with it.

mcallegari commented 4 months ago

With the last commit, this can be closed.