Viper|1.2.2 update with bugfixes and new skin
-
- Banned
- 203 posts since 13 Jul, 2021
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.
Like a Synth Edit thing that most punters often dismiss.
I still prefer Synths that are 100% coded outside another developers framework.
- KVRAF
- 4290 posts since 31 Oct, 2004
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.
-
- KVRAF
- 35436 posts since 11 Apr, 2010 from Germany
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.
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.
-
- Banned
- 203 posts since 13 Jul, 2021
I agree but every layer adds latency.SampleScience wrote: ↑Fri Oct 15, 2021 9:03 pm
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.
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?
Last edited by Norqa on Fri Oct 15, 2021 9:17 pm, edited 1 time in total.
-
- Banned
- 203 posts since 13 Jul, 2021
-
- Banned
- 203 posts since 13 Jul, 2021
-
- Banned
- 203 posts since 13 Jul, 2021
-
- KVRAF
- 35436 posts since 11 Apr, 2010 from Germany
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.
-
- Banned
- 203 posts since 13 Jul, 2021
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.
-
- KVRist
- 225 posts since 13 Jul, 2009
@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.
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.
- KVRAF
- 18561 posts since 16 Sep, 2001 from Las Vegas,USA
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.
None are so hopelessly enslaved as those who falsely believe they are free. Johann Wolfgang von Goethe