Add support for multiple device pairs and sections per instance

[helgoboss]

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:

• Device pair 1 (default)
• Device pair 2
• Device pair 3
• ...
• Device pair n

Each device pair has 2 properties:

• Input device
• Output device

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:

• Backbone (one)
  • Instance (many)
    • Input device (one)
    • Output device (one)
    • Controller compartment (one)
      • Mapping (many)
    • Main compartment (one)
      • Mapping (many)
    • Clip Engine (one)
    • Pot Browser (one)

With device pairs and sections added to the mix, the structure would look like this:

• Backbone (one)
  • Instance (many)
    • Device pair (many)
      • Input device (one)
      • Output device (one)
    • Section (many)
      • Controller compartment (one)
        • Mapping (many)
      • Main compartment (one)
        • Mapping (many)
    • Clip Engine (one)
    • Pot Browser (one)

Variations

Variation A: Section contains device pair

A variation of this is to unite the "device pair" and "section" feature into one concept:

• Backbone (one)
  • Instance (many)
    • Section (many)
      • Input device (one)
      • Output device (one)
      • Controller compartment (one)
        • Mapping (many)
      • Main compartment (one)
        • Mapping (many)
    • Clip Engine (one)
    • Pot Browser (one)

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:

• Backbone (one)
  • Instance (many)
    • Section (many)
      • Device pair (many)
        • Input device (one)
        • Output device (one)
      • Controller compartment (one)
        • Mapping (many)
      • Main compartment (one)
        • Mapping (many)
    • Clip Engine (one)
    • Pot Browser (one)

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":

• Unit
• Configuration

[vonglan]

Each device pair has 2 properties:

Input device
Output device

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

• One ReaLearn Instance with controller mapping OB6 to SY (virtual mapping set)
• Another one with controller mapping X-Touch Mini to SY
• Both have Main Mapping from SY to e.g. Diva
• Diva

[helgoboss]

New feature "C" (multiple units per ReaLearn FX instance) is implemented and will show up in upcoming ReaLearn 2.16.0-pre.8.