Provide meta data for inputs and outputs

[SpotlightKid]

It would be nice if there was some way to provide meta data for input and output ports, e.g. "name" and "symbol" or other tags / flags.

I'm not sure whether FAUST has a "proper" way of attaching meta data to inputs / outputs, but I guess we could just use the global meta data via declare to store it, e.g.:

declare inputs__0__name "Audio In L";
declare inputs__0__symbol "in_l";
declare inputs__1__name "Audio In R";
declare inputs__1__symbol "in_r";
declare outputs__0__name "Audio Out L";
declare outputs__0__symbol "out_l";
// ... etc

NB: It seems that meta keys must be valid identifiers, i.e. only [a-zA-Z0-9_] but the manual isn't very clear about that. So unfortunately it seems we can't use chars like / as key/sub-key separators.

The architecture file could then provide the following methods:

const char port_label(bool input, unsigned index);
const char port_label(bool input, unsigned index);

similar to the existing parameter_label, parameter_symbol, etc. methods.

This would mean parsing the meta data keys into (in_out, index, key) triples. I'm not sure whether jinja2cpp already provides sufficient functionality for that?

[SpotlightKid]

Another possibility would be to store the port meta data as a JSON string in the value of a specific meta data key. But FAUST doesn't allow escaping double quotes or strings in single quotes, so we need to use single quotes in the JSON, which then would need to be replaced with double quotes again, before the JSON can be parsed. So overall not very elegant and harder to write too.

For example:

declare ports "{
    'inputs': [
        {
            'name': 'Audio In L',
            'symbol': 'in_l'
        },
        {
            'name': 'Audio In L',
            'symbol': 'in_l'
        }
    ],
    'outputs':
        {
            'name': 'Audio Out L',
            'symbol': 'out_l'
        },
        {
            'name': 'Audio Out L',
            'symbol': 'out_l'
        }
    ]
}";

There's a similar thing done in the FAUST examples: https://github.com/grame-cncm/faust/blob/master-dev/examples/smartKeyboard/dubDub.dsp#L37

[jpcima]

Hello,
I've desired a way to attach metadata to in/out ports as well, and to my knowledge this does not really exist.
I noticed you posted on Faudiostream-users, so let's wait to hear an answer from there.

I know you can attach metadata to particular functions, so perhaps this information is best there.
Perhaps then something like the following would be writable.
declare sallenKeyOnePole input.0.name "Frequency";

This information is best not defined as a global, because users might want distinct information depending on which -pn value is used.

[jpcima]

If adding this feature in short term, I think to go with a syntax similar to controls.
declare process input0 "Frequency [symbol=frequency] [unit=Hz]";

[SpotlightKid]

This will end up in the FAUST XML/JSON output with keys like "relative/path/to/foo.dsp/process:input0". If you think faustpp is able to find/extract the information like this regardless of from where faustpp was called, then I think this is a good solution.

[jpcima]

Regarding status of this issue

• The current -xml output has trouble with this metadata, because it strips the elements between brackets.
  Extraction from c++ does not have this issue. Another possibility is to extract from the output of -lang interp.
• The global variables inputs and outputs are already taken, it needs to use other names.

[SpotlightKid]

Can we revisit this feature now that we have a Python implementation?

It should be much easier to parse meta data and extract proper keys from it with Python.

[jpcima]

Perhaps this is a topic worth discussing with faust devs?
Some of these things may be interesting to get into the official specification. (like the symbol attribute)

[SpotlightKid]

We tried to bring up the topic on the faust user mailing list back then, but there was no reaction from the devs:

https://sourceforge.net/p/faudiostream/mailman/message/37087209/

We also brought the topic up in this related FAUST Github issue:

grame-cncm/faust#435 (comment)

But this also didn't go anywhere.