Expose XY-pad/mixer as parameters about bangr

[falkTX]

By that I mean adding lv2:minimum and lv2:maximum to the parameter definition on the ttl side.

[sjaehn]

Sorry, my fault. There is communication via atoms only if UI on. This made sense before, but not anymore. I'll remove this part.

[falkTX]

There is custom message passing for those in https://github.com/sjaehn/BAngr/blob/master/src/BAngrGUI.cpp#L186

But nothing that I see prevents those from being lv2:Parameter types, which are well defined in the spec.
(host support is hit or miss, Carla and mod-host should be okay at least)

eg-sampler is something you can look for lv2 parameter usage.

[sjaehn]

Hmmm, indeed. The x,y position is calculated withing the DSP on the base of the values of the ports 8 to 15 (speed, speed_range, speed_flexibility_type, speed_flexibility_amount, spin, spin_range, spin_flexibility_type, and spin_flexibility_type). The calculated x,y position is sent to the GUI via a bangr_cursorEvent atom object as defined in https://github.com/sjaehn/BAngr/blob/master/src/Urids.hpp#L39. And sent back to the DSP in the reverse way if the user dragged the dot in the GUI. I can't use ports for this as this is a two ways communication that needs read and write access.

It would be nice to see it working with MOD. But I've to admit that I didn't go into details about MOD, yet. What I heard is that MOD uses ports but doesn't like atoms. But I'd be glad if you can show me a way that works with MOD.

[falkTX]

If you use lv2 Parameter (not control ports) you can have the DSP change its own values.
Already supported in MOD since v1.10

[sjaehn]

Using the lv2:Patch extension?

[falkTX]

Yes. send patch:Set from the GUI to set parameters, and implement patch:Set and patch:Get on DSP side so host can also know and change these values (important for saving and loading state correctly)

https://github.com/lv2/lv2/tree/master/plugins/eg-sampler.lv2 has example code. lots of stuff you dont need, just focus on the gain parameter.

[sjaehn]

I am / was still a bit skeptic about the support of lv2:Patch by hosts. I know that there was only a very poor support just a few years ago. Is it much better now? Then I would generally go this way.

[falkTX]

Yes, both Ardour and Qtractor got a little attention on this.
Last I checked, Qtractor didnt allow to automate such parameters (but not possible to do that now with current plugin anyway)

I will fix anything that you find in carla that misbehaves.

To be clear: I am not advocating to make the entire plugin use patch/parameter, only the XY stuff.
Rui's v1 synths have gone in this path, where most things are still control ports, but a few are patch/parameters.

[dromer]

It would be nice to see it working with MOD.

Already have the DSP working (some patch on the Airwindows code replacing doubles with floats to allow for compiler optimizations). Sounds pretty cool!
But control over the XY-mix would certainly make this much more useful ;)

[sjaehn]

Already have the DSP working (some patch on the Airwindows code replacing doubles with floats to allow for compiler optimizations).

Especially the long double variables.

[dromer]

All of them, actually :D
https://github.com/moddevices/mod-plugin-builder/compare/juce-tests...Wasted-Audio:plugin/BAngr?expand=1

[sjaehn]

Support of lv2:Parameters and lv2:Patch is now drafted in 7d2ad4f . Still TODO the getter (needed?) and some cleanup. Additional support of lv2:State now would make sense. What do you think?

[dromer]

DId a quick build both for desktop and MOD. In Carla I see the new X/Y-Coord parameters, however they only start 'moving' once I open the GUI.
In MOD these parameters are not visible yet. Supposedly you need to set min/max values for them (which atm are not there).

[falkTX]

MOD will only accept boolean parameters without range (it assumes it is 0 min, 1 max).
Integer, Long, Float and Double need to set their range.

parser code in question: https://github.com/moddevices/mod-ui/blob/master/utils/utils_lilv.cpp#L801

[dromer]

I tried with:

diff --git a/BAngr.ttl b/BAngr.ttl
index 7bb1274..3e9d81c 100644
--- a/BAngr.ttl
+++ b/BAngr.ttl
@@ -33,12 +33,16 @@
 <https://www.jahnichen.de/plugins/lv2/BAngr#xcursor>
    a lv2:Parameter ;
    rdfs:label "X-Cursor" ;
-   rdfs:range atom:Float .
+   rdfs:range atom:Float ;
+    lv2:minimum 0.0 ;
+    lv2:maximum 1.0 .

 <https://www.jahnichen.de/plugins/lv2/BAngr#ycursor>
    a lv2:Parameter ;
    rdfs:label "Y-Cursor" ;
-   rdfs:range atom:Float .
+   rdfs:range atom:Float ;
+    lv2:minimum 0.0 ;
+    lv2:maximum 1.0 .

 <https://www.jahnichen.de/plugins/lv2/BAngr>
         a lv2:Plugin, lv2:DistortionPlugin, doap:Project ;

