CLAP... thoughts?

[Funkybot's Evil Twin]

Yes. The way CLAP works is a plugin can query a host for extensions, and host can query a plugin for extensions. This handshake at startup lets you suss out the capabilities of your environment (if you are a plugin) and your target (if you are a host). In this case, with a draft extension, the most likely workflow is in some future CLAP 1.n version bitwig or one of the other hosts will take a shot at implementing it, we will have a comment period, and then at 1.m, m>n it will be promoted out of draft. Also, if a host doesn't provide the extension the plugin can code defensively to never offer up pages and what not.

If you have particular comments about features for this extension, your experience would be welcome in a GitHub discussion on the clap repo!

This might be complex, but it would be nice if the host could declare what kind of parameters were available in the controller and CLAP allowed for a "smart" mapping system that could be paired up with the available controls in the plugin.

For example:

1. Host says "this controller has 16 encoders" and plugin parameter pages are built around 16 encoders.

2. Host says, "this controller has 8 encoders and 8 faders" and plugin parameter pages are built around 16 params, same as above.

3. Host says, "this controller has 8 encoders, 8 faders, and 8 buttons" and the plugin first checks for any toggle-type parameters. Any 0.0 to 1.0 (on/off) type of parameters are automatically assigned to the buttons first, maybe even stepped params like three-way switches. 4-stepped params or fewer can map well to buttons. Then any continuous controls are mapped to the encoders and faders like in scenarios 1 and 2 above.

4. Host says, "this controller has 8 encoders, 8 buttons, and 8 displays with upper and lower display lines", now this scenario should work like scenario 3 but how to assign what shows up on the displays? Do we assume the 8 encoders match up to the 8 displays? Maybe ask the hosts to identify the linkage and report to CLAP and once established, use the upper display to show the FXParam Name and the lower display for the FXParam Value?

I use the CSI (Control Surface Integrator) extension in Reaper and have created hundreds of FX mappings for my various hardware so things like stepped params, encoders, displays, are all top of mind for me. A basic "Quick Controls" setup like in Cubase is better than nothing, but my dream integration would look a little more like the mappings I create manually for use in CSI.

Additionally, I think it would be helpful if plugin manufacturers could declare how important the parameter is and inform the host for mapping purposes. Sort of a plugin parameter mapping index. So a filter cutoff knob on a synth might be parameter 1, resonance 2, then maybe the ADSRs are next. But this may not be the same order that those parameters exist for automation, where they may be logically grouped. This would be just to tell the host, "when building plugin parameter pages for controllers, try to dynamically map these in this order".

Hope that all makes sense. Note: as an end-user I wouldn't feel qualified to jump into a CLAP extension discussion on this topic, hence why I'm posting here and not on Github. If any of this is of actual value, then feel free to steal.

[Tj Shredder]

It sounds like Midi 2.0...

[EvilDragon]

Yeah this definitely sounds more like MIDI 2.0 profiles. So why invent hot water, then? DAWs should start implementing MIDI 2.0 features instead.

[vurt]

. So why invent hot water, then?

to make coffee of course.
happy to help

[Funkybot's Evil Twin]

Yeah this definitely sounds more like MIDI 2.0 profiles. So why invent hot water, then? DAWs should start implementing MIDI 2.0 features instead.

A few reasons I can think of:

1. MIDI 2.0 won’t work for the millions of MIDI 1.0 devices and never will - what I’m proposing could work with any plugin/host that supports CLAP and MIDI 1.0 devices

2. MIDI 2.0 adoption has been far slower than CLAP adoption and CLAP is only a few weeks old - I have more faith that a well made extension would be widely supported

[audiojunkie]

The MIDI 2.0 Protocol uses the architecture of MIDI 1.0 Protocol to maintain backward compatibility and easy translation while offering expanded features. I don't think Midi 2.0 will prevent millions of MIDI 1.0 devices at all--Midi 1.0 is a subset of Midi 2.0 specifically for this purpose.

[Funkybot's Evil Twin]

The MIDI 2.0 Protocol uses the architecture of MIDI 1.0 Protocol to maintain backward compatibility and easy translation while offering expanded features. I don't think Midi 2.0 will prevent millions of MIDI 1.0 devices at all--Midi 1.0 is a subset of Midi 2.0 specifically for this purpose.

I’m not all that familiar with the finer technicalities of the MIDI 2.0 spec but isn’t the whole thing that the MIDI 2.0 hardware can interact with MIDI 2.0 hosts and plugins and declare the hardware parameters available for mapping, which MIDI 1.0 doesn’t do? If I’m thinking about it the right way, then since MIDI 1.0 devices don’t offer this feature, how could they take advantage of it? The host could perhaps act as a middle man I suppose after you MIDI Learn the 1.0 device. So maybe that’s doable but then why bother with a Quick Controls extension at all if MIDI 2.0 can do it all even with MIDI 1.0 devices? I’m not trying to be argumentative just thinking out loud about the feasibility of something like that.

[audiojunkie]

The MIDI 2.0 Protocol uses the architecture of MIDI 1.0 Protocol to maintain backward compatibility and easy translation while offering expanded features. I don't think Midi 2.0 will prevent millions of MIDI 1.0 devices at all--Midi 1.0 is a subset of Midi 2.0 specifically for this purpose.

I’m not all that familiar with the finer technicalities of the MIDI 2.0 spec but isn’t the whole thing that the MIDI 2.0 hardware can interact with MIDI 2.0 hosts and plugins and declare the hardware parameters available for mapping, which MIDI 1.0 doesn’t do? If I’m thinking about it the right way, then since MIDI 1.0 devices don’t offer this feature, how could they take advantage of it? The host could perhaps act as a middle man I suppose after you MIDI Learn the 1.0 device. So maybe that’s doable but then why bother with a Quick Controls extension at all if MIDI 2.0 can do it all even with MIDI 1.0 devices? I’m not trying to be argumentative just thinking out loud about the feasibility of something like that.

No worries! It's a learning journey for all of us.

Obviously, MIDI 1.0 devices will not be capable of making use Midi 2.0 functionality, but it won't stop users from being able to do what they've always have done with their MIDI 1.0. devices. As for the finer technicalities, I too don't claim to know or understand it all, but while it is certainly possible to some extent to have hosts compensate for some lost functionality between the MIDI 2.0 and MIDI 1.0 standards, I have to ask myself how realistic is it that hosts or CLAP would be even willing to take that aspect on, considering that MIDI 2.0 already exists--it would be reinventing the wheel for CLAP and windows hosts, at least as far as I can understand it.

Edit: Or maybe I'm misunderstanding what you are getting at--which wouldn't be the first time for me.

[EvilDragon]

I still don't think there should be double work done when MIDI 2.0 spec is there and CLAP also supports it, basically.

[baconpaul]

So first, for these reasons among others, the quick controls extension is still draft. I think that bears repeating!

My understanding of it was more prosaic though. Most daws have a 'quick control' where they highlight a set of params. Perhaps in a few pages. It would be nice if the plugin could let you know what those are. Sort of like smart controls in logic. So Surge could advertise, say, a macros page, a filter scene A page, a filter scene B page. Maybe?

The general problem of describing a physical device is, indeed, the role of MIDI 2 profiles or all the various json people author for each platform. I don't think CLAP would make that any cleaner, but CLAP with an appropriate extension could advertise parameters which were "preferred' or "quick" in some sense.

But, again, it's a draft extension and not in any danger of being promoted.

[Arashi]

I think it's a class case of Second System Effect. (https://en.wikipedia.org/wiki/Second-system_effect). VST1 organically grew in to VST2 based on need. Sue it had warts and was a bit ugly... but it was simple and useful. It could have continued growing.

Then all that was thrown out, because of pride and over confidence. And now it's too embarrassing to admit it's a failure, so we are stuck with it.

That explanation fits like a glove. VST3 has been a spectacular failure.

[Arashi]

On Maschine you have direct page jump mode, on keyboards it's sequential. At any rate, NKS is absolutely great for blind users and they're thankful it exists.

I never noticed the ability to jump to specific pages of controls. It's a bit awkward, but handy anyway. Would be nice if it was actually usable when pinned in page nav mode, so you don't have to hold Shift + Navigate every time, but you can't see the parameter names or values in that mode, so it's better to use it as a temporary mode (without pinning), otherwise it has to be invoked twice every time you want to switch pages.

If they ever make Maschine mk4 and Komplete Kontrol mk3 (it's hard to tell if NI still has any interest in making hardware), I hope they'll add a second row of buttons below the display (like Ableton Push 2), as it makes it possible to dedicate one set of buttons to navigation. Not all Ableton Live devices support it, but the ones that do are really nice to work with on the controller.

[SebAV]

I don’t know if CLAP is concerned about improving remote control of plugins. But if we take the great Push 2 : Ableton knows it’s own devices, itself and the controller. With VSTs it’s not so great, pretty basic in fact. The « apparent » sole difference is VST vs native device. If à VST could be known by Live as deeper as a native device, perhaps the remote features would be the same ? Perhaps CLAP could make this knowledge accessed by the host ?
If it’s Midi 2.0, we’ll see it in 10 years, me think.

[SiliconDeath]

It says on U-he page that some beta version of Bitwig already has CLAP support? So my question is, has anyone tested it or done benchmarks yet?

[ThomasHelzle]

viewtopic.php?t=582950