Add new comment

In the end I think I have found the solution, at least for me. WARNED!!! I'm going to be long because I think it makes sense, no one is forced to read :).

There is no need to create any utilities for Qtractor to facilitate project sharing and backup.

It's much simpler. If a plugin format or plugin prevents or makes it difficult for me to create my own resources organization, my own workflow, that format or plugin is not suitable for me, and I will not use it.

A plugin is a resource of a musical project, such as audio files, midi, soundfont, etc. Therefore, it must meet the same requirements.

For me they are:

1 Be clearly and indisputably "libre".

2 Be independent: It must be self-defined and make sense on its own, without dependencies on external libraries, etc.

It should be able to be "played" by any compatible "player". In the case of plugins, the player is the host.

In any case, it is the host that may have dependencies (or not), but never the plugin. I insist, a plugin, even if it is technically software, is a resource ALWAYS linked to the projects, never to the programs or the operating system.

Therefore it should never be installed in the ROOT part of the operating system, but in the HOME, because the projects are the responsibility of the creator (user). Not from the administrator, nor from the operating system, nor from the distribution maintainers.

Conceiving it as an application and not as a resource is a misconception, and misconceptions always bring problems. Is a plugin an application? No, a plugin is a resource, with a dynamic property.

Just because it is developed as an application to comply with this dynamic property does not make it an application in terms of concept. It is an application only in "technical" terms, not in terms of use and functionality. And the proof is that I can exchange its use with a physical device, in an analog studio with physical tape recording, without changing the functionality.

Like a chair, it is a piece of furniture to sit on in concept, although in physical terms it can sometimes be a piece of wood, and other times a piece of metal.

3 Be portable, shareable, organizeable: If the design error indicated in point 2 arises, this will lead to portability failures.

4 Friendly interfaces.

5 Not be compiled, be human readable. Can be modified on the fly. I add this point as desirable, which unfortunately does not share almost any audio resource, except for a drawing of a waveform (which can be converted to audio), sheet music (which can be converted to midi) and SFZ libraries.

Today we only have 3 plugin formats that comply with point 1: LV2, CLAP and DSSI.

LV2 does not comply with 2, which makes it sometimes incompatible with 3. CLAP and DSSI comply with all except 5.

CONCLUSION:

At the moment, as an administrator, I am deleting all the VST and VST3 plugins from my "root", because they are not free (vst3 is not free with the GPL3 license either, although it takes a long time to explain). I am passing all the LV2, CLAP and DSSI to the home team to organize them as I see fit. Those LV2 that do not support the transplant will be eliminated.

What if I am left without some functionality? I will have to learn to modify the LV2 to make them portable or learn to create my own CLAPs. What if I don't get it? I will make music only with the tools available with my requirements, which are not few.

I'm not saying that anyone does what I do, nor that it is THE SOLUTION. I'm just saying it's my solution, and maybe others can find some use in these words.

For me, freedom above all.