Re: [Line6linux-devel] (no subject)

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

On Wednesday 01 May 2013 11:11:00 Andrej Kruták wrote:
> Hello all,
> 
> like others tried before me (according to the numerous results on "pod x3
> linux"), I'm yet another one to go this way.
> 
> 
> The usb messages to setup the X3 look simple enough (at least
> downloading/uploading the profiles+knobs), but knowing nothing about midi
> and line6linux, I'd like to ask you guys if you have any documentation
> anywhere.
No, all stuff so far has been implemented by observing the USB traffic while 
the device communicates with the Windows software provided by Line6.

> I saw you did quite a rewrite in recent weeks/months, dropping most of the
> code and putting it into the userspace qt tool.
Yes, there is ongoing work in 
https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/branches/qtbased 
to build a user space interface to PODxt devices (the only ones available to 
me for testing), and I tried to keep the code generic enough such that it 
should be possible to support other Line6 devices as well. Note that the 
software is currently not based on Qt despite the name of the branch (see
https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/branches/qtbased/README.txt).

However, progress has slowed down for two reasons:
*) The birth of my son in January :-)
*) It is not obvious to which extent the user space library should interpret 
messages received from the device. The simplest answer would be to interpret 
nothing at all (e.g., for the PODxt, just deliver the position of the volume 
knob in the range of 0 to 127, which is the value range of standard MIDI 
messages). However, it would be more natural to map the volume to a floating 
point number in the interval 0.0 to 1.0 since the volume always refers to a 
value between some minimum (zero) and maximum value. By doing so, a graphical 
representation of the volume knob position would not have to know about the 
device-specific range of the volume value. However, this can get much more 
complicated for other parameters. For example, on the PODxt, the actual range 
of some effect parameters (e.g., delay time) depends on the chosen effect 
model. As another example, the frequency base for the tuner should be given as 
an absolute frequency (e.g., 440Hz), independent of the range supported by the 
device. I tried some time to find a unified solution to this problem, but I 
think we should go ahead with the simple answer (just use the raw values) and 
leave a more intelligent mapping as future work. I'm sure it can be done 
within a C++ class hierarchy representing different devices, but it's not an 
easy task.

> So, is there any documentation for that stuff yet?
There is a high-level document which describes the design of the user space 
software:

https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/branches/qtbased/doc/design.tex

(run "cmake .; make" in the "qtbased" directory to create a PDF from the LaTeX 
source code)

Aside from that, I must admit that the source code is poorly documented, but 
if you are willing to contribute, I'll help you to find the relevant code 
locations.

> I mean specifically, how do you plan to
> support multiple devices using single binary. AFAIK, the pod XT has only
> single "processing line", X3 has one/two, and the HD500 probably can route
> signals even more wildly?
This is a good question, and since I only have a PODxt Pro/Live, I don't know 
an answer. Something like a "select active processing line" command in the 
user space library might be a solution. Can somebody please comment on the 
routing capabilities on the X3 and HD500 in some more detail?

> As I said, I don't know much about MIDI, so it's hard to tell for me, if
> the messages in X3 (bean) resemble it at all. What's your plan if it's
> different, is the userspace (planned t be) flexible enough?
It is intended to be flexible enough, and if it turns out it isn't, it should 
be changed. The goal is definitely to support different devices. The family of 
Line6 devices is mapped to a C++ class hierarchy, where virtual methods should 
be used to handle device-specific details.

> How is the profile uploading/downloading handled with the XT?
The PODxt simply transmits a constant sized block of data which encodes all 
settings in a device-specific way. Without interpreting such data, it is still 
possible to load and save settings, which I think is the most important use 
case. Interpretation of profile data and conversion to/from other formats 
(e.g., *.l6t) should be handled separately IMO.

> BUT the most important question - how is the PCM audio handled? On X3, from
> the USB dumps it seems that the windows driver simply opens the 0x86/0x2
> and the data start to flow. Is it the same with Pod XT too? The X3 should
> be able to send 4 types of signals (dry+wet+mix+something else), and the
> dumps also vaguely indicate this - the output data is 1152B each, while the
> input is 4608B. Does XT do the same, or is there just one signal?
The PODxt always inputs/outputs a 24 bit stereo signal at a sampling rate of 
39062.5 Hz (that's the 10MHz USB clock divided by 256, just in case you wonder 
:-) You can also select different signals, and in case of the dry signal, the 
left and right channel contain identical data. All of this is certainly task 
of the kernel driver and not the user space code, except the routing selection 
as long as it doesn't change the format of the audio data.

> I'm asking all this, because I don't want to spend too much time trying to
> parse the current code, searching for clues :) I gathered the usb
> interfaces between hw generations are similar in many regards - but it
> seems like HD300/HD500/X3/XT are quite nicely mixed, featurewise?
I can't really comment on this since I only have the XT. I received data dumps 
for other devices, but it's hard to interpret without the device available for 
experimenting.

	Kind regards,
		Markus