JACK/LV2 port metadata (for pretty names, CV ports, units)?

[mxmilkiib]

• https://jackaudio.org/metadata
• https://jackaudio.org/metadata/pretty-name
• https://jackaudio.org/metadata/signal-type
• https://github.com/jackaudio/jack2/blob/master/common/jack/metadata.h

The main purpose of signal-type is to hint/mark JACK ports as CV.

(N.b. there is also this request; https://bitbucket.org/agraef/faust-lv2/issues/22/support-for-lv2-cvport)

[mxmilkiib]

@sletz Might you have any comment?

[sletz]

What is the question ?

[mxmilkiib]

Feature request: it would be nice if, for JACK app* targets, the user could define information for setting JACK client metadata about the input/output port names and/or mark some as CV signal ports, might this be possible?

I guess LV2 targets could equally use this information for port names names and type (lv2:CVPort).

[sletz]

Feature request: for Faust application using JACK as audio backend? How do you see "the user could define information for setting JACK client metadata about the input/output port names" could be done?

[mxmilkiib]

For both JACK and LV2. I thought any LV2 effort works be done in the other project. Do any other plugin formats allow setting proper names for ports? Apologies, maybe pretty names and CV would be best approached as separate issues. In JACK, they are both just metadata properties, but maybe not just JACK is to be considered.

[sletz]

Be more concrete if possible: how to you suggest doing that?

[mxmilkiib]

I would guess maybe using declare in as Standard Metadata. I'm not confident on what the notation format would be best for such a mapping though.

[sletz]

Please suggest something ((-; What kind of string JACK meta-data system would be interested to get?

[mxmilkiib]

https://jackaudio.org/api/group__Metadata.html has the exact details for JACK. The metadata link above covers using jack_property to make metadata changes.

Edit: pretty-name, signal-type, port-group, and order

(For LV2 it would be setting the port name and type Turtle metadata.)

[sletz]

So in the Faust DSP code:

declare ?? declare ?? declare ??

[mxmilkiib]

Essentially.

Pd-fork Spaghettis uses messages.

Note: Carla, when hosting an LV2 bundle as a JACK client, goes further and presents that bundles port metadata as JACK port metadata, including the lv2:minimum and lv2:maximum, which is why Spaghettis mentions minimum and maximum.

(There is a the thought that, if CV signal is a normalised signal between -1 and 1, that the actual range it represents can be communicated out-of-band for some next level opportunities. There are no implementations/uses of this yet though, and also MOD devices CV plugins uses a CV range that goes beyond -1 to 1.)

[mxmilkiib]

Though that does kind of depend on ones definition of "essentially"; maybe there is a better way of notating such metadata?

Might it be possible to have this reopened?

[mxmilkiib]

Can I request again that this issue be reopened?

Currently faust2lv2 outputs plugins with ports like:

And faust2jack outputs apps with ports like:

But LV2 plugins can have ports like:

And JACK apps like:

Nice looking port names is probably more a priority for general users, but I've a big interest in modular synths and recently watched the MOOC videos by @orlarey and @rmichon so I would quite like to try making 'CV' plugins in FAUST if it might be possible going forward?

[cbix]

@SpotlightKid and me discussed this issue this week after his post on the mailing list. My idea was introducing 2 primitives that can be declared and annotated anywhere in the code (instead of being restricted to the process function) similar to the UI primitives. Quote:

I'd propose introducing two optional primitives, input("Name[key:val]") and output("Name[key:val]") that can be annotated with metadata just like the UI primitives and basically work the same way, but at sample rate. Example:

lin = input("[0]Left In[symbol:in_l]"); // S⁰ → S¹
rin = input("[1]Right In[symbol:in_r]");

declare lout group_channel "l";
lout = output("Left Out"); // S¹ → S⁰
declare rout group_channel "r";
rout = output("Right Out");

process = lin, rin : re.stereo_freeverb(0.1, 0.2, 0.2, input("Spread
cv[type:cv][unit:percent]")) : lout, rout;

For most build targets this metadata would probably only be relevant in the UI code (which can simply ignore it) while in DSP code it's equivalent to using _, _ for ports. I believe this would also make it easier to write sidechain inputs later in the processing chain, provided the input() function is S⁰→S¹ just like for example vslider().

One potential issue that needs fomalization would be the order and dimensionality of inputs and outputs and dimensionality of process, especially when combined with the traditional syntax.

If you think that this issue is purely JACK/LV2 targeted, introducing new primitives might be overkill tho. But considering possible other/future build targets like VCV Rack it might be appropriate to prevent fragmentation by different build targets.

[sletz]

Yes, this discussion about associating proper "semantic" to audio ins/outs is also quite important in the context of VCV Rack. We are indeed working on that, see: https://github.com/grame-cncm/faust/tree/vcvrack/architecture/vcvrack. And we'll have to think about what has to be added in the language or if an existing mechanism (like the declare key value) can be used for that.

[cbix]

Now with the vcvrack target released, the above questions seem mostly resolved and no changes to the language or existing practices are necessary:

[CV:N] can be used in input (typically sliders or nentry) or output (typically bargraph) controllers to connect them to CV instead of regular GUI parameters.

Now while with faust2vcvrack, input/output channels are automatically used as CV (there is no audio port type in Rack, just an Audio module interfacing with the outside world), this is not practical for JACK/LV2. The solution should only convert UI primitives tagged with [CV:n] to CV type ports and keep in/out channels as audio ports.

Ideally, any Faust code that compiles to vcvrack would then also compile to JACK and LV2, providing the same functionality.

[SpotlightKid]

@cbix: I'm not sure how your remarks relate to (general) metadata for input/output ports. Can you elaborate?

[cbix]

@SpotlightKid not related to general metadata. However one of the requests was to allow CV ports, which JACK supports by metadata and LV2 supports as a port type. Now that there is a solution for CV ports in another target (vcvrack), this could be used instead of generic port metadata to enable CV.

For all other use cases of generic channel metadata outside CV I'd still support other solutions.