Mod-UI - no ability to map parameter to controller

Developers
#1

Hi Guys,

If I have a parameter defined like this:

plug:feedback
	a lv2:Parameter ;
	rdfs:label "Feedback" ;
	rdfs:range atom:Float ;
	lv2:default 0.5 ;
	lv2:minimum 0 ;
	lv2:maximum 1 .

Then in Mod-UI I can see the knobs for the parameters but the little box to click on to bring up the controller mapping is not there so I cannot say map them to a midi controller.

I’m obviously missing something simple can anyone help me?

Cheers

Andy

1 Like
#2

Shouldn’t it instead be this?

a lv2:InputPort , lv2:ControlPort ;

I’ve never seen/used rdfs:label or rdfs:range either.
Instead of label it’s usually lv2:name

2 Likes
#3

Thanks for the info @dreamer.

This is ttl generated by Juce 7, which I’m beginning to think may not be the best way forward!

It’s little strange that the parameters work and are displayed in the webpage but the mapping button is missing, I’m wondering if it is because it needs an index.

1 Like
#4

Ok, with these lv2:Parameters they seem to be handled totally different using patch_set rather than param_set:

DEBUG:root:[host] popped from queue3: patch_set 0 https://www.yourcompany.com/plugins/SimpleDelay:feedback "0.5424107142857142"

I would say this is not going to fly!

1 Like
#5

LV2 has 2 types of controls

  • the old control ports which take a float pointer and plugins need to read from it every run (including to see if it changed compared to previous runs)
  • the new patch/parameter style of controls, which are changed via patch:Set messages on the plugin atom port. they take a bit longer to setup, but provide sample-accurate parameter changes and event notifications (you no longer need to check every run if params changed or not, you simply get an event when they do)

because there were 0 plugins making use of patch parameters when we did the v1.10 update (that introduced support for them), we did not bother with the mapping implementation as it was kinda pointless (and hard to test anyhow)

of all plugins that got published into the (stable) store previously, only the “notes” one made use of patch parameters. and well… it is still not that useful to map “notes” font size to a hw control

so parameter mapping was simply not implemented, in a kinda chicken-egg problem where we first needed a couple of plugins to justify the time spent working on the feature.

4 Likes
#6

Ah, thanks for the info.

I might have a look to see if I can shoehorn it in, is it only Mod-Ui that needs updating, so it can use the existing mod-host mapping functionality? Or is it more complex than this?

1 Like
#7

it is a bit more complex.
although there are some entry points that can be reused for changing value from HMI / mod-ui side, things are a bit more complex because mod-host also allows value changes from control chain and MIDI mappings.
doing it for HMI side is easy, but the other 2 not so much (MIDI events in particular happen during audio thread, so no allocations there). we need to take special care in regards to thread-safety and race conditions when parameters can be changed from different sources.

also we need to be aware of the file format used to save these mappings.
changes need to be made such that it is both forward and backwards compatible. That is, any new data written on newly saved PBs does not break existing v1.10/11/12 users, and old pedalboards being resaved keep working without losing data.

5 Likes