Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback and Control Transformation for Toggle Mode #1

Closed
DLongoni opened this issue Jul 15, 2020 · 9 comments
Closed

Feedback and Control Transformation for Toggle Mode #1

DLongoni opened this issue Jul 15, 2020 · 9 comments
Labels
enhancement New feature or request
Milestone

Comments

@DLongoni
Copy link

Hello,
currently Feedback and Control Transformation are available only in Ablsolute mode. It would be nice to have them in Toggle mode as well.
I guess it would also make sense in relative mode, even though I have never fount it necessary yet.
Thanks

@helgoboss helgoboss added the enhancement New feature or request label Jul 16, 2020
@helgoboss
Copy link
Owner

Having feedback transformation in relative and toggle mode makes sense to me because it's always the same principle and always works with absolute values.

Having control transformation in relative mode could potentially be interesting but would be much more complicated to understand because x could be either a relative or an absolute value and y as well. I think it would be good to wait until someone comes up with a reasonable use case for this instead of adding it just for the sake of completeness.

Having control transformation in toggle mode appears a bit pointless to me. Either you want a standard toggle behavior, then you choose toggle mode, or you want something more custom, then you choose absolute or relative mode.

@DLongoni
Copy link
Author

Agreed for relative mode. Regarding toggle mode I can ony think about the use case I am asking it for: in my case, the feedback value affects the led color. In this situation I'd like to toggle between colors different from the midi CC values 0-127, whic in my case are "turned off" and "yellow", but I'd like to switch between green and red which are more visible, for instance. This can be clearly achieved using the Source Max/Min parameter in toggle mode, or alternatively implementing a feedback transformation formula for Toggle mode. I think that if you are interested in developing this functionality it's really about how you prefer to implement it, either privileging design or ease of implementation.

Now allow me a moment of stream of thoughs about possible future features, just because they might affect design decisions if you think they make any sense. Imagine if the formula cound check on a few status variables... I could use a formula like "If selected track is muted then light the button red, otherwise green"... Otherwise, let's say I have a "Loop region x" trigger. Then it would be very useful to light the button in a specific way when the cursor is inside region 1. But maybe this would make more sense to be implemented ad an absolute mode. I'm about to write a feature request on this as well. At some point I will stop to annoy you, I promise

@helgoboss
Copy link
Owner

Regarding toggle mode I can ony think about the use case I am asking it for: in my case, the feedback value affects the led color.

Feedback transformation in toggle mode is okay. I only found arguments against control transformation in toggle mode.

Imagine if the formula cound check on a few status variables... I could use a formula like "If selected track is muted then light the button red, otherwise green"...

Making this possible also crossed my mind but I see a few issues with that:

  1. User expectations
    • I think in a scenario like the one you describe, users would expect that the LED will turn from green to red when the selected track's mute button is pressed. This is not going to happen though because if it's just the formula that queries the track mute state, ReaLearn won't know that it has to listen to it in order to send feedback whenever it changes. The LED color will change as soon as the target value changes, whatever that is in your mapping.
    • The only reason why ReaLearn knows when to send feedback and why it can do that without a big performance impact, is that it knows the targets (e.g. "Track mute") and can listen to the target state.
    • Better think in terms of targets in ReaLearn, they are the key to feedback because they deliver both the correct feedback value and the correct moment when to fire feedback.
  2. Thread freedom
    • Right now, transformation functions execute in the main thread. But they could just as well execute in the audio thread. This might be desirable in future.
    • By letting the transformation function query REAPER state, you lose the possibility to execute it in the audio thread.
  3. Where to draw the line
    • The scope of this API is potentially very large, potentially as large as the ReaScript API itself.
    • The best thing would be to just make everything available that is also available in a ReaScript - but AFAIK that's not possible via REAPER API.
  4. KISS
    • Not sure if giving something which is supposed to be a simple formula within a small mapping such power.
    • That might add quite some complexity to ReaLearn and make it more difficult to scale and maintain.

@DLongoni
Copy link
Author

Regarding toggle mode I can ony think about the use case I am asking it for: in my case, the feedback value affects the led color.

My bad, totally agree on this

As for the rest, you clearly have the very best perspective in terms of software scope and development. I absolutely support your choices and points of views, and my comments are only written in constructive terms! This said, for points 2-3-4, I fully agree. As for user expectations I understand performance and technical concerns/limitations. As for user expectations in general, I think that having a surface state that reflects the DAW state in a way that involves more that one single aspect/parameter (i.e. one button that selects a track when pushed, and tells you if a track is muted with its color) is desirable from a user perspective. Then again maybe this will not be a huge drawback for anybody, just pointing that since a few control surfaces natively have this kind of behavior, then the user might expect/apprecitate it even when using relearn.

In general though I think you arguments are more than valid, especially for this stage of the software development!

Thank you for the torough reply.

@helgoboss
Copy link
Owner

Now I'm beginning to understand your use case. Maybe there's a better way than formulas to achieve it. Let me think about it.

@helgoboss
Copy link
Owner

I think it would help to talk about particular examples. Let's focus on your use case "one button that selects a track when pushed, and tells you if a track is muted with its color".

Wouldn't that be possible already now, without even using formulas? Let's say we have 8 buttons and 8 tracks. Then we need 8 control-only mappings with "Select track" target for letting each of the buttons select one of the 8 tracks ("Select exclusively" enabled). And we need 8 feedback-only mappings with "Track mute" target and "Track must be selected" enabled. That should do it. It should automatically update feedback in response to changes in the track mute status AND track selection.

@DLongoni
Copy link
Author

Cool, I didn't think about the feedback only mapping! It works exactly like you said! I have to experiment a bit with this but it looks promising! Thanks

@helgoboss helgoboss added this to the 1.10.0-pre7 milestone Jul 29, 2020
@helgoboss
Copy link
Owner

helgoboss commented Jul 29, 2020

Solved via b653f1a: Feedback transformation is available in all 3 modes now and has the same behavior (feedback is always absolute).

@DLongoni
Copy link
Author

Awesome, thank you so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants