API and tests

[Tim LaBerge]

I've committed some changes to the 'dev' branch of my gdigi clone on github:

https://github.com/tlaberge/gdigi/tree/dev

I've defined a simple API for interacting with the gdigi program from
the command line. It communicates requests and receives responses from
the gdigi program over a unix domain socket by exchanging UDP messages.

Currently, it supports two operations:

gdigi_get_parameter(id, position, &value)
gdigi_set_parameter(id, position, value)

The API is built into a library libgdigi.a which is linked with a new
executable gdigi_client:

gdigi_client [get|set] id position [value]
'value' is required for set, ignored for set.

There is a new directory Gdigi in which I build a Perl module Gdigi.pm
that provides bindings for the API. There is a sample perl script
gdigi.pl that demonstrates the use of Gdigi.pm.

I also added some code to gdigi itself. When run with the '-p' option,
gdigi will print a textual description of its internal effect tree. The
newly added Perl script gdigi_test.pl parses this output and uses the
API to exhaustively exercise all the effects and settings in the gui
(except for pedal assignment and the LFO's).

On my RP355, the script exercises 1648 test cases in about seven and a
half minutes. Based on its output, I fixed a number of bugs (mostly
omissions from the modifiers and xml_settings lists).

The API should be easy to extend in the obvious ways and allow gdigi to
interact with the rest of the world in interesting ways.

Please give the new code a spin. I plan to push it upstream fairly soon.

Best regards,

Tim

[Tomasz Moń]

On Sun, Dec 30, 2012 at 12:41 AM, Tim LaBerge <tlab...@visi.com> wrote:
> I've committed some changes to the 'dev' branch of my gdigi clone on github:
>
> https://github.com/tlaberge/gdigi/tree/dev
>
> I've defined a simple API for interacting with the gdigi program from the
> command line. It communicates requests and receives responses from the gdigi
> program over a unix domain socket by exchanging UDP messages.

I'm sorry to say that, but:
1.In GTK+-based application I would expect to use the GSocket and
GUnixSocketAddress which are available in GLib.
2.Despite point 1, I think that D-Bus [1] is more appropriate here
than unix domain socket.

GIO supports DBus since GLib release 2.26 [2] (even gtk+-3.0.0
required at least GLib 2.28).

> I also added some code to gdigi itself. When run with the '-p' option, gdigi
> will print a textual description of its internal effect tree. The newly
> added Perl script gdigi_test.pl parses this output and uses the API to
> exhaustively exercise all the effects and settings in the gui (except for
> pedal assignment and the LFO's).

This script is nice. Worked fine on RP250.

> The API should be easy to extend in the obvious ways and allow gdigi to
> interact with the rest of the world in interesting ways.

I think D-Bus interface would be superior. We would just need to
provide the interface specification (bus name should presumably be:
org.gdigi) and there wouldn't be need for libgdigi at all. Any client
application would just need to link to its D-Bus library be it: GDBus,
QtDBus or anything else.
Moreover, rest of the world quite heavily uses D-Bus already.

What do you think regarding this?

Regards,
Tomasz

[1] http://www.freedesktop.org/wiki/Software/dbus
[2] http://developer.gnome.org/gio/stable/gdbus-lowlevel.html

[Tim LaBerge]

On 01/02/2013 02:18 PM, Tomasz Moń wrote:
> I think D-Bus interface would be superior. We would just need to
> provide the interface specification (bus name should presumably be:
> org.gdigi) and there wouldn't be need for libgdigi at all. Any client
> application would just need to link to its D-Bus library be it: GDBus,
> QtDBus or anything else.
> Moreover, rest of the world quite heavily uses D-Bus already.
>
> What do you think regarding this?
>
> Regards,
> Tomasz
>
> [1]http://www.freedesktop.org/wiki/Software/dbus
> [2]http://developer.gnome.org/gio/stable/gdbus-lowlevel.html

I think that's a great idea. I'll rework the patch along those lines.

tjl