Viper｜1.2.2 update with bugfixes and new skin

[Norqa]

A Dark cloud will forever hang over a Flowstone Synth.
Like a Synth Edit thing that most punters often dismiss.
I still prefer Synths that are 100% coded outside another developers framework.

[SampleScience]

I still prefer Synths that are 100% coded outside another developers framework.

Does it even exist? Most plugins are coded in JUCE, which is a framework coded by another developer. If it's not JUCE, then it's most likely iPlug 2 or even something like Cabbage Audio (Puremagnetik plugins are built-in Cabbage Audio) or Hise Sampler.

[chk071]

Yes, not many plugins which really use a complete custom framework, I guess.

Why care though? It's completely invisible to the user. And, even with SynthEdit or Flowstone, you can write completely customized DSP. It's silly to point at the framework, because, there aren't even similarities between the plugins, if they use custom code.

Besides, if you (Norqua) hadn't mentioned it, noone would have noticed that there are people who are really bothered about the used framework. The only thing I could imagine which could be worth bothering about is the lack of certain formats as a limitation of the framework's output capabilities. So, ya, Mac people could be bothered, and they have a point.

[Norqa]

Does it even exist? Most plugins are coded in JUCE, which is a framework coded by another developer. If it's not JUCE, then it's most likely iPlug 2 or even something like Cabbage Audio (Puremagnetik plugins are built-in Cabbage Audio) or Hise Sampler.

I agree but every layer adds latency.
Are you suggesting to make the most efficient Vst it would first be good to add another layer such as Synth Edit or Flowstone?
Is that what Uh-he or Synapse do to make their Synths ultra tight?

[Norqa]

double post.

[chk071]

I agree but every layer adds latency.

Latency? The CPU usage might be a bit higher, but, why latency?

[Norqa]

Latency? The CPU usage might be a bit higher, but, why latency?

And what happens when the cpu doesn't or can't do its job, the daw adds latency to compensate, or at least it does on my computer.

[chk071]

And what happens when the cpu doesn't or can't do its job

Does that happen to you with Viper?

[Norqa]

Does that happen to you with Viper?

It happens with every Vst I have ever tried.
Each instance adds to overall cpu usuage which takes a hit on latency.
Vst's that are highly optimized suffer lesss.

[chk071]

It's the first time I hear that CPU usage adds latency.

[Norqa]

It's the first time I hear that CPU usage adds latency.

Its the first time I've heard that Cpu usuage doesn't add to any latency lag and crackling.
Perhaps I should downgrade my Cpu to up my Daw's performance?
Sounds good to me

[chk071]

I think you confuse something. Lowering buffer size for less latency leads to more CPU usage. Increased CPU usage doesn't add latency. At least I never heard it does.

[Norqa]

I think you confuse something. Lowering buffer size for less latency leads to more CPU usage. Increased CPU usage doesn't add latency. At least I never heard it does.

You are probably right chk071.
I am confused, all I know is the faster Cpu I have seems to grant me much better latency.
I can compose a track with many instances of various Vst's and my Daw reports back to me which vst
's are costing and the delay (latency) involved.

[omac]

@Norqa
When a framework is used it exports the code of the structures/methods that are used by your plugin, and they become a part of your plugin's executable. A compiled plugin dll is an executable designed to be called by your daw. The framework ceased being a factor when the dll was compiled. There's a common misconception of a plugin dll as being this fully interpreted program with a framework as a layer of abstraction that the daw is constantly accessing while the plugin is being used. It's not.

[Teksonik]

Yes, not many plugins which really use a complete custom framework, I guess.
Why care though?

One reason to care would be that the developer does not have command and control of the underlying code used in a third party framework.

I'm sure many people remember the infamous multiple instance bug that SynthEdit suffered from in the early days.
Developers who used SE at the time were powerless to fix the bug in SE and had to wait for Jeff to release a fix.

Now I'm not saying such bugs have been common in any framework over the years but the possibility does exist that some bug may creep into the underlying code.

We've seen some SE plugins not being able to get updated to 64 bit because of their dependence on modules written by someone else who had not updated those modules. The developer couldn't update their plugin to 64 bit because he/she didn't or couldn't write the module.

It's been that dependence on other parties that has always given me pause when considering the purchase of a "Save As" plugin and to the best of my knowledge I have never purchased an SE or FS plugin at least not willingly.

Viper using FS won't keep me from buying it since I do like it but it doesn't incentivize me to buy it. There is no real advantage to the end user when a developer uses SE/FS. It just makes it easier on the developer. I've never seen anyone say "I'd buy this plugin but it's not SE/SM/FS so I won't".

One thing to note about the frameworks is I often see developers claiming or bragging about "100% Coded in C++" but I rarely see anyone admit to using SE or FS, let along brag about it.

That may be due to the stigma those platforms have gained but that stigma will never go away if developers are ashamed to admit to using any framework.

With JUCE I think it's nearly impossible to avoid plugins made with it these days since it has become somewhat ubiquitous. To my very limited knowledge of the framework I get the impression it differs from SE/FS but I could be wrong and no doubt someone will be along to correct me in no time.