Main menu
You are here
Utility: Plugins in Qtractor Session
If you want to share a session, you must inform the recipient which plugins are running on it. Many times, that recipient is your future self.
It is unpleasant to open a session and see that installed plugins are missing.
Collecting session plugins by hand is tedious.
If what you want to share is a template (.qtt), you must also specify those plugins that are disabled. However, in the case of projects, shutdowns can be ignored.
For this I have developed a small html5 application. I'm including it as an attachment in case you find it useful.
__Note 1
Unfortunately, the list does not include external sound sources such as .sf2, .sfz or .wavs that some plugins work with.
Qtractor compresses complex data from some plugins, making it unreadable.
__Note 2
Maybe it would be nice if Qtractor saved an "External Sources" information file.
Being able to share and create consistent backups is essential.
This text file would be saved in the root of the project. It would also be good if it could be consulted from Qtractor, opening a window equivalent to the message window.
I would include something like this:
Activated Plugins:
- Plugin name | Format | Operating system | Emulation manager (yadwidge, etc.)
- Presets: URL | Extension Preset Name
- External sources of the plugin: URL | Font name.extension (sfz, waw, etc.)
(For hosts, like Carla, include your own sources)
-Carla LV2 Linux
- Plugin name | Format | Operating system | Emulation manager (yadwidge, etc.)
- Presets: URL | Extension Preset Name
- External sources of the plugin: URL | Font name.extension (sfz, waw, etc.)
___
Disabled Plugins: (same as in "Activated Plugins"):
___
External Audio (sometimes we work with sound libraries not included in the project)
- URL/name.extension
___
External Midi (same as in "External Audio")
___
In fact, in the compressed .qtz session versions, all this material would be encapsulated.
In graphic arts, when a file is encapsulated, all its sources (fonts, images, etc.) are included. How else to ensure that the printing press can print it correctly? How to collaborate with other professionals as an artefinalist?
In the audio it is absurd that it is not the same.
I understand that in proprietary software, this is not done due to licensing problems with the plugins. But gentlemen, ladies, we work with free software.
Although the best thing while working is to share resources (libraries, etc.), once the project is completed it should be able to be encapsulated. It's common sense.
There are private and public spheres, and this is freedom. Entrusting everything to suppliers and dependencies is not freedom, but a dependent model. And dependency is the opposite of freedom.
| Attachment | Size |
|---|---|
 PlugInQtractorSession.1.html_.zip | 23.78 KB |
re. Utility: Plugins in Qtractor Session
just a note from this cat's mouth:
when saving to archive/zip (*.qtz) type format, only (some) LV2 plugins might do it into the bundle; all other plugin types are of no use in this regard; but still, on the LV2 realm, there's a hindrance that is blocking this aforementioned plan due to libLILV taking over the whole business for crying out loud!
I'll take your attention to the following, if you're still interested:
https://github.com/rncbc/qtractor/issues/427
https://gitlab.com/lv2/lilv/-/merge_requests/2
for the sake of it, please make an up-vote on the later ;)
cheers
re. Utility: Plugins in Qtractor Session
I voted :).
There are many things I don't understand about LV2, such as the concept of URIs.
My knowledge is very limited. I don't understand why there is an http:// there.
Does the plugin stop working if the computer is not connected to the internet?
Obviously not. so? what data does it send? And why does it send data?
Did someone ask me if I want to send data to a URI?
but is data really sent? And if not, why is there an http:// instead of a path to where my plugin is hosted?
Going back to what I said before, regarding the documentation suggestions for external files and encapsulation I think I need to make some corrections.
What I propose about providing information about plugins hosted on other host plugins is crazy. Let's imagine someone has put a Carla Host LV2 inside a Carla Host LV2 inside a Carla Host LV2 inside... how do you manage that to automate a backup?
Likewise the SFZ, because they in turn have many intricate dependencies (without entering into the weight of a library that can be tens of gigabytes).
So, I stick to:
_1
External resources must be automatically documented. Audio, Midi, plugins, and their direct dependencies (sfz, sf2, wav...) and maybe presets.
If the dependencies in turn have dependencies (wavs as in the case of an sfz), ensuring integrity is a matter of how the person organizes their libraries.
_2
Top-level plugins (not hosted ones) should be able to be encapsulated, but their external resources should not be.
This part must be done by the person making commitment decisions, and depends exclusively on the way they organize their libraries.
It is not as simple as in graphic arts, in music there are nested dependencies of several levels, sometimes indeterminate.
In graphic arts there are only one-level dependencies.
So I'm going to better study what I need the application to provide me to be able to share projects and make reliable backups.
When I have it I will share it.
---
LV2 is disappointing me as a free format. CLAP looks good.
I only know JSFX from learning about it, I have not used it. I think Carla supports it.
And there is a host on github that I haven't tried.
But I think it is the only format that really fits a free concept.
It is distributed uncompiled, anyone can read and modify it on the fly and learn in the process. It is text, it is easily hostable, copyable, modifiable and distributable.
It allows quick predefined interfaces (sliders, boxes...) and complex interfaces.
It is well documented.
It has an extensive community.
However...
With Reaper they indicate, there is a paid use copyright. (Although they do not make it clear what you are committing to and what they are committing to with the purchased license, they only specify that you have to buy it. They use a different pricing model depending on your earnings, which implicitly implies that they take rights over the exploitation of your own copyright and what you decide to do with it, which I consider one of the most unfair and least legal license models there is).
But with JSFX... they do not indicate the format license anywhere, or at least I have not found it.
And this doesn't look good.
To this day they have not opposed others creating hosts, they allow the format to be used without restriction...
But what about tomorrow?
I don't want to record a song, and in 10 years they demand that I have to pay for my pluging or my song, because they have changed their mind about their plugins formats.
In conclusion, I believe that the free plugin format of the future should have the properties of JSFX, but with a clearly free license.
re. Utility: Plugins in Qtractor Session
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.
100% agreed on all points!
100% agreed on all points!
re. Utility: Plugins in Qtractor Session
hi,
IDK whether this is some kinda rant or else, but, before it gets too late, I wish you the most and happy NYE!
cheers!
Happy happiness and
Happy happiness and prosperous prosperity for each and every day!!!
Best wishes for 2024
Best Rui & others over here,,
Wish you, the forum members and all our loved ones a healty and peaceful 2024 !!
Remember yesterday, dream of tomorow but live today....
It's interesting that this
It's interesting that this topic just came up. Yesterday, I was struggling with a similar issue because I opened up an old project and some plugins were missing. Rather than ask me where they could be (e.g., like Kdenlive asks for the location of missing assets), it silently ignored it. What makes it interesting is that this was Carla itself that was missing; while it is available elsewhere and opened up in other tracks, it was not available for one track in the location expected by the project or Qtractor. So, two of the same plugin in two locations - one missing and one not - that's probably why qtractor didnt say anything. Fortunately, I did a screen record for a video that showed each of the plugins and settings. Anyhow..., I better get to reviewing and voting on those two tickets!
Add new comment