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 multiple device pairs and sections per instance #870
Labels
enhancement
New feature or request
Comments
You mean, only one of the pair is the input device, and only one is the output device? Speaking of multiple controllers, for ReaLearn SY, I built FX Chains that have
|
helgoboss
added a commit
that referenced
this issue
Jun 19, 2023
New feature "C" (multiple units per ReaLearn FX instance) is implemented and will show up in upcoming ReaLearn 2.16.0-pre.8. |
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
because instance-panel button not usable if overlaid by unit panel
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Dec 28, 2023
helgoboss
added a commit
that referenced
this issue
Jan 1, 2024
helgoboss
added a commit
that referenced
this issue
Jan 1, 2024
helgoboss
added a commit
that referenced
this issue
Jan 2, 2024
helgoboss
added a commit
that referenced
this issue
Jan 2, 2024
helgoboss
added a commit
that referenced
this issue
Jan 2, 2024
Important especially for additional units because only the compartment parameters of the main unit are mapped to the plug-in parameters.
helgoboss
added a commit
that referenced
this issue
Jan 2, 2024
helgoboss
added a commit
that referenced
this issue
Jan 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm thinking about adding support for multiple input/output devices within just one ReaLearn instance.
Motivation
The motivation comes from Playtime 2. I want to make it more straightforward to add multiple controllers controlling the same clip matrix.
At the moment, controlling the same matrix from multiple controllers is possible but not straightforward. One must add one for each controller one ReaLearn instance and connect that instance to the "main" instance with the clip matrix. This is complex and doesn't feel symmetric. For ReaLearn itself, this complexity was acceptable because communicating between multiple instances was a rare use case and why make something user-friendly that is rarely needed?
But with Playtime 2, it's different. Controlling one clip engine with multiple controllers is a common use case. Although Playtime 2 is integrated in ReaLearn, I don't want to force users to become familiar with the intricacies of ReaLearn. After all, Playtime's focus is having an intuitive and user-friendly user interface.
Basic idea
New feature A: Device pairs
The basic idea is to allow adding multiple device pairs to one ReaLearn instance:
Each device pair has 2 properties:
New feature B: Ability to specify for each mapping source a device pair (optional, maybe in future)
Of course, the ability to define device pairs alone wouldn't make any sense! It needs additional features to make use of them.
One such feature would be to allow the user to specify for each mapping source which device pair should be used. So instead of just saying source "MIDI note velocity on channel 8", one could then say "MIDI note velocity on channel 8 of device config 2".
This would be most interesting for controller compartments with virtual targets, as it would enable combining multiple hardware controllers into one big virtual controller. However, building a virtual dream controller in order to control Playtime from multiple hardware controllers is actually not really what's needed. What we need is the ability to dynamically add multiple hardware controllers that all control Playtime separately, in their own specific way - much like what using multiple ReaLearn instances gives us already, just easier to set up.
This is why we need another concept, I will call it "Section" for now.
New feature C: Sections
Sections are kind of "mini instances" within one ReaLearn instance. Each section has its own controller compartment, main compartment, controller preset, main preset etc.
Big picture
At the moment, ReaLearn has the following hierarchical structure:
With device pairs and sections added to the mix, the structure would look like this:
Variations
Variation A: Section contains device pair
A variation of this is to unite the "device pair" and "section" feature into one concept:
This would be less complex but have one disadvantage: It would be a awkward to implement feature B on this (sources that can refer to a specific device pair). The mapping source would refer to a section instead of a device pair ... which is weird, because the mapping source refer to another section just to borrow its device pair.
Variation B: Section contains potentially multiple device pairs
This would fix the issue of variation A: Make a "section" have potentially multiple device pairs:
This sounds good to me. And as a first step, it would be okay to allow only one device pair per section. This would solve our main issue right now (connecting multiple controllers to Playtime) and still leave an elegant way to implement feature B on top. I think this (one-to-many relationship between section and device pair) is better than the original structure (many-to-many relationship between section and device pair).
Alternative wording
Other terms instead of "Section":
The text was updated successfully, but these errors were encountered: