Looking at the 2.0 bug reports forum and having the last betas in mind, I’m thinking about handling all this plugin stuff a bit different, in favor of stability and compatibility.
We have a set of compatibility options, which only exist because many plugins don’t behave as they should (as the VST standard allows in theory). For example the “static buffer” option is something that is in theory not needed, but it is, because most hosts simply call VSTs on a fixed sized buffer (the current ASIO buffer size in most cases), so the plugins never get tested on “dynamic” buffers, thus they randomly work or not.
But wouldn’t it be wiser to be in first place more compatible and shit on the few CPU cycles that the more compatible ways of using VSTs/AUs do add? This would mean we do
enable “static buffers” for !all! plugins
do some other extra safety stuff that is needed like always clearing the plugins buffers, even when the VSTs are responsible to do so
Pros:
This way we would avoid a lot of “My VST doesn’t work, freezes, crackles” problems and could solve a variety of random VST/AU related crashes. For sure not all - don’t worry, your plugins will still randomly crash from time to time.
Cons:
We would add a bit (really just a bit) of CPU overhead for every VST/AU you use. And this would add a delay / latency of 512 samples per plugin, but this gets compensated by PDC in Renoise 2.0.
Again, this is just a !bit! of extra CPU overhead, but its overhead. Thats why we have this as option and not enabled by default. Also this avoids that we have to test/verify compatibility options for every plugins that gets released. I’m also a bit sick of taking care of all these plugin related problems because this costs so much time, which could be spend on new features instead…
Would it be possible to do this on a user definable per-VST level? That way your CPU cycles would only increase with problem VSTs? … could even have some defaults for known problem VSTs.
Only if you force me to make that an option. How would you explain such an option to a newbie? And if we make this an option, then it should be enabled by default.
The question is: Do you want to add one VST more per project - assuming all your projects are already at the limits of your CPU - or do you want to get less random crashes and other problems with plugins?
Can I suggest re-factoring the sqlite database into a single file with a new columns representing operating system, type of and status instead of the multiple sqlite files we have now i.e. CachedAUs.db, CachedFailedAUs.db, CachedFailedVSTs.db, CachedVSTs.db on OS X for example?
This will allow power users to trade optimized databases, as well as coders to write scripts to optimize the databases more easily i.e. point to 1 file instead of X files where X is dependent on platform?
We already have a list of settings that work, let’s keep those, but clean up the database representation of this information and consolidate it into a single file so it’s easier for power users to manage themselves.
All unknown plug-ins (i.e. all future plug-ins and the ones we never encountered) use taktik’s new idiot proof settings.
If the user wants to, he/she can edit the database and adjust the settings for these new/un-encountered plug-ins manually. Trade databases, whatever.
Lots of programs have options where power users can configure for their special environment, but the default is equivalent to what taktik is proposing.
Smart defaults which are not likely to be changed by mistake are good, but as this is an environment where a lot of people strive to make the most of their equipment, they should be allowed to control it.
go for it, make it optional, but at the same time please leave the power-features open. I might remind you of this little plugin called “senderella” that only works with an asio-buffersize of 256… I still want to be able to use this one somehow and when you say you will make every plugin use 512 samples then this might not work…
On the other hand, maybe I should just look for a substitute.
Sounds good to me, but as many others have said, leave the current system as optional, and keep this new slightly slower system as default.
Wouldn’t this be dependant on CPU speed? I’m guessing that will equate to less than 1/50th of a second? In some ways, I’m more concerned about latency than overall speed. When I press a key, I like instant sound coming from it
Make the stabile changes the default, but let the known plugins keep their default settings (the ones in the list we know they do need or can’t stand the static buffering)
The problem with static buffering is that some plugins that create delay do not report that delay. Are you sure the default delay with static buffering is 500ms?
Stability raise okay, but you will keep getting questions about plugins that pose a delay and in some cases, users might take this delay for granted for the FAQ PDC wisdom “Some plugins have delay but don’t report this correctly or don’t report this at all, Renoise cannot automatically correct this delay”
