Re: [Line6linux-devel] Status of line6 staging cleanup

[Markus G. <gr...@ic...>]

On Friday 16 November 2012 07:05:09 Stefan Hajnoczi wrote:
> On Thu, Nov 15, 2012 at 11:38 PM, Markus Grabner <gr...@ic...> 
wrote:
> > Am Donnerstag, 15. November 2012, 08:16:25 schrieb Stefan Hajnoczi:
> I'm not sure what the best practice is, I guess we'll see when
> submitting the patches to move the driver out of staging.
> 
> The only problem I see with sysfs is that it's not clear to me how to
> control file ownership.  Typically we need the 'audio' group to own
> the attrs so regular users can read/write them.  sysfs supports
> chmod(2)/chown(2) but I don't know whether udev(7) rules can apply
> ownership on sysfs attributes.
After reviewing the sysfs entries, I noticed that the MIDI mask and MIDI post 
processing flags are the only ones which do not directly translate to a 
message sent to the device, but affect driver state instead. The MIDI 
postprocessing can be moved to user space if necessary, the MIDI masks were 
introduced several years ago to make the driver play nicely with the 
rosegarden MIDI sequencer (I didn't check since then if this is still 
required). Unfortunately ioctl calls seem to be possible only for ALSA PCM 
devices, but not for ALSA MIDI devices, so we might lose this masking 
functionality if we take the ioctl approach, but I don't consider this high 
priority. The TonePort LEDs could be controlled via ioctl calls on the 
TonePort's PCM device, though :-)

> > The CSV table approach discussed in Section 4.4 of the design document
> > comes close to the self-describing data tables you mention above: all
> > relevant relations (e.g., the mapping between USB product ids and device
> > names, or between device parameters and corresponding MIDI byte codes)
> > are defined and edited in CSV files, which are automatically converted to
> > corresponding C++ code (enums, tables, maps, etc.) during the build
> > process. The application can then use these symbols as desired, and
> > consistently adding a new parameter to all relevant enum lists, tables,
> > maps, etc., is as easy as adding a single row to a CSV table. The created
> > files should contain a prominent notice that they were created
> > automatically, with a reference to the input file (this is not yet
> > implemented).
> > 
> > The perl script that does all this magic (parse_data.pl) is actually the
> > most complex piece of software in the user space code repository at this
> > time :-)
> Cool :).  I should try adding POD HD300 support.
That would actually be a great test for the flexibility of the framework! The 
following steps are required:

*) edit the csv-tables in
https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/branches/qtbased/libline6comm
according to the HD300. The table "tablecodeparam.csv" maps a MIDI byte code 
(first number in each row after "data") to the corresponding device parameter. 
I don't know if the HD300 behaves similarly (i.e., a single byte is sufficient 
to distinguish the different parameters in the MIDI message). Your USB monitor 
will tell you.

*) If the MIDI message format is different from the PODxt, you need to create 
a class representing the HD300 and implement a suitable 
HD300::midiMessageReceived(). See the files "pod.hpp" and "pod.cpp" for how 
this is done for the PODxt devices.

*) The shell is initialized by some hard-coded parameters in "shell.cpp", 
these need to be changed according to your system (it would be useful if the 
Stream class had a static method which lists all available devices such that 
the user can choose one -> TODO).

> > As far as I know it is not possible to query a single parameter value from
> > the device (e.g., the current volume), and even if it were, such a query
> > would require a host-device-host roundtrip and suffer from a (small)
> > delay. On the other hand, whenever changing to a different tone on a POD
> > device, the entire settings for the new tone are transmitted to the host
> > (~140 bytes). I therefore think that maintaining the current state is
> > useful here (that's actually how the driver currently responds to read
> > requests on special files representing device parameters, which would
> > also become obsolete in the driver when done by a user space library).
> 
> In a Qt GUI the widgets already keep state - you can ask a slider for
> its current value.  So the application doesn't need the library to
> duplicate that state.
Yes, but I was more thinking of a shell-like application, which doesn't have 
widgets at all. It would still be nice to do something like

PODxtPro> get volume
0.75
PODxtPro>

in the Line6 shell. Here the state must be maintained either by the library or 
by the application. Not sure which one is better...

> I think we're talking about the same thing here.  I mean that the ALSA
> MIDI write call should be non-blocking so that we don't block the main
> loop.
Ok, I just wanted to stress that achieving the non-blocking behaviour by means 
of multi-threading adds unnecessary complexity to the library (and to 
applications using the library).

Please let me knot if you have any questions (probably many) regarding the 
code!

	Kind regards,
		Markus