WOT: Return Codes

[mr_es335]

Good day,
To begin with, though I "studied" programming for a time...as the saying goes..."...I am not a programmer nor a programmer's son..." ...however...I would like to share with those that are interested some of the results of some recent research that I have been performing. And I do want to keep this whole process simple..."...'cause it wer'nt!"

Definition [Mine...by-the-way]: In programming, when the main program "calls" a specific part of that program - often referred to as a "function", to perform that function, to ensure that that function is performing correctly, a typically, numeric message called a "return code" is then sent back to the main program in order to report to the main program the end result - or the outcome, of precisely what that function was intended to do...and more importantly, if the function actually did what that function was intended to do!

When it comes to the use of "plug-ins" - what I have discovered is that some plug-ins[1] may either 1) not employ the use of return codes at all, or 2) improperly employ the use of "return codes". Though this possible lack of use of such return codes may not necessarily be an issue with some "host" applications - such as SAW and others, with SAC, and I can really only surmise here, is that the omission of such return codes may interfere with just how the plug-in is, in actuality, "responding" to the host.
* [1] Those plug-ins that do provide available source code.

How was I able to discover this potential anomaly you ask? When available, "Look at the code!"

With one plug-in in particular, the code is "open source" - simply meaning that the developer of that code has made that code available to others - this being "Freeverb3". That source code has been employed by many, many others - especially what is referred to as "Freeverb3 Hibiki". Thus, you can view the actual source code - updating that code as you see fit.

So, what is "deal" with SAC. In short, "Scenes". To keep this whole mess as-simple-as-is-possible, when you insert a plug-in in SAC, then create a scene based on that plug-in, that plug-in not only needs to respond with a "return call" of some soft, but that plug-in needs to also respond with any updates to that initial return call. I do hope that this all makes sense?

What I have discovered - and I am positive that words will escape me here, is that if the plug-in does not respond properly then, in short, "all hell breaks loose!" And this anomaly is precisely what I have been discovering and experiencing with many of the plug-ins that I have been testing - some 57 to be sure!

Out of those 57 plug-ins, only 3 functioned as expected - meaning that a mere 5% actually worked a you would expect!!

Following is a very simple outline of that testing process:
1. Install the plug-in into SAC
2. Launch SAC and create a new Mix session
3. Insert the plugin, and create 2 scenes - with each scene based on a different preset
4. Recall the scenes - observing the results
* Observation 1: What is important to realize during this scene recall process is that there can be any number of things going on here. Two in particular are 1) the update to the sound of the plug-in, and 2) the update to the user interface - including both the preset name and the update to the interface - that would normally accompany that preset update.
* Observation 2: Now, you would expect that plug-in to respond accordingly...correct? Well..."...that ain't necessarily so!"
* Observation 3: What I have been observing is that most of the plug-ins either 1) did not respond at all, or 2) the sound was updated but not the interface - especially the name of that preset!
5. If the plug-in did respond to either Step #3 or Step #4, the next procedure was to update the plug-in presets and then update each scene accordingly.
* Observation 1: In most situations, the majority of the plug-ins failed - 54 out of 57!! Of those that did not and whom provided open source code, I sent that code to an acquaintance whom IS a programmer, and asked them to examine that code. One interesting response was simply, "very buggy!"
* Observation 2: Without going into a whole lot of detail here, I then sent them an updated version of that code - again "open source", of one of the plug-ins that functioned as expected and that was based on the original source code, and again asked them to observe that updated version and their response, again in simple terms was, "Much better!"

In summary...
The original code was taken from one of the "ports" of the "Freeverb3"[1] code, and the second was an updated version of that code. The first - obviously, failed...whilst the second did not! The second version passed all scene tests - while the first failed in the second. Why? Maybe it was because one was "buggy" - and the other "not? Not being a programmer, I may never know the answer to that question. Then again, do I really have to know?
* [1]: Freeverb3
* [2]: Dragonfly Reverb

One final point, it IS interesting to note that many of the plug-ins tested employed the use of "JUCE"! And that is...as they say "That!"

I hope that some will find this information both "interesting" and to some practicable use?

[mr_es335]

Good day,

With regards to the Dragonfly Reverbs, I do believe that these 'verbs are as good as anything else out there...even the Valhalla's!

I have been "learning a bit" about 'verbs and I have been discovering that whatever I have been able to accomplish with the Fabfilter Pro-R, the Valhalla Room, the Valhalla Vintage Verb, or even the Relab LX480 Complete...I have been able to accomplish with the Dragonfly Reverbs.

Anyhow, I may have some good news with regards to these plug-ins within the next week! So...stay tuned! [Preferably in DADGAD!!]

Thanks for your time!