On Thu, Nov 15, 2012 at 1:11 AM, Markus Grabner <[email protected]> wrote: > On Wednesday 14 November 2012 08:45:24 Stefan Hajnoczi wrote: >> The sysfs attributes involve MIDI commands and some state. If we >> leave this to userspace then the kernel driver can focus on PCM and >> MIDI I/O. The code will become much smaller and simpler because we >> can drop all the peeking into MIDI buffers and the housekeeping that >> goes along with that. >> >> Letting userspace handle MIDI means that line6linux development >> becomes accessible to a wider group of developers - people not >> comfortable with C or driver hacking. It encourages people to explore >> their devices and contribute code. > I agree with all of that. Let me point to a document which I started to write > a year ago when we first briefly discussed this: > > https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/branches/qtbased/doc/design.tex > > The sysfs attributes are ugly, but very convenient for development and > testing. I don't want to remove them without having a similarly convenient > replacement, that's why I started to write some code according to the ideas > discussed in the abovementioned document. Feel free to comment on this! > > One particular question is how to best control the driver's behaviour (e.g., > the midi masks) from user mode. I can imagine at least two methods: > *) using ioctl() calls > *) defining a virtual MIDI device for communication with the driver > > Are there more options, and what would be considered best practise in this > case?
Either ioctl() or sysfs is okay. ioctl() is very easy for C/C++ applications to use if they already have a file descriptor. For human-readable data sysfs is nicer since it can be accessed easily from a shell session. The challenge with sysfs is locating the device directory, but this could be done given the ALSA device numbers. The design document you posted looks sane and well thought out. I think the main "meat" of the library will be the data tables for each supported device. Ideally the library code would not hard-code names (e.g. amp1_gain, wah_position) but instead use self-describing data tables. The advantage here is that developers can easily add new tweak parameters by modifying the data tables. The only piece of software that needs to understand the parameter names is the GUI, and even there we could try to use a data-driven approach. In other words, the library doesn't need enums for all possible parameters. Instead you could say line6_set_param(dev, "master_volume", 0x40), which looks up "master_volume" in the device's data table. That produces a MIDI message (PC, CC, or SysEx). When the device sends MIDI messages to the host in response to the wah pedal, for example, the library uses the data table to translate from the MIDI message to event_param_changed(dev, "wah_position", 0x7f). The design document doesn't cover whether to make the library stateful or not. A stateless library simply transmits and receives events on behalf of the application. A stateful library keeps a "current value" stored for every parameter in the data table so that the application can retrieve it quickly. My feeling is that a stateless library is a good thing but there is a risk that applications will duplicate code, so we'd have to watch out if we find ourselves reimplementing the same state code in multiple applications. A small detail that came to mind: transmitting MIDI should be asynchronous just like receiving MIDI is. The reason for this is that sending large commands (e.g. restoring saved presets) should not block the GUI. Is there code to implement this design? Stefan ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Line6linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/line6linux-devel
