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

Add support for LCDs #448

Closed
helgoboss opened this issue Sep 16, 2021 · 0 comments
Closed

Add support for LCDs #448

helgoboss opened this issue Sep 16, 2021 · 0 comments
Labels
enhancement New feature or request high priority

Comments

@helgoboss
Copy link
Owner

helgoboss commented Sep 16, 2021

Current state:

  • It's possible to program LCDs in EEL language by using the "MIDI script" source.
    • Needs programming skills.
    • You can't access any other data than the current numerical target value ... no track name, no nothing.
  • It's possible and convenient to control the 7-segment display on MC (Mackie Control) devices in order to display the current (numerical) target value as percentage by using the the "Mackie Control" controller preset.

Solution approach:

  • Displaying target properties which are not the current numerical target value could be achieved by letting targets (but also ReaLearn globally) expose key-value pairs and making them accessible in the already existing "MIDI script" source.
  • "MIDI LCD" source which supports various ways of programming LCDs (builtin) and accessing the key-value pairs
  • "OSC" source should support string type in same way

In general, usage should be straightforward:

  • Controller mapping should expose one line on the LCD via LCD source as a named virtual control element "ch1/lcd/line1", not yet mapping any info, just defining the LCD type etc.
  • Mapping selected track's name to that line (or any other globally reachable info):
    • Source: Virtual control element "ch1/lcd/line1"
    • Target: "Global/Project: General info (feedback only, for displays)"
      • Display expression: "{selected_track_position}. {selected_track_name}"
  • Mapping formatted target value to that line:
    • Target: e.g. "Send: Volume"
      • Display expression: "{value_in_db} dB"
  • Mapping send name to that line:
    • Target: "Send: Volume"
      • Display expression: "{target_track_name}"

Related: #380
Losely related: #187

@helgoboss helgoboss added enhancement New feature or request high priority labels Sep 16, 2021
helgoboss added a commit that referenced this issue Sep 30, 2021
helgoboss added a commit that referenced this issue Oct 4, 2021
helgoboss added a commit that referenced this issue Oct 4, 2021
helgoboss added a commit that referenced this issue Oct 8, 2021
helgoboss added a commit that referenced this issue Oct 8, 2021
…rect comparison)

It pushed out feedback too infrequently if the change in terms of percentage
was too small but the absolute change quite significant. That could happen
e.g. with seek target and a huge project size.
helgoboss added a commit that referenced this issue Oct 8, 2021
Idea: Replace half-hearted Derivative-based source equality/hash stuff
with something explicit. Distinguish between symmetric matching based on
source addresses (for feedback use cases) and asymmetric matching
(for source filtering use cases).
helgoboss added a commit that referenced this issue Oct 8, 2021
helgoboss added a commit that referenced this issue Oct 8, 2021
helgoboss added a commit that referenced this issue Oct 8, 2021
helgoboss added a commit that referenced this issue Oct 9, 2021
helgoboss added a commit that referenced this issue Oct 9, 2021
as preparation for cheap source address creation and comparison
helgoboss added a commit that referenced this issue Oct 9, 2021
helgoboss added a commit that referenced this issue Oct 9, 2021
helgoboss added a commit that referenced this issue Oct 9, 2021
helgoboss added a commit that referenced this issue Oct 10, 2021
helgoboss added a commit that referenced this issue Oct 17, 2021
- based on final source feedback value, not the normalized target or mode value (important because
  different target/mode values can lead to the same source feedback value and vice versa - it's
  a matter of difference in resolution/tolerance)
- at the moment takes care of preventing consecutive duplicate feedback output per output,
  not per feedback address, so there could still be some flickering when assigning one knob to multiple
  parameters and one causes changes in feedback and the other one not (then the feedback interleaves and
  we have duplicate feedback per feedback address)
- should prevent display flickering, e.g. on SiniCon controllers
helgoboss added a commit that referenced this issue Oct 17, 2021
helgoboss added a commit that referenced this issue Oct 17, 2021
- this takes feedback duplicate prevention one step further by preventing
  even interleaved feedback to different addresses
- shouldn't leave anything to be desired
helgoboss added a commit that referenced this issue Oct 19, 2021
- Make color applicable to numeric feedback as well
- Adjust user guide
- Fix Clippy warnings
helgoboss added a commit that referenced this issue Dec 22, 2021
By sending short messages as separate messages
instead of batched. Previously, only the last digit
was displayed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request high priority
Projects
None yet
Development

No branches or pull requests

1 participant