I’m attempting to use the CALF-plugin set on Ubuntu14.04. Everything was going well until I closed ARDOUR. Upon restarting the program I get this error whenever I try to load the project file and the CALF library is completely missing in Ardour’s plug in list: "[ERROR]: Found a reference to a plugin (“http://calf.sourceforge.net/plugins/Equalizer12Band”) that is unknown.
Perhaps it was removed or moved since it was last used.’
However, if I load a different project, the CALF plugins are all available and work correctly.
I literally saved the project after working with the plugins, closed ardour, rebooted my machine, and opened Ardour again… and the plugins are missing. Also, I can only get Ardour to open from a terminal, if I try to open it using Unity it crashes at the splash screen for this project (and works fine for every other project).
I just tried with 4.0rc1 and it is fixed. Since I’m not a subscriber (I just did a one time donation), I can’t recover my plug-in settings, right? I had already done a few hours of EQing and am just wondering if I can find that data somewhere.
Right, I get that. I was just wondering if there is a way to recover the data since it was saved in my copy of 3.5.403 (which wasn’t the free version).
There is now a warning given in the free version about this issue. It notifies the user that they will lose plugin settings by using the free version (if there are any).
The way I’m reading this, it implies that if you create and save a project in the paid version, your plug-in settings will be saved as expected, but, if you then open that same project in a free version (or perhaps a nightly build) and then edit / resave it, the plugin settings will actually be removed / corrupted in the project? I really hope that’s not what happens? (and if it is, just putting a warning in is not really the appropriate solution… )
That’s correct. The free version has NO capability to LOAD or SAVE plugin settings. If auto-save is enabled, the first auto-save (or the first manual save) will overwrite the session file, without the plugin settings. The decision on whether or not to load/save is done at build time, not run time; there is no code in the free version that can load or save. We could potentially activate the read-only flag for such sessions, which might be a better solution (this flag is normally only set if the session folder is not writable).
That's correct. The free version has NO capability to LOAD or SAVE plugin settings. If auto-save is enabled, the first auto-save (or the first manual save) will overwrite the session file, without the plugin settings...
!!!
We could potentially activate the read-only flag for such sessions, which might be a better solution...
Hmm.. What you need to do is make sure that users (myself included) can't take a session, load it into ardour, and then effectively have ardour corrupt the session on (auto!!) save. That includes, the free version (and possibly the nightly versions?) breaking sessions saved in a paid version. Perhaps if the free version just didn't restore the plugin settings, then there would still be a limitation, but, with the added benefit that on getting a paid version, you can unlock "free" sessions, and paid sessions wouldn't be corrupted.
Maybe you could still do this at build time, although, I don't quite see the logic of requiring that, in preference to a runtime option - if the intention is to stop users enabling the option, then that's kind of irrelevant, because even with the code in there, it would still be more hassle to hack it than to download and build from source - which has everything enabled anyway. Surely the whole point of the free version is that its already built.
At this point I’m wondering which is worse… Open standards (and applications) which I support in principle, but which automagically corrupt my data when saving and / or crashing, or proprietary standards (and applications) which at least enable me to work productively.
No application should be considered usable (no matter how rich its feature set) and especially not in any professional context, if the action of simply opening a file can corrupt that file. And if I understand it correctly (and in a sense I hope I have misunderstood it) with autosave - a feature designed to mitigate against losing data - enabled, that’s effectively exactly what happens.
this issue applies only to the free/demo version of the program. it does not apply to any other builds. this already makes it a bit of a corner case, but an important one neverthless.
@linuxDSP: that mac starting up in the background will run ardour just fine
A Demo/freebie version will display http://ibin.co/1x8JlQrJxo6k when started. It could include a hint: “make a backup of the session”, but then again that’s what one should do anyway when encountering a bug in the first place and trying a different version.
Just like releases, nightly builds are available as both “Full version” (for subscribers) and “Demo/Free”, just have a look at http://nightly.ardour.org/
While it’s not nice that “Ardour the free/demo version” does not load/save plugin settings, what’s wrong with that? It’s a demo and it says so in multiple places. As you said, it can’t “be considered usable” because, well, as demo, it’s for demonstration and testing purposes only.
PS. Yes, I do also think that there are better ways to limit a demo that don’t affect the session state at all.
But “no plugin state” is the current deal and it’s not a big deal. If a user can’t read the warnings or does not bother, other free/demo limitations will eventually have the similar effects no matter what they will be.
While it's not nice that "Ardour the free/demo version" does not load/save plugin settings, what's wrong with that? It's a demo and it says so in multiple places. As you said, it can't "be considered usable" because, well, as demo, it's for demonstration and testing purposes only.
I don't have a problem with feature limited demos - after all, that's how my software works - so I get that saving and loading plugin settings is intentionally disabled, and I understand why. The problem is that (as I understand it) if you have a session which was created in a paid version and therefore contains plugin settings, then, for some reason, accidentally or otherwise (you might call it user error I suppose) you open that same session in a free version, auto-save can then re-save over that file, but without the plugin settings thereby corrupting the file.
I keep backups obviously, but the point remains, that I would not trust an application which corrupted a file, purely as a result of opening that file, which is effectively what can happen. I accept that its a corner case, but if its possible at all it could cause all kinds of problems.
Imagine that happening with other forms of documents, so, for example, you open some important document, as a final check to make sure its complete etc, before sending it to someone, and the action of doing that modifies the document on disk, but not in a way which is visible at the time in the application. If you then sent it, believeing it to be correct, it would be at best corrupted, or at worst missing vital information - not acceptable - even for a demo. That's what I have a problem with.
It doesn’t “corrupt” the file. It throws away plugin state. The session is still usable. Using the word “corrupted” is really pushing the semantics of that word.
We give you a warning that you may lose any plugin settings. If the user ignores it, what are we supposed to do?
Your scenario requires that a user who has worked on “some important document” now somehow has a free/demo version of the program, they start that version by mistake (unclear how, given how modern desktops work) and then ignore the warning (which requires an affirmative click to hide). I’m sorry, this is not a realistic “the program is at fault here” scenario to me.
Actually I would disagree with your assessment. While I don’t agree with some of LinuxDSPs wording, I think he has a very valid point. I have old sessions that I pull out with to teach with on occasion, and sometimes I have to do this on other machines by plugging in an external drive and grabbing a copy of Ardour, if for no other purpose than demonstration. All of a sudden I could lose settings via autosave here.
(Hypothetical user here) Or I had a session that crashed due to a bug in older versions of Ardour. I want to know if Ardour has improved so I download and run a test version of Ardour, even with warning this is ridiculously easy to lose data to, especially given the habit of people to click through error screens on occasion.
Obviously I am more likely to use a full version, but I know in the past for the sake of ease and quickness I have done that first example repeatedly in the past for several reasons, it is not as corner case as you might think (Though I may be as much a corner case as you may think:).
In the past, when an A3 session opened an A2, it made a backup first. I would suggest something similar here, but instead of making a backup, when opened with a demo version, it creates a new file and opens that so the original session is completely untouched, and that way any autosave still operates as well.
We are encouraging people to download Nightlies to see if issues they are having (bugs or un-expected behavior) still exist. The session they open could have been created on a purchased, but not subscribed to, version of Ardour. If they blindly click through the messages, as Seablade has pointed out people have a tendency to do, they are opening themselves up to loosing some of their session data. However much this could be said to be their own fault, and not defined as corruption per se, it’s not particularly “customer friendly”.
