In terms of usability, if implemented, this is what it solves:
The problem in the flow is as follows:
1. You've decided to automate something, let's call it ReceiverX.
2. You create a sender: At that moment, what's on your mind is deciding which message configuration best suits ReceiverX.
You don't remember that you have to connect it to Control; it's something your mind takes for granted, especially if you've already made a connection of that type in that session (your subconscious mind says, "I already made the connections with Control").
3. If we remember, that breaks the workflow. To further disrupt it, we have to change windows (operations space). Make the connections and go back...
4. Where was I going? Who was the receiver? The flow has been broken.
Of course, this is exaggerated, since the entire process happens in seconds. And at the same time, it's not exaggerated, because those interruptions are there (they're actually making noise and causing confusion in the background).
Either proposal would solve this problem.
If the option is in the p-plugin, as I indicated, it should be enabled by default if the dedicated Qtractor Control ports exist, and disabled if they don't. The reasons are that the safe way to automate internally is through Qtractor Control, and for automation outside of Qtractor, Qtractor Control is not useful (or at least I have not found a way to make it useful).
For mixed flows (sending external and internal control messages), the option in p-plugin give the user greater control, that's true.
If you think it's not worth it, I understand. It's now functional, and you can't imagine how grateful I am.
In terms of usability, if implemented, this is what it solves:
The problem in the flow is as follows:
1. You've decided to automate something, let's call it ReceiverX.
2. You create a sender: At that moment, what's on your mind is deciding which message configuration best suits ReceiverX.
You don't remember that you have to connect it to Control; it's something your mind takes for granted, especially if you've already made a connection of that type in that session (your subconscious mind says, "I already made the connections with Control").
3. If we remember, that breaks the workflow. To further disrupt it, we have to change windows (operations space). Make the connections and go back...
4. Where was I going? Who was the receiver? The flow has been broken.
Of course, this is exaggerated, since the entire process happens in seconds. And at the same time, it's not exaggerated, because those interruptions are there (they're actually making noise and causing confusion in the background).
Either proposal would solve this problem.
If the option is in the p-plugin, as I indicated, it should be enabled by default if the dedicated Qtractor Control ports exist, and disabled if they don't. The reasons are that the safe way to automate internally is through Qtractor Control, and for automation outside of Qtractor, Qtractor Control is not useful (or at least I have not found a way to make it useful).
For mixed flows (sending external and internal control messages), the option in p-plugin give the user greater control, that's true.
If you think it's not worth it, I understand. It's now functional, and you can't imagine how grateful I am.