Website (main software list): https://jelstudio.dk/JELSTUDIO_software.html
Website (for this plugin): https://jelstudio.dk/VSTplugin_TestingAndDiagnostics/

Email: jelstudio@hotmail.com
Twitter: https://twitter.com/JELSTUDIO


this plugin is freeware



//////////
Understanding the file-name:

"VendorName - PluginName - (PluginVersion).mXX.f64.vst.dll"

Vendor-name (JELSTUDIO)
Plugin-name (TestingAndDiagnostics)
Plugin-version date (YYYYMMDD)
mXX = m32 for 32-bit version, m64 for 64-bit version
f64 = internal audio-calculations are done with 64bit precision
vst = this .dll file is a VST2 plugin
.dll = file extension



//////////
How to use:

Load the plugin in a VST-host.

There are no user-controls.

The plugin-display is inspired by design used in aviation, to give quick and easy overview of test-results.

Please allow a few seconds of 'warm-up' time for the tests to stabilize when the plugin is first run.

If Windows gets busy with background-tasks, there can be some small continues fluctuations in the test-results. Ideally they should be green all the time, since that indicates a 'rock-solid' stable system.


The tests:

-------------------------
test20
Reset test, should read 1 or 2.
High numbers mean the host is triggering a plugin-reset faster than the plugin can keep up with.

-------------------------
test30 and 31
Sample-block and latency test, should match the target-value.
A mis-match indicates the host may be resampling audio independently of the sound-card.

-------------------------
test40 and 41
Sample-rate test, should match the target-value.
A mis-match indicates the host may be resampling audio independently of the sound-card.

-------------------------
test50 and 51
Display refresh-rate test, should be above zero.
This is the frame-rate of the plugin-display (normally not audio-related, although it can be by design). If it reads zero the plugin does not update its display (This would indicate a 'stuck' or 'frozen' screen and should never happen unless something is seriously wrong)

-------------------------
For test20 to 51
Ext and Int (external and internal) should always match. If they do not, then the host is interfering with the plugin.
(Ext uses a variable the host can access, and thus, if it behaves badly, interfere with, while int uses a variable the host can not access, and thus, even if behaving badly, not interfere with.)



-------------------------
test60
This test requires you play one or more of the included 'dirac-train' test-samples (When you play a test-sample it MUST be followed by a pause of at least about 3-5 seconds. The plugin uses this silent period to determine if the test has concluded and what the final result of the test is. It also resets the test so it is ready to be repeated with a new test-sample)
The test is to determine what happens with the sample-rate between the sample-file and the plugin-input (If it is passed as-is or altered on the way)

How to use test60:

If your sound-device is running at a sample-rate of 44.1 kHz, then the sample-file called '44100' should count to exactly '10' and the test-result sample-rate should match the sample-rate your audio-device is currently running at. This indicates NO re-sampling between file and plugin-input is taking place (This is good and what we want)
Other sample-files should result in 'crazy' counts and 'crazy' test sample-rates, since this would indicate that live re-sampling IS taking place for those sample-files (Since they are not the same sample-rate that your audio-device is running at. This is ALSO good and what we want)

But test60 fails whenever a sample-file named differently from your audio-device's current sample-rate counts to exactly 10 and results in the same test sample-rate as your audio-device is currently operating at (Since a match here would mean that NO re-sampling is taking place, which in turn means the file is being fed to the plugin at the wrong playback-speed or time-velocity. This is bad and is NOT what we want)

For example; if you run your audio-device at 96 kHz and play the 44.1 kHz sample-file, then, if the 44.1 kHz file is being fed to the plugin as if it was a 96 kHz file (Which it will if no re-sampling is taking place between the file and the plugin-input), then the timing internally in the plugin will not match the playback-speed of the file (To the plugin this case would sound like mouse-voices in Disney's Cinderella, rather than the correct play-back speed))

You may not always be aware if a VST-host does this, since it may re-sample the output instead. Re-sampling the output will make the sound sound as if it is being played back at normal speed, but all the plugin-calculations will be at the wrong speed since they take place before the re-sampling point in the chain.
Or conversely; the plugin will run at its correct internal timing, but the song will play too fast or too slow inside the plugin, which means that when we hit the re-sample stage after the plugin's output, we basically convert the plugin's timing and sample-rate output when we correct the sample-file's playback-speed. This will lead to a situation similar to if you run the plugin at a slower or faster sample-rate than intended, relative to the sample-file's sample-rate.

Of course not all plugins require play-back speed to be correct, but some time-domain operations will sound different if play-back speed is too fast or too slow relative to what the plugin expects.





-------------------------
If you do not get 'all-green', these are the main possible reasons:
1: your host is not letting the sound-card be in control.
2: your windows-machine is not fully stable.
3: you found a bug in the plugin.
