custom information for all file types

[RustoMCSpit]

.nam is the neural amp modeler model file type

open audio should have a database of file types containing mininal info about them for #86

(the below is a studiorack issue)
ir should then be able to list all plugins capable of using that file type like the below does for plugins found within projects
studiorack/studiorack-site#44

[RustoMCSpit]

this database may also be necessary for the sake of how metadata should be listed.

https://tonehunt.org shows what .nam files need to be presented for example (e.g light, feather or nano)

when tonehunt was FOSS they had a bunch of open tickets you might like, also it's all in typescript and has plenty of ui assets https://github.com/tonehunt-org/tonehunt/issues

a plugin dev should honestly PR any metadata structures they need for their stuff into openaudio, most plugins just use presets which are general enough to use our generic preset metadata but some, like NAM, are not 'presets' but rather extra files the plugin uses to work. another example of something like that would be if this were implemented in terrain aaronaanderson/Terrain#5

some plugins essentially use 'presets' that are not contained within the plugin but link to other files.

ive tried to imagine how this would work with tagging, metadata, and downloading through out these issues

[RustoMCSpit]

another example, theoretically in the future, would be rvc files for plugins that use voice conversion tech

or .sfz files you already know about for sfizz or some other sampler

[kmturley]

I am adding details for every file format Open Audio Stack references in code:

• https://github.com/open-audio-stack/open-audio-stack-core/blob/main/src/types/FileFormat.ts
• https://github.com/open-audio-stack/open-audio-stack-core/blob/main/src/types/PluginFormat.ts
• https://github.com/open-audio-stack/open-audio-stack-core/blob/main/src/types/PresetFormat.ts
• https://github.com/open-audio-stack/open-audio-stack-core/blob/main/src/types/ProjectFormat.ts

They are then added to the config:
https://github.com/open-audio-stack/open-audio-stack-core/blob/main/src/Config.ts#L37

And generated in the Registry static files e.g.

• https://open-audio-stack.github.io/open-audio-stack-registry/config/file-formats/
• https://open-audio-stack.github.io/open-audio-stack-registry/config/plugin-formats/
• https://open-audio-stack.github.io/open-audio-stack-registry/config/preset-formats/
• https://open-audio-stack.github.io/open-audio-stack-registry/config/project-formats/

So I consider this feature already built, and it will be extended over time.

[RustoMCSpit]

So I consider this feature already built, and it will be extended over time.

then add to the readme how to upload a new file format. youve added to the readme how to add plugins, projects, and presets so just add that too

[RustoMCSpit]

description	"macOS and iOS software package installer."
value	"pkg"
name	"Apple package"

.nam files need to be presented for example (e.g light, feather or nano)

the ability to add more metadata points is crucial

also, im not sure i like the name "file formats". these should be labelled as storage formats and things like .sfz, .nam, .rvc, etc. should be "file formats". anything which falls into the description of a 'preset' that is used by a plugin but not contained within the plugin but use other files. i guess you could argue most plugins' presets fall into that description but im thinking more in the lines of plugin agnostic files. for example, an impulse response can be used by any plugin that supports it. it isnt designed for a specific plugin.

is this making sense? theyre like presets but plugin agnostic and classifying them as presets isnt correct at all, theyre "file formats" that are standardised across plugins and they each require their own metadata points

[kmturley]

So I consider this feature already built, and it will be extended over time.

then add to the readme how to upload a new file format. youve added to the readme how to add plugins, projects, and presets so just add that too

Only file formats used in the specification will be supported for now.

[kmturley]

description	"macOS and iOS software package installer."
value	"pkg"
name	"Apple package"

.nam files need to be presented for example (e.g light, feather or nano)

the ability to add more metadata points is crucial

also, im not sure i like the name "file formats". these should be labelled as storage formats and things like .sfz, .nam, .rvc, etc. should be "file formats". anything which falls into the description of a 'preset' that is used by a plugin but not contained within the plugin but use other files. i guess you could argue most plugins' presets fall into that description but im thinking more in the lines of plugin agnostic files. for example, an impulse response can be used by any plugin that supports it. it isnt designed for a specific plugin.

is this making sense? theyre like presets but plugin agnostic and classifying them as presets isnt correct at all, theyre "file formats" that are standardised across plugins and they each require their own metadata points

FileFormats are the formats supported in the Registry package files specification.
They are archive and installer formats which are used to bundle and distribute other files.

I don't want individual files to be supported in package files, otherwise every Package Manager will have to handle every file format. That's usually not how package managers work. They require packages to be distributed using a fixed list of archive/installer formats.

[RustoMCSpit]

let me rephrase, i know youre storing all the files within 'file formats' but when youre uploading the files within those file formats to the registry, they need custom metadata around them

nam files need to be presented for example (e.g light, feather or nano)

[kmturley]

According to the docs:
https://neural-amp-modeler.readthedocs.io/en/stable/model-file.html

.nam are not presets but trained neural network model files. At the moment I don't plan to support plugin-specific file formats.

[RustoMCSpit]

At the moment I don't plan to support plugin-specific file formats.

okay but the problem is plugins need them to function. maybe re-open and make this a long term low priority issue

[kmturley]

When a manager installs a plugin, it can copy all files to the default plugin directory:

Platform	Path
Linux platform	$HOME/usr/local/lib/$format
Mac platform	$HOME/Library/Audio/Plug-ins/$format
Windows platform	C:\Program Files\Common Files$formatC:\Program Files (x86)\Common Files$format

When the manager installs a preset, it can copy all files to the default preset directory:

Platform	Path
Linux platform	$HOME/.vst3/presets
Mac platform	$HOME/Library/Audio/Presets
Windows platform	$HOME/Documents/VST3 Presets

If there needs to be custom installation paths, either the plugin can distributor an installer executable file containing the logic. OR we can support some mapping from file extensions to paths which is covered in another ticket.

[RustoMCSpit]

okay but if youre downloading a project and open audio cant recognise what file has been used in a plugin and it has no metadata or info to link in back to in our registry, that would be a disaster.

also these arent "presets", theyre not really "plugin-specific file formats" either, though some are. some are howeve plugin agnostic and classifying them as presets isnt correct at all, theyre "file types" that are standardised across plugins and they each require their own metadata points. .nam, my example, is used in so many plugins (mod desktop, neural amp modeler, ratatouille, aida-x, etc.). you wouldnt say that impulse responses are presets would you #40

i think that down the line, plugin devs should be able to upload metadata scheme for plugin types and open audio can decide if it's worth it, which is honestly a documentation concern almost