CLAP: Plugin's output Note Expressions in Bitwig have unwanted smoothing

[mccann]

Hi,

This is pretty much the same as https://github.com/free-audio/interop-tracker/issues/44, but for PRESSURE and BRIGHTNESS

I've made a github project with sources to reproduce here: https://github.com/mccann/CLAP-Expression-Tests

Simply put, Bitwig appears to provide parameter smoothing for pressure and brightness even when the initial expression value is set at the same time as the Note-ON.

For some context, I'm trying to provide interoperability with an Osmose E, which is very sensitive to these values, and can have initial values at NoteOn time that do not match Bitwig's default values of 0.0 and 0.5 for Pressure/Brightness.

[baconpaul]

ha yeah that looks like the exact same problem we had in surge land with tuning in bitwig indeed.

@abique easy to lift the change to the other expressions do you think?

also what an excellent report @mccann!

[mccann]

@baconpaul Thank you!

[abique]

Because this note expression is a discrete signal, it'll be smooth, but yeah the note on should allow a hard jump maybe.

[baconpaul]

Yeah I think just like tuning all the other expressions if at the same sample as a note on imply the starting value and we should avoid the smooth from default. One sample late and smooth it as you see fit but simultaneous is starting. We can add this to the doc too if you agree!

[abique]

Maybe only if the event has a (key and channel) or note id specified? My point is that this rule may not be applicable to global note expression events.

[baconpaul]

Oh sure I agree with that. An exact match at note on

wildcards get smoothed

[mccann]

Exact match makes sense to me.

It isn't at all clear from CLAP specs what the host does with 'note_id' that are generated by a plugin. I'd be happy to generate ids, for my use case if there's an expectation that host will read them.

That is to say, would be helpful to clarify what constitutes an exact match, given the vagueness of spec with respect to host interpretation's of note_id in output.

[baconpaul]

"exact match" to me meant "no wild carded slots in the PCKN tuple"

I agree we could continue to expand this doc!

[mccann]

Updated Note-Generator in the test project: https://github.com/mccann/CLAP-Expression-Tests to send exact match PCKN tuple.

[mccann]

I noticed a semi-relevant comment in the next branch regarding Note-On PCK tuples: https://github.com/free-audio/clap/commit/bcdc1efc31edc27a5d8aabbae986bec8c7d2239d

It clarifies, understandably, that Note-On events must not have wild-cards in the PCK fields. It makes sense to me that you want to give hosts that implement CLAP the flexibility to not support note_ids. Given the 'exact match' conversation above, it seems to me that it might be useful to have a way to query the HOST If it requires note_id. The voice-info extension is almost right, but it only allows host to query plugin, not plugin query the host.

This has me thinking that in general, when a plugin writes notes-out, the host/plugin roles are somewhat reversed. Whatever requirements there are for a host to know about a plugin's capabilities in determining what to place in the plugins event stream, so go for a plugin regarding the host, when writing to the plugin's output event stream.