And the parameters now do show up in MOD, however they are not synced to the DSP at all and have no influence over the mix.

[falkTX]

Might be the plugin expecting some kind of very specific message.
Worth checking if the XY stuff works in Carla without the GUI open.

[dromer]

Yeah exactly, in carla the parameters don't do anything until I open the GUI. When I close the GUI (not just hide, but really close the window) then the parameters stop syncing again.
So seems similar.

[sjaehn]

Just fixed this in d706fb5 (I like it if bug fixes lead to a reduced size of source code :) ).

[dromer]

Ok, they do update now however in MOD I'm not able to override the position of these parameters: they immediately jump back to where they were.

[falkTX]

MOD will listen to changes sent by the plugin. so the plugin might be acting in a feedback loop

[sjaehn]

Hmmm, the present version is still (too much) optimized for the use of the GUI.

The white cursor position is permanently calculated for each sample on the base of the last cursor position. Unless the cursor is dragged in the GUI: The GUI sends a bangr_cursorOn atom to the DSP if the mouse button is pressed over the cursor. And the GUI sends a bangr_cursorOff atom to the DSP if the mouse button is released. The GUI only sends position data (xcursor and ycursor) if the cursor is dragged. If the DSP receives bangr_cursorOn, bool listen is set true (and the opposite for bangr_cursorOff). And if listen is true, automated position recalculation from speed and spin parameters is paused. This prevents the feedback loop. For the native GUI.

I suspect there is something with the bangr_cursorOn and bangr_cursorOff atoms (not defined as params). And I don't know how MOD handles these events. I think I've to take a deeper look into MOD.

[sjaehn]

Already have the DSP working (some patch on the Airwindows code replacing doubles with floats to allow for compiler optimizations).

Yes the brutal conversion to float works. I was a bit more careful in the first step and firstly converted only the long doubles to doubles. But the next conversion to float is still fine. And faster. Thanks!

[dromer]

Nice, just tried the latest master and this certainly improves things even more!

Now we just need those controls on the X/Y-Coords (and a modgui ;) )

[sjaehn]

... however in MOD I'm not able to override the position of these parameters: they immediately jump back to where they were.

As I mentioned above, this could be the result of the permanently recalculated cursor position by the DSP. This makes it hard to manually change the continuously moving cursor position. Especially if there is some latency between the host (MOD) interface and the plugin. Therefore I defined a short (200 ms - can be extended if needed) resting time (= no automatized recalculation) for the cursor if the cursor is changed via patch_Set: eaa17f0 . I hope this makes it a bit easier. I'm not sure if it also fixes the MOD problem, but I hope.

[dromer]

Just to confirm: in Carla this always worked (initially only with GUI open)

In MOD moving around the parameters simply doesn't change anything.
MOD also certainly registers these as a different parameter, I'm not able to map these to any controls either (ie. MIDI, Device or CV. See missing config-button in screenshot).
https://i.imgur.com/S59by0t.png

I think @falkTX can probably best comment on what could be missing here.

[falkTX]

You cannot address these parameters. It is normal.
See notes.lv2 which behaves the same way.

[dromer]

hmm, that's somewhat unfortunate. So it would not be possible to adjust the mix using any physical controls.
Then how come Carla is able to midi-learn to these parameters and adjust the values subsequently?

[falkTX]

It is just a limitation on the MOD side due to lack of time.
It can be done, but was not justifiable since zero plugins used this parameter style at the time the feature was being developed.

[dromer]

Aaaah check. Ok MOD 2.0 then ("future stuff").
For now I can live with this "alive" behaviour I guess. Although being able to "set" the mix would still be nice.

Would the parameter values still be saved in a preset? Then the alternative for "setting" the values would be to wait until they are what you want, then turn the "speed" parameter to 0 and they stop moving. [edit: nope]

@sjaehn setting this 200ms delay is then not necessary, maybe undo that commit?

[falkTX]

Would the parameter values still be saved in a preset?

Yes, if @sjaehn implements state support for that. eg-sampler also has example code on how to do this.
So on MOD side you can create presets or pedalboard snapshots, which will save and load this parameter state.

[sjaehn]

Save & restore state is easy. This time I don't need to do unconventional stuff as I did in my sequencer pattern plugins ;-).

[sjaehn]

lv2:State save and restore is now supported. I would usually also set state_StateChanged but then you would never get unsaved states (unless speed == 0).

[dromer]

Have been having some weird performance issues on the MOD DuoX with this plugin the past days (tried several recent commits, somehow the whole ui and my browsers freeze up when this plugin is loaded).

Will investigate more and open a new ticket if I know more of what's going on ..