500ms (1/2 a second) would scare me to death if that’s the latency when pressing a key before hearing any sound… I’m guessing it won’t be that slow?
Be nicer to come to a decision where we can all ‘agree’ if poss I’m guessing…? Though it seems like there’w a general consensus on this one anyway. 
i thought power users where not a minority anymore ? i mean many of us bought a pc specialy to do music and most new computers are pretty powerfull anyway. i’d rather have that power work for me.
Where did people read 500ms. I read from original post 512 samples, which is 512 / 44100 * 1000 = 11.6ms
Its 256 samples, so we got about 5ms delay per VST. This delay/latency is indeed a problem, especially for FX, because the delay summs up when chaining them in tracks.
Again about the CPU usage: This is a very, very small overhead. Most of you would never have noticed this, so that should not stop us to gain more compatibility / less random crashes with buggy plugins. I can not understand why people prefer CPU usage over stability here, really. Because plugins anyway crash?
But looking at the responses (“make it optional” means, “add it, but I wont use it”) and the problems (mainly the summed up delay of plugin FX), we should not do this now, but take care of this in an upcoming release.
What I’ve done now for RC2 and thus also Renoise 2.0 final, is enabling static buffers for some plugins by vendor, not plugin ID. Its quite likely that plugins from the same vendor share parts of its sources, so they do also share bugs.
Vendors where we know that dynamic buffers are a problem are Native Instruments, Korg, IK Multimedia and all DSP card plugins. So all plugins from these vendors will have static buffers enabled in 2.0 final. These are mainly instruments so I doubt that this has noticeable negative side-effects (CPU/Latency wise).
What we should do/hope and try in future, is:
hoping that more and more vendors do test their plugins with Renoise, so we don’t have to take care about this
trying to run plugins outside of the Renoise process (in their own process) to avoid that buggy plugins crash or randomly “break” Renoise
will for sure use more CPU and memory, but is the only way to guarantee that Renoise does not crash anymore when a plugin does something bad. Looking at the amount of plugins out there, how seldom and how “rough” they are tested, this is really needed.
All sounds good, but just out of curiosity, is it possible or feasible to get it down from 256 samples to 128 or less?
I would use it, and then switch to the more buggy, quicker mode in emergencies when I need the extra speed (or if any compatibility problems arise which I doubt). That’s why optional would be nice Would you say the speed decrease is in about the 2% ballpark?
256 was chosen to keep the CPU overhead small, but yes, we could easily change this to 128 or could make this configurable. But again this is nothing we should do for this release, even if its unlikely that this would cause problems, it !can! cause problems…
Stability is a noble goal, with our current ability to tweak the buffers/settings per plugin, I don’t get why a new system should be imposed at all looking at the cons.
If a plugin crashed Renoise, I’ll try it on different settings if I really need it. If this doesn’t improve things, I don’t use it at all. There are probably tons of stable alternatives. To me it is clear vst(i)'s crash Renoise and it is often not the other way around. Don’t underestimate the users, plugin issue threads are commonplace on every music forum + if you download 1000+ (crappy looking) synthedit plugins you should know what to expect.
I don’t like the idea of Renoise being ‘crippled’ somewhat by a few rotten apple vst(i)s I never use anyway.
Thats why it stays ‘make it optional’ for me 