I was working on an update for one of my plug-iNs the other day and discovered a
pretty cool method for testing plug-ins that I thought others might be able to use.
Usually, I get done with a plug-iN and test the plug-iN:
- Putting in bad data to check the input processors.
- Checking to make sure all of the functions work.
- etc.
Well, that’s pretty boring in my opinion. It’s always a big “yawn-fest” and it really
does nothing to get me “hyped-up” or excited.
Well, I figured a “new” way to test plug-iNs that I find REALLY fun and worthwhile.
First off, this method may prove somewhat difficult depending on your programming
style. I use a method I invented called “Structure Programming” where I break the code
into logical parts I call “modules”. Thus, I can paste one module after another, testing
them in the order that they run.
So, what I do is paste in a module and then make some “output” lines at the end to
see what is happening. This might seem difficult in XLISP given its poor performance
with screen output. For instance, suppose you have an input variables named:
FST
IBX
NT7
and in your end “output” you have:
(PRINT FST) : (PRINT IBX) : (PRINT NT7)
…it will print:
12
11
59
That can get pretty tedious to look at…
Now, you can get “around” this using PRIN1 so that they all print on one line, but this
lacks nice verbiage to make your DEBUG cooler looking. What you really want is
something like in BASIC such as:
PRINT “Slow Code”;FST
…but this won’t work in XLISP. You CAN use something like the format ~A command,
but this is what I use:
(SETQ SPEED (LIST 'Speed= SPM SPD)) : (PRINT SPEED)
(SETQ TREBC (LIST 'Treb-Cut= TCF TFQ TCT TCT)) : (PRINT TREBC)
(SETQ BASSC (LIST 'Bass-Cut= BCF BFQ BCT BCR)) : (PRINT BASSC)
(SETQ MODUZ (LIST 'TMM-AM= TMF TMQ TMW TWV AMO AFQ)) : (PRINT MODUZ)
(SETQ ECHOF (LIST 'Off-Echo= OFT MOS MEK MEZ)) : (PRINT ECHOF)
(SETQ VOLUME (LIST 'Volumes= MVL MVO OVL OVO TVL TVO)) : (PRINT VOLUME)
You can actually find out some pretty interesting stuff using this method. I’m not sure
if Audacity 1.3 does this, but Audi126 (which I use) is pretty “sketchy” about the input
sliders. For instance, my updated plug-in had volume inputs set to “real” (aka decimal)
with a default of 100 (in this case it was 100%). Well, when I checked the input module
I kept getting something like 99.9 percent, which was bad as I had it so code would be
skipped if the user kept it at 100% volume. If you manually (text-type) in 100 then it
WILL be 100, but you can’t expect all users to do that. Anyway, short story long, I
eventually just settled for using integer (aka whole number) for that input.
Well, that’s about it. Testing plug-iNs can be fun and a worthy time, and might even
give you some ideas for improving the code of your plug-iN.