Page 1 of 1

OT: Plug-in Development

Posted: Sat Jun 03, 2023 10:07 am
by mr_es335
Good day,
Though this topic may initially appear not to be at all relevant, I sincerely believe that after perusing this text and then performing your own research, that this topic may indeed, become relevant - especially for SAC users.

Italics
The use of italics is important in that - at the end of the day, what is being written is my own personal view on the topic.

Preamble
It would appear that many developers today - either have not or do not build plug-ins "from scratch". Rather these developers employ the use of libraries or frameworks. Whatever these libraries or frameworks are, though relevant, are not specific to this topic. What is specific to this topic however, is with regards to problem solving, or more specifically, "debugging".

An example...
Many years ago now, I was beta-testing Guitar Rig 5 within SAC. At some point, I can across an anomaly that was submitted to Native Instruments for a possible resolve. As a beta-tester I was privy to the development platform that they were using at that time - which helped me in being able to explain the situation, as I had some experience with that particular platform. As NI was developing GR5 "from scratch" - they were able to track-down the anomaly and provide a "fix".

Fast-forward to today, as noted, many developers no longer develop software "from scratch" - but do indeed, use libraries or frameworks in their development efforts. What this means, in short, is that their ability to debug their software may be hampered by their use of such libraries and frameworks.

JUCE
One such framework is JUCE [Click_Me]. Even though JUCE is "open source" - this begs the question, "Do the developers really know what that open source data is actually doing?" From my own personal experience, it would appear that many developers really do not know what is actually going on in the source. In such cases, it would appear that though such developers are able to debug the "front end" - they have no idea what is going on in the "back end". I do hope that this makes sense.
* As was the case with SynthEdit, in JUCE, I created the GUI portion of a wave file player plug-in all without knowing any of the particulars of the actually programming language.

A personal example
To bring this all home, I use three plug-ins that were all recently updated. Prior to that update, I was able to perform scene updates in SAC to any of the plug-ins without incidence. After the update, the plug-in becomes "unresponsive". SAC is still functioning, but the plug-in is not. Reverting to the previous version - all worked as expected. Updating the plug-in, the plug-in is then unresponsive.

Quoting Sir Arthur Conan Doyle, "When you have eliminated the impossible, what is left, no matter how unlikely, is the truth"...thus, the update is the issue. I was later to discover that JUCE was used for all of the recent updates. Any attempt at a resolve from any of the developers however has proven to be thus far, unfruitful.

What does this all mean?
In short, for SAC users, it might be helpful to ascertain from the developers if any such libraries or frameworks were used in their applications.

In closing...
Though JUCE was originally developed in 2004, none of the current plug-ins - with the exception of those updates as noted above, use JUCE. In contacting a number of the developers from past plug-ins, none had used JUCE as well - though I never asked them if they might be currently using JUCE.

Also, I cannot say how many-and-what updates have occurred with JUCE itself, with the current version being, I believe, v7.

I hope that some will find this information of some practicable use?

Re: OT: Plug-in Development

Posted: Sun Jun 04, 2023 5:48 am
by John Ludlow
The thing about sophisticated software is that, unless you write completely in assembler, you are always standing upon the shoulders of an entire hierarchical army of past programmers, both living and dead, layer after layer. Visual C++ and all of its libraries are also just assembler being re-used. And so: if any of it has a bug - you have a bug.

There are two ways to look at that dynamic. On the one hand, if you don't use other's code in your work, you can't possibly inherit their bugs. On the other hand, in the process of re-creating wheel after wheel after wheel, and if you ever get done writing it, you may have left proportionately more of your own bugs in your code. The creators of code modules only have that specific functionality to be responsible for. And as the bugs are discovered in it, and fixed once, they are fixed forever for everyone who uses it and updates.

In your case, I wonder whether the new version of your plug-in requires access to a newer version of something else it re-uses. For instance, Philip came up with a brilliant fix for Other John (see link below) just a few weeks ago for a problem he had that sounds at least similar to the issue you're having.

Visual C++ programs rely upon, and make calls to, a code module called the Visual C++ Redistributable. There are successive versions of it that fix previous bugs and add new functionality. In theory they are backwards compatible. If your new plug-in version relies upon functionality that is only available in a newer version of the Redistributable than is installed on your computer, you may have problems such as you have described. Check this out:

https://www.groovypost.com/howto/fix-vi ... indows-10/

Worth a try!

Re: OT: Plug-in Development

Posted: Tue Jun 06, 2023 10:59 am
by mr_es335
Hello,

So, after some research, it would appear that a number of the developers went from JUCE v5 to JUCE v6 - and at about the time I began to notice some irregularities with those plug-ins in SAC.

Apparently JUCE v7 is out - as of 06/21/22.

I am unable to get confirmation if the problems will be resolved in v7 or not.

Re: OT: Plug-in Development

Posted: Wed Jun 07, 2023 6:04 pm
by John Ludlow
mr_es335 wrote:
I am unable to get confirmation if the problems will be resolved in v7 or not.
My presumption is that the portion of the Juice code that is used is compiled directly into the plug-in, rather than referred to externally. Is that true? Like, is there a separate file that is the Juice library that the plug-in draws from, or is there just the plug-in? Because if there's just the plug-in, then there's nothing you can do if the bug is within Juice. It would be kinda odd though because you'd presume that everyone would suffer from the same bug - and so it would have been noticed in alpha or beta testing.