Metadata info opcodes

[AlexMitchellMus]

Currently library creators enter info about SFZ files as comment blocks.

For this data to be useful, for database, or display, a group of opcodes would be needed. Such as:

info_author_label=
info_company_label=
info_date_label=
info_version_label=
info_email_label=
info_license_label=
info_genre_label=
info_instrument_class_label=
info_instrument_type_label=

[kinwie]

I think since it already had "info" prefix, we can take out the "label"

info_author=
info_company=
info_date=
info_version=
info_email=
info_license=
info_genre=
info_instrument_class=
info_instrument_type=

?

[sagamusix]

It could also end up in its own <info> section which would make the info_ prefix redundant as well.

Practical considerations: It is quite likely that some of these values may contain spaces. Let's not repeat the messy backtracking required for parsing sample filenames here. I can imagine several solutions:

• Require the value to be put in double-quotes, e.g. author="Author Name". This is already used in some places (e.g. #include) so most SFZ parsers already have code to handle quoted strings.
• Enforce one opcode per line, so it doesn't matter if the value contains spaces or = characters. In this scenario, author=Test 1=2 would be valid and the effective value of the author field would be Test 1=2.
• Keep the data in comment blocks, but establish a standard for parsing those comments. E.g. standardize that // author=Author Name would specify the author. This solution is the most backwards-compatible one, because old parsers don't have to deal with any new concepts.

[redtide]

for this specific case I would vote the comment block option, something like Doxygen comments (using c or c++ styles)
E.g.:

/**
    @author       Joe Smith
    @organization ACME Inc.
    @date         2012/12/21
    ...
*/

[AlexMitchellMus]

Doxygen style could work. However I think strings in SFZ need to be revisited regardless, and @sagamusix has some good points.

Also, using doxygen for data that will be presented to the end user (Player Plugin, in info tab) feels wrong.

[redtide]

It may seem odd yes, but I think for this context could be the a good solution also to avoid to add compatibility issues as sagamusix said. OTOH Doxygen was made to be parsed just for extracting data, so I don't think will be particular issues for that purpose, otherwise this solution would be pointless other than looking strange.

[jpcima]

Not doc comments preferably, SFZ parsing is already very vaguely specified, and doc comments are not helping.
This is better expressed within the syntax of SFZ,and we should work towards a parsing specification which is rigorously defined.

[redtide]

I'm one against ui in sfz, and at some extent also ui related labels (and so the image opcode in sfizz);
I think the <control> header should remain audio only context.

Recently output_labelN has been implemented in Calfbox, which also goes under <control> like other extensions.

Note that UI unrelated opcodes comes from extensions only:

• label_ccN ARIA
• label_keyN sfizz
• output_labelN Calfbox

plus image (sfz v2) which I'm not sure at this point if at that time was meant to go under <control> like it has been implemented in sfizz (a work made by jpcima and me).

As side note it's not clear what to do with #define, which seems to be used outside headers (like it should being something coming from C language) but this is how was meant in sfz2.

So I think all of these should not go in sfz 3 under the control header but using a new one, which would be something like <metadata>. Samplers could make it work on both for compatibility.

So the above should follow the same logic and naming convention, e.g.: label_author, label_product etc.