How do I control the order in which the parameters show up?

[TheGuyWhoo]

If I wanted to arrange my parameters in a specific order, is there an argument I can pass or something? Or are they ordered in the order that the object is created?

[dromer]

Which order do you mean? is this with a specific generator?

[TheGuyWhoo]

Yes with dpf!

The order of sliders.

So say by default it's:

Pitch detune choas

and I want it to show up as

detune chaos pitch

in the daw.

[dromer]

Hmmm, so this is determined by the order in which the parameters are created, which we simply get from the list of receivers passed on to the generator.

Not sure what the easiest/simplest method would be to achieve such an order. We could add a new object to the meta.json that sets these and then enhance https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/generators/c2dpf/c2dpf.py#L32 to order the list.

Rather then having to add new creation flags to each receiver to define this, that would make things even more messy.

[GModal]

First, thank you for updating heavy to work with Python3!!

I've been playing with the source, and changed HeavyDPF.cpp from:

    case param{{v.display}}:
        parameter.name = "{{v.display.replace('_', ' ')}}";
        parameter.symbol = "{{v.display|lower}}";
        parameter.hints = kParameterIsAutomatable

To the following:

      case param{{v.display}}:
    parameter.name = "{{v.display.replace('__1', ':')}}";
        parameter.name = parameter.name.replace('_', ' ');
        parameter.symbol = "{{v.display.replace('__1', '_')}}";
        parameter.symbol = parameter.symbol.toLower();
        parameter.hints = kParameterIsAutomatable

A receive object in a Pd patch of r A__1_gain1 @hv_param 0 3 1

Converts to a LV2 parameter tag of A: gain1 , and a symbol of a__gain1, which doesn't seem to cause problems.

Parameters can be arranged in blocks (A:, B:, Sec1:, Sec_C, etc.). They are still alphabetized, however. This is definitely a hack, but it does work.

The code just replaces all instances of "1" with a colon (":") in the parameter name, then replaces that string with a single underscore for the lv2 symbol. Other characters that are not allowable in Pd symbols can be inserted in a like fashion ("2", "__3", etc.).

[dromer]

@GModal bit of a hack indeed. I don't really like creating in-line code that modifies the DPF parameters at runtime.

Maybe we can create a python function that can be injected into jinja2 instead and does all necessary replacements. Anyway "injecting" a : into the name when you don't have any such sections would look really ugly. If you simply want to force an order to your parameters without such a section every thing would get this prepended, which would look pretty weird.

Perhaps such a suggested function could take care of any such parsing as well, but now we really need to come up with some generalized convention of how to deal with this.

In principal I think doing something like prepending with __<int> to force an order could be useful. Although this likely won't work if you go to numbers above 9 .. so we need to come up with something better.

[GModal]

Yeah, it's definitely a hack :)... This is worse: https://github.com/GModal/ChaffVerb (in the hvcc_namefix dir) But the hacked version isn't the default Pd patch, it's just an option...

I'm aware this approach was never a viable solution:

- Only works while the DPF generator isn't updated
- Works ONLY on with the DPF generator (BIG fail)
- possibility of a parameter.symbol collision 
    - slight, and Pd itself wouldn't care about multiple identical receive objects
    - hvcc seems to anticipate symbol collisions, and generates it's own symbols in that case

Plus, as a transparent way to reorder the parameters (without a prefix), this won't work.

I'm not sure how a ":" would be injected unless the author added it. Reordering with just a prefixed letter (or word) doesn't require a separator (or any changes to the current code). The colon (or dash, etc.) is just for readability.

One idea: a substitution/ordering list in the .json file, something like:

{"receivers_subs": [ {"display" : "Gain_1" , "new" : "Gain, Preamp", "order" : 1}, {"display" : "Gain_2" , "new: : "Gain, Post", "order : 2} ] }

...where "Gain_1" and "Gain_2" are the receive obj arguments in the Pd patch.

Re: the inline codes, a 4 digit __<int> code shouldn't be too difficult (regex?), if that's seen as a viable way to reorder.

But there REALLY needs to be a way to use other characters in the display name. The alphanumerics that hvcc currently allows aren't sufficient. I wonder why hvcc won't even accept a dash in receive objs args, when Pure Data is OK with it.

Reordering would be great, but at least there are work-arounds, and alphabetical is better than random. Not wild about using object creation order in the Pd file, either. Pure Data is so arcane when it comes to object order. Yes, you can do it, but it's a lot of cutting an pasting. And no way to verify order without compiling the project. Some other explicit ordering schema would be preferable.

Thank you again for the work updating hvcc!!

[dromer]

Using the meta.json to enhance this for DPF was one of my suggestions as well. But this basically would mean even more custom implementation just for DPF. It would be great if this could be applied to other generators (say javascript or unity) as well.

I'm getting into the same bottle-neck now that I'm finally getting to making some plugins of my own. Of course you can edit the source files after things have been generated, but that's quite tedious. Being able to more easily group and order parameters would certainly make things better. Particularly since we don't have any way to create GUI code, generic host-UI without any kind of directed order is quite unusable especially if you have more than even half a dozen parameters.

Lets brainstorm more about how we can achieve this over the coming weeks. I'm also open to look at different prototypes if anyone cares to jump in on this.

[GModal]

Yes, I'm not too proficient in python, but I'd like to give the code a more in-depth look.

I know the (project).heavy.ir.json file includes the complete receivers list, in alphabetical order (with my hacked names, if I'm using them). No sure if it's written to multiple times during compiling.

Correction: the original names with the underscore codes are in the ir file.

[dromer]

So I noticed this bit of code today that is slightly related. It's about prioritizing execution order: https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/interpreters/pd2hv/PdReceiveObject.py#L51-L58

Which are subsequently sorted later: https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/core/hv2ir/HeavyGraph.py#L768-L769

As the first comment says we currently cannot use this priority for externed receivers (aka "parameters"), but maybe the syntax can be adjusted to allow for this.

For instance by appending @hv_param:<priority> and using that. Bit of a brain-fart, but I'll see if this can be used at all or if it would completely break things.

Potentially this would allow us to do general ordering of these externed receivers and this way use it for other parameters as well.

[dromer]

Ok nevermind. After a quick trial it seems this is not the path to take for sorting parameters.

Will have to re-think this once more ..