Difference between revisions of "Testing Plugins"

From MOD Wiki
Jump to navigation Jump to search
(How to validate you plugin data.)
m (Update the address of the lv2 repository)
 
(3 intermediate revisions by one other user not shown)
Line 13: Line 13:
 
=== Preparation ===
 
=== Preparation ===
  
Assuming you have installed <code>sord_validate</code> with your system package manager. On Arch Linux the package is called <code>lv2</code>.
+
Assuming you have installed <code>sord_validate</code> with your system package manager.
  
 
We clone the upstream LV2 repository:
 
We clone the upstream LV2 repository:
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
$ cd ~/Downloads
 
$ cd ~/Downloads
$ git clone http://lv2plug.in/git/cgit.cgi/lv2.git/
+
$ git clone http://lv2plug.in/git/lv2.git
 
$ cd lv2
 
$ cd lv2
 
</syntaxhighlight>
 
</syntaxhighlight>
The reason is linux distribution are probably not up to date. We don't want to waste time
+
These files might be also distributed in a package of your system package manager, e.g. package <code>lv2</code> on Arch Linux.
with errors that are fixed upstream!
+
The reason to clone the upstream source is your package data might be stale and we don't want to waste time
 +
with errors that are already fixed!
  
 
First let's check the release itself is not broken. The following should give no errors:
 
First let's check the release itself is not broken. The following should give no errors:
Line 66: Line 67:
 
== Stress tests ==
 
== Stress tests ==
  
lv2bm
+
Your plugin builds, runs and can be found on the LV2PATH. Let's test the code.
the other inf,denormal tool
+
 
 +
=== Testing with lv2bm ===
 +
 
 +
Download and compile the tool with
 +
<syntaxhighlight lang="bash">
 +
$ cd $MY_GITHUB_DIR
 +
$ git clone git@github.com:moddevices/lv2bm.git
 +
$ cd lv2bm
 +
$ make DEBUG=1
 +
</syntaxhighlight>
 +
Optionally you can install it on your system path.
 +
Make sure, you also built your plugin with debug symbols.
 +
 
 +
 
 +
If your plugin has the URI <code>http://example.org/mybundle</code> then you run the tool with:
 +
 
 +
<syntaxhighlight lang="bash">
 +
$ ./lv2bm --full-test http://example.org/mybundle
 +
...
 +
[Inferior 1 (process 5735) exited normally]
 +
</syntaxhighlight>
 +
 
 +
If your plugin crashes you can investigate it with
 +
<syntaxhighlight lang="bash">
 +
$ gdb --args ./lv2bm --full-test http://example.org/mybundle
 +
...
 +
(gdb) run
 +
...
 +
</syntaxhighlight>
 +
for example.
 +
 
 +
=== Torture tester ===
 +
 
 +
There is another tool to test LV2 plug-ins called [http://carlh.net/plugins/torture.php Torture tester].
 +
Install and build it:
 +
<syntaxhighlight lang="bash">
 +
$ cd $MY_GITHUB_DIR
 +
$ git clone git@github.com:cth103/plugin-torture.git
 +
$ cd plugin-torture
 +
$ make
 +
</syntaxhighlight>
 +
Again we don't install it on the system path.
 +
 
 +
Run it with
 +
<syntaxhighlight lang="bash">
 +
$ ./plugin-torture -d -a -e --lv2 -p ~/.lv2/alo.lv2/manifest.ttl
 +
</syntaxhighlight>
 +
Of course, you can wrap this with GDB as well. See <code>./plugin-torture -h</code> for the arguments explained.
  
 
== Does it load on MOD? ==
 
== Does it load on MOD? ==
  
 
mod-host trick
 
mod-host trick

Latest revision as of 18:29, 20 August 2019

WARNING: This page is currently being written, please check in later!

Error checking

Using SDK, needs py3lilv out of scope of this, see lilvlib for debian and osx

Plugin Data Validation

With RDF data it is possible to check the syntax and semantics. Syntax means, for example, you have not written a comma where ought to be a semicolon. Valid semantic means, for example, there is no AudioPort which is InputPort and OutputPort at the same time.

Preparation

Assuming you have installed sord_validate with your system package manager.

We clone the upstream LV2 repository:

$ cd ~/Downloads
$ git clone http://lv2plug.in/git/lv2.git
$ cd lv2

These files might be also distributed in a package of your system package manager, e.g. package lv2 on Arch Linux. The reason to clone the upstream source is your package data might be stale and we don't want to waste time with errors that are already fixed!

First let's check the release itself is not broken. The following should give no errors:

$ sord_validate $(find . -name '*.ttl')
Found 0 errors among 88 files (checked 1834 restrictions)

Second we need to have the definitions of the MOD extentions (which are documented at [1] and [2]).

$ cd ~/Downloads
$ mkdir ns-mod-ttl
$ cd ns-mod-ttl
$ wget http://moddevices.com/ns/mod/mod.doap.ttl
$ wget http://moddevices.com/ns/mod/mod.ttl
$ wget http://moddevices.com/ns/modgui/modgui.ttl
$ wget http://moddevices.com/ns/modgui/modgui.doap.ttl

Let's also check if the set union of the two is still valid:

$ sord_validate $(find ~/Downloads/lv2/ -name '*.ttl') $(find ~/Downloads/ns-mod-ttl/ -name '*.ttl')
Found 0 errors among 92 files (checked 1889 restrictions)

Now we are prepared.

Validate Your Plugin

What sord_validate does is, reading in the whole world of triples and proving that there are no conflicts with the rules. The rules are stated in the definitions you downloaded above.

If you can list your created Turtle files like this

$ find ~/.lv2/mybundle.lv2 -name '*.ttl'
/home/username/.lv2/mybundle.lv2/manifest.ttl
/home/username/.lv2/mybundle.lv2/seealso.ttl
...

then you can validate them by adding this command in the back:

$ sord_validate $(find ~/Downloads/lv2/ -name '*.ttl') $(find ~/Downloads/ns-mod-ttl/ -name '*.ttl') $(find ~/.lv2/mybundle.lv2 -name '*.ttl')

The result should be 0 errors. That's it.

Stress tests

Your plugin builds, runs and can be found on the LV2PATH. Let's test the code.

Testing with lv2bm

Download and compile the tool with

$ cd $MY_GITHUB_DIR
$ git clone git@github.com:moddevices/lv2bm.git
$ cd lv2bm
$ make DEBUG=1

Optionally you can install it on your system path. Make sure, you also built your plugin with debug symbols.


If your plugin has the URI http://example.org/mybundle then you run the tool with:

$ ./lv2bm --full-test http://example.org/mybundle
...
[Inferior 1 (process 5735) exited normally]

If your plugin crashes you can investigate it with

$ gdb --args ./lv2bm --full-test http://example.org/mybundle
...
(gdb) run
...

for example.

Torture tester

There is another tool to test LV2 plug-ins called Torture tester. Install and build it:

$ cd $MY_GITHUB_DIR
$ git clone git@github.com:cth103/plugin-torture.git
$ cd plugin-torture
$ make

Again we don't install it on the system path.

Run it with

$ ./plugin-torture -d -a -e --lv2 -p ~/.lv2/alo.lv2/manifest.ttl

Of course, you can wrap this with GDB as well. See ./plugin-torture -h for the arguments explained.

Does it load on MOD?

mod-host trick