investigate portable plugin graph

[atsushieno]

(copied from https://github.com/atsushieno/augene/issues/1)

Right now, when we use this tool to define audio plugin graphs for each track, those plugins are recorded as bare filtergraph generated by AudioPluginHost. When we switch environment across platforms, those plugins become different (they would be AU on Mac, and they would be VST3 on Windows and/or Linux, or LV2 on Linux). Since my secondary purpose of this project is to support AAP, it has to be also portable to Android too.

Since they don't share the same set of plugins, it is song author's responsibility to use the set of common audio plugins. But even if they use only such plugins, those filtergraph files from AudioPluginHost is platform dependent.

Maybe there should be some kind of mapping aliases, or at least per-platform filtergraphs. But the fundamental problem lying around here is, what is an "identical" plugin? Some possible usage scenarios:

• I use Collective on Linux, Mac, and Windows. They are all VST2, and portable across those desktop. Are they "identical" ? They should be.
• I use different versions of Collective on those platforms. Are they identical? They probably still should be.
• I use ADLplug AU on Mac, and ADLplug LV2 on Linux. Are they identical? Argurable.
  • Their behavior would be almost identical. But they have different unique IDs.
  • Also, they wouldn't share the same "state" binary blob.
  • Furthermore, there is no assurance on whether they share the same parameter set or not. At least JUCE on VST3 often generates extraneous parameter set for MIDI CC dispatching (like 2050+ extra).
• What if I use ADLplug on Linux as LV2 somewhere, and ADLplug via lv2vst i.e. as VST2 elsewhere?

Can we cover some or all of them?

---

Some relevant web resources (will be updated):

• https://www.kvraudio.com/forum/viewtopic.php?t=285627
• https://www.kvraudio.com/forum/viewtopic.php?t=397199

---

On plugin state portability:

For LV2 plugins, there is LV2_State_Map_Path feature that should be provided by the host of which a plugin can make use to convert absolute and abstract file paths. https://lv2plug.in/doc/html/group__state.html#structLV2__State__Map__Path

It is used by sfizz for example, so that SFZ files are stored in abstract form, not immediate path.

[atsushieno]

From the latest README:

Then you can #include this macro, and write your track MML like:

// not quite sure if this 127 works just as 127, you might need some multiplication
1 INSTRUMENTNAME "opn" CH0 @1 OPNPLUG OPNPLUG_PART\1_OPERATOR\1_LEVEL 127

Wherever you have the same set of audio plugins installed on your system, you can generate the same set of macro definitions and therefore the MML should be compatible across environment, whereas the plugin unique IDs might be different.

This resolves environment dependency in audio plugins via automation tracks and environment-independent automation support MML files.

Not relevant to the rest of the problems though (such as, plugin format difference, uid differences per environment, etc.).