line6linux-devel — mailing list for developers of Line6 Linux software

[Line6linux-devel] UX2 all over again

[Petter S. S. <pet...@gm...>]

Hello

I have a Line6 UX2 device which was working with linux for a couple of
years ago. I decided to give it another go today, and can not seem to get
it to work. After installing the drivers and plugging in the device the
device lights up and it appears in alsamixer like it used to. But when I
try to switch to it in system preferences my computer freezes and I have to
"pull the plug". Update: Now it freezes as soon as the dive is pluged in.
Running Ubuntu Gnome 13.10 (kernel 3.11.0-15-generic). Think this problem
is quite similar to the problem I had before, and I would love to see this
resolved.

Keep up the good work!

-- 

Med vennlig hilsen / Kind regards

[Line6linux-devel] Fwd: [PATCH] Add support for POD HD400 to line6usb driver

[Chris B. <cba...@gm...>]

This patch adds support for the Line 6 POD HD400 to the line6usb driver.

Signed-off-by: Chris Bajumpaa <cba...@gm...>

--- 8< Patch starts here ----

diff -ur stock/linux-3.11.6/drivers/staging/line6/driver.c
line6/linux-3.11.6/drivers/staging/line6/driver.c
--- stock/linux-3.11.6/drivers/staging/line6/driver.c    2013-10-18
14:24:16.000000000 -0400
+++ line6/linux-3.11.6/drivers/staging/line6/driver.c    2013-10-27
23:49:03.238659004 -0400
@@ -38,6 +38,7 @@
      {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_GUITARPORT)},
      {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_POCKETPOD)},
      {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD300)},
+    {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD400)},
      {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD500)},
      {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_GX)},
      {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_UX1)},
@@ -64,6 +65,7 @@
      { LINE6_BIT_GUITARPORT,    "GuitarPort",    "GuitarPort",
LINE6_BIT_PCM               },
      { LINE6_BIT_POCKETPOD,     "PocketPOD",     "Pocket POD",
LINE6_BIT_CONTROL           },
      { LINE6_BIT_PODHD300,      "PODHD300",      "POD HD300",
LINE6_BIT_CONTROL_PCM_HWMON },
+    { LINE6_BIT_PODHD400,      "PODHD400",      "POD HD400",
LINE6_BIT_CONTROL_PCM_HWMON },
      { LINE6_BIT_PODHD500,      "PODHD500",      "POD HD500",
LINE6_BIT_CONTROL_PCM_HWMON },
      { LINE6_BIT_PODSTUDIO_GX,  "PODStudioGX",   "POD Studio GX",
LINE6_BIT_PCM               },
      { LINE6_BIT_PODSTUDIO_UX1, "PODStudioUX1",  "POD Studio UX1",
LINE6_BIT_PCM               },
@@ -352,6 +354,7 @@
              break;

          case LINE6_DEVID_PODHD300:
+        case LINE6_DEVID_PODHD400:
          case LINE6_DEVID_PODHD500:
              break; /* let userspace handle MIDI */

@@ -693,6 +696,7 @@
      case LINE6_DEVID_PODXT:
      case LINE6_DEVID_PODXTPRO:
      case LINE6_DEVID_PODHD300:
+    case LINE6_DEVID_PODHD400:
          alternate = 5;
          break;

@@ -747,6 +751,7 @@
          break;

      case LINE6_DEVID_PODHD300:
+    case LINE6_DEVID_PODHD400:
          size = sizeof(struct usb_line6_podhd);
          ep_read = 0x84;
          ep_write = 0x03;
@@ -905,6 +910,7 @@
          break;

      case LINE6_DEVID_PODHD300:
+    case LINE6_DEVID_PODHD400:
      case LINE6_DEVID_PODHD500:
          ret = line6_podhd_init(interface,
                         (struct usb_line6_podhd *)line6);
@@ -1032,6 +1038,7 @@
              break;

          case LINE6_DEVID_PODHD300:
+        case LINE6_DEVID_PODHD400:
          case LINE6_DEVID_PODHD500:
              line6_podhd_disconnect(interface);
              break;
diff -ur stock/linux-3.11.6/drivers/staging/line6/pcm.c
line6/linux-3.11.6/drivers/staging/line6/pcm.c
--- stock/linux-3.11.6/drivers/staging/line6/pcm.c    2013-10-18
14:24:16.000000000 -0400
+++ line6/linux-3.11.6/drivers/staging/line6/pcm.c    2013-10-27
23:49:03.238659004 -0400
@@ -439,6 +439,7 @@
      case LINE6_DEVID_PODXTLIVE:
      case LINE6_DEVID_PODXTPRO:
      case LINE6_DEVID_PODHD300:
+    case LINE6_DEVID_PODHD400:
          ep_read = 0x82;
          ep_write = 0x01;
          break;
diff -ur stock/linux-3.11.6/drivers/staging/line6/usbdefs.h
line6/linux-3.11.6/drivers/staging/line6/usbdefs.h
--- stock/linux-3.11.6/drivers/staging/line6/usbdefs.h    2013-10-18
14:24:16.000000000 -0400
+++ line6/linux-3.11.6/drivers/staging/line6/usbdefs.h    2013-10-27
23:49:03.238659004 -0400
@@ -25,6 +25,7 @@
  #define LINE6_DEVID_GUITARPORT    0x4750
  #define LINE6_DEVID_POCKETPOD     0x5051
  #define LINE6_DEVID_PODHD300      0x5057
+#define LINE6_DEVID_PODHD400      0x5058
  #define LINE6_DEVID_PODHD500      0x414D
  #define LINE6_DEVID_PODSTUDIO_GX  0x4153
  #define LINE6_DEVID_PODSTUDIO_UX1 0x4150
@@ -48,6 +49,7 @@
      LINE6_INDEX_GUITARPORT,
      LINE6_INDEX_POCKETPOD,
      LINE6_INDEX_PODHD300,
+    LINE6_INDEX_PODHD400,
      LINE6_INDEX_PODHD500,
      LINE6_INDEX_PODSTUDIO_GX,
      LINE6_INDEX_PODSTUDIO_UX1,
@@ -68,6 +70,7 @@
      LINE6_BIT(GUITARPORT),
      LINE6_BIT(POCKETPOD),
      LINE6_BIT(PODHD300),
+    LINE6_BIT(PODHD400),
      LINE6_BIT(PODHD500),
      LINE6_BIT(PODSTUDIO_GX),
      LINE6_BIT(PODSTUDIO_UX1),
@@ -88,7 +91,9 @@
      LINE6_BITS_PODXTALL = LINE6_BIT_PODXT | LINE6_BIT_PODXTLIVE |
                    LINE6_BIT_PODXTPRO,
      LINE6_BITS_PODX3ALL = LINE6_BIT_PODX3 | LINE6_BIT_PODX3LIVE,
-    LINE6_BITS_PODHDALL = LINE6_BIT_PODHD300 | LINE6_BIT_PODHD500,
+    LINE6_BITS_PODHDALL =     LINE6_BIT_PODHD300 |
+                LINE6_BIT_PODHD400 |
+                LINE6_BIT_PODHD500,
      LINE6_BITS_BASSPODXTALL    = LINE6_BIT_BASSPODXT |
                    LINE6_BIT_BASSPODXTLIVE |
                    LINE6_BIT_BASSPODXTPRO

Re: [Line6linux-devel] Fwd: [PATCH] Add support for POD HD400 to line6usb driver

[Stefan H. <ste...@gm...>]

On Thu, Nov 21, 2013 at 6:27 PM, Chris <cba...@gm...> wrote:
> I didn't want this to get lost so I am posting it here as well.
>
>
> ---------- Forwarded message ----------
> From: Chris Bajumpaa <cba...@gm...>
> Date: Mon, Oct 28, 2013 at 12:01 AM
> Subject: [PATCH] Add support for POD HD400 to line6usb driver
> To: lin...@vg...
>
>
> Hello,
>
>     This patch adds support for the Line 6 POD HD400 to the line6usb driver.

Reviewed-by: Stefan Hajnoczi <ste...@gm...>

Please include a Signed-off-by: line.  See Documentation/SubmittingPatches.

[Line6linux-devel] Fwd: [PATCH] Add support for POD HD400 to line6usb driver

[Chris <cba...@gm...>]

I didn't want this to get lost so I am posting it here as well.


---------- Forwarded message ----------
From: Chris Bajumpaa <cba...@gm...>
Date: Mon, Oct 28, 2013 at 12:01 AM
Subject: [PATCH] Add support for POD HD400 to line6usb driver
To: lin...@vg...


Hello,

    This patch adds support for the Line 6 POD HD400 to the line6usb driver.


--- 8< Patch starts here ----

diff -ur stock/linux-3.11.6/drivers/staging/line6/driver.c
line6/linux-3.11.6/drivers/staging/line6/driver.c
--- stock/linux-3.11.6/drivers/staging/line6/driver.c    2013-10-18
14:24:16.000000000 -0400
+++ line6/linux-3.11.6/drivers/staging/line6/driver.c    2013-10-27
23:49:03.238659004 -0400
@@ -38,6 +38,7 @@
     {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_GUITARPORT)},
     {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_POCKETPOD)},
     {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD300)},
+    {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD400)},
     {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD500)},
     {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_GX)},
     {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_UX1)},
@@ -64,6 +65,7 @@
     { LINE6_BIT_GUITARPORT,    "GuitarPort",    "GuitarPort",
LINE6_BIT_PCM               },
     { LINE6_BIT_POCKETPOD,     "PocketPOD",     "Pocket POD",
LINE6_BIT_CONTROL           },
     { LINE6_BIT_PODHD300,      "PODHD300",      "POD HD300",
LINE6_BIT_CONTROL_PCM_HWMON },
+    { LINE6_BIT_PODHD400,      "PODHD400",      "POD HD400",
LINE6_BIT_CONTROL_PCM_HWMON },
     { LINE6_BIT_PODHD500,      "PODHD500",      "POD HD500",
LINE6_BIT_CONTROL_PCM_HWMON },
     { LINE6_BIT_PODSTUDIO_GX,  "PODStudioGX",   "POD Studio GX",
LINE6_BIT_PCM               },
     { LINE6_BIT_PODSTUDIO_UX1, "PODStudioUX1",  "POD Studio UX1",
LINE6_BIT_PCM               },
@@ -352,6 +354,7 @@
             break;

         case LINE6_DEVID_PODHD300:
+        case LINE6_DEVID_PODHD400:
         case LINE6_DEVID_PODHD500:
             break; /* let userspace handle MIDI */

@@ -693,6 +696,7 @@
     case LINE6_DEVID_PODXT:
     case LINE6_DEVID_PODXTPRO:
     case LINE6_DEVID_PODHD300:
+    case LINE6_DEVID_PODHD400:
         alternate = 5;
         break;

@@ -747,6 +751,7 @@
         break;

     case LINE6_DEVID_PODHD300:
+    case LINE6_DEVID_PODHD400:
         size = sizeof(struct usb_line6_podhd);
         ep_read = 0x84;
         ep_write = 0x03;
@@ -905,6 +910,7 @@
         break;

     case LINE6_DEVID_PODHD300:
+    case LINE6_DEVID_PODHD400:
     case LINE6_DEVID_PODHD500:
         ret = line6_podhd_init(interface,
                        (struct usb_line6_podhd *)line6);
@@ -1032,6 +1038,7 @@
             break;

         case LINE6_DEVID_PODHD300:
+        case LINE6_DEVID_PODHD400:
         case LINE6_DEVID_PODHD500:
             line6_podhd_disconnect(interface);
             break;
diff -ur stock/linux-3.11.6/drivers/staging/line6/pcm.c
line6/linux-3.11.6/drivers/staging/line6/pcm.c
--- stock/linux-3.11.6/drivers/staging/line6/pcm.c    2013-10-18
14:24:16.000000000 -0400
+++ line6/linux-3.11.6/drivers/staging/line6/pcm.c    2013-10-27
23:49:03.238659004 -0400
@@ -439,6 +439,7 @@
     case LINE6_DEVID_PODXTLIVE:
     case LINE6_DEVID_PODXTPRO:
     case LINE6_DEVID_PODHD300:
+    case LINE6_DEVID_PODHD400:
         ep_read = 0x82;
         ep_write = 0x01;
         break;
diff -ur stock/linux-3.11.6/drivers/staging/line6/usbdefs.h
line6/linux-3.11.6/drivers/staging/line6/usbdefs.h
--- stock/linux-3.11.6/drivers/staging/line6/usbdefs.h    2013-10-18
14:24:16.000000000 -0400
+++ line6/linux-3.11.6/drivers/staging/line6/usbdefs.h    2013-10-27
23:49:03.238659004 -0400
@@ -25,6 +25,7 @@
 #define LINE6_DEVID_GUITARPORT    0x4750
 #define LINE6_DEVID_POCKETPOD     0x5051
 #define LINE6_DEVID_PODHD300      0x5057
+#define LINE6_DEVID_PODHD400      0x5058
 #define LINE6_DEVID_PODHD500      0x414D
 #define LINE6_DEVID_PODSTUDIO_GX  0x4153
 #define LINE6_DEVID_PODSTUDIO_UX1 0x4150
@@ -48,6 +49,7 @@
     LINE6_INDEX_GUITARPORT,
     LINE6_INDEX_POCKETPOD,
     LINE6_INDEX_PODHD300,
+    LINE6_INDEX_PODHD400,
     LINE6_INDEX_PODHD500,
     LINE6_INDEX_PODSTUDIO_GX,
     LINE6_INDEX_PODSTUDIO_UX1,
@@ -68,6 +70,7 @@
     LINE6_BIT(GUITARPORT),
     LINE6_BIT(POCKETPOD),
     LINE6_BIT(PODHD300),
+    LINE6_BIT(PODHD400),
     LINE6_BIT(PODHD500),
     LINE6_BIT(PODSTUDIO_GX),
     LINE6_BIT(PODSTUDIO_UX1),
@@ -88,7 +91,9 @@
     LINE6_BITS_PODXTALL = LINE6_BIT_PODXT | LINE6_BIT_PODXTLIVE |
                   LINE6_BIT_PODXTPRO,
     LINE6_BITS_PODX3ALL = LINE6_BIT_PODX3 | LINE6_BIT_PODX3LIVE,
-    LINE6_BITS_PODHDALL = LINE6_BIT_PODHD300 | LINE6_BIT_PODHD500,
+    LINE6_BITS_PODHDALL =     LINE6_BIT_PODHD300 |
+                LINE6_BIT_PODHD400 |
+                LINE6_BIT_PODHD500,
     LINE6_BITS_BASSPODXTALL    = LINE6_BIT_BASSPODXT |
                   LINE6_BIT_BASSPODXTLIVE |
                   LINE6_BIT_BASSPODXTPRO

Re: [Line6linux-devel] pod hd desktop

[Alexander P. <pon...@gm...>]

I have some expirience in C programming. But i'm in doubt about kernel 
module... looks like rocket science for me. I think that i can provide 
packet capture, only need to find windows machine.
I would appreciate it if someone could help me.

Re: [Line6linux-devel] pod hd desktop

[Stefan H. <ste...@gm...>]

On Fri, Aug 9, 2013 at 6:25 AM, Александр Понимаскин
<pon...@gm...> wrote:
> Is support for hd desktop (id 0e41:4156 ) planned?

My guess is that Pod HD desktop works in the same way as a HD500,
which is currently not supported.

Adding support first requires studying the USB packet capture.  I
think no one has provided packet captures for this device yet.

That said, I'm busy and cannot add support myself even if you do send
the packet capture.  Maybe Markus or someone else is willing to help
you if you can provide packet captures.  Or if you are a developer
with C programming experience you could try adding it yourself.

There are free tools for Windows and Linux to collect USB packet
captures.  The idea is to record what happens when you connect your
POD to your computer running the official Windows drivers.  Also
capture what happens during recording audio and using HD Edit.

By studying the capture it is possible to implement compatible
behavior in the line6usb Linux driver.

Stefan

[Line6linux-devel] pod hd desktop

[Александр П. <pon...@gm...>]

Hi,
Is support for hd desktop (id 0e41:4156 ) planned?

Re: [Line6linux-devel] Regression upstream

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

On Tuesday 11 June 2013 10:46:13 Jimi wrote:
> Hi,
> 
> Seems like the upsteram kernel does not care so much for the
> drivers in staging. Is there any chance you could give your
> beloved driver little more love with 3.8.0+ kernels?
> https://bugzilla.kernel.org/show_bug.cgi?id=53801
> and
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1103018
> 
> Would really be appriciated, thanks for everything. ;)
> 
> Best regards,
> Jimmie

I just tested my PODxt Pro under openSUSE-12.3 with kernel 3.9.5, and audio 
output works fine there. I will also try with a GuitarPort, which is a closer 
match to the POD Studio UX2.

	Kind regards,
		Markus


P.S.: May I suggest to continue this discussion on the mailing list since 
other users might have the same issue?

Re: [Line6linux-devel] POD HD500

[Paddy <mr...@li...>]

L. Alberto Giménez <agimenez@...> writes:

> 
> On Wed, Apr 17, 2013 at 05:39:55PM +0000, varomix wrote:
> > Hey Sébastien
> > 
> > does USB audio recording works?
> > I only want to be able to record, tone editing I can do in 
my laptop but I 
> > love to record on my linux box
> 
> Hi,
> 
> I tested the driver some months ago and all I got was a system 
freeze :( I intend to
> start working on it someday but you know, Real Life (tm) work 
and other
> hobbies/chores keep me away of getting my hands dirty :(
> 
> If I get to work on it again, I'll post to the list my 
progress!
> 
> Regards,

I would be quite interested in helping any way I can. I own a 
POD HD500 and I'd like to think I can code, but I have never 
done any kernel/driver hacking at all and haven't done any 
coding in over a year.

Re: [Line6linux-devel] (no subject)

[Andrej K. <de...@an...>]

On Fri, May 3, 2013 at 12:40 AM, Markus Grabner <gr...@ic...>wrote:

> On Thursday 02 May 2013 22:51:04 Stefan Hajnoczi wrote:
> > On Thu, May 2, 2013 at 7:51 PM, Andrej Kruták <de...@an...> wrote:
> > > On Thu, May 2, 2013 at 4:39 PM, Stefan Hajnoczi <ste...@gm...>
> > >> Can you explain what you mean regarding volume sent as a float?  Do
> > >> you have a traffic capture?
> > >
> > > This is how the frames look like, either incoming or outcoming.
> > >
> > > OUT: 1C 00 01 00 | 06 00 0A 40 01 03 00 | 15 00 00 00 00 00 00 03 00
> 01 00
> > > 00 00 05 00 10 3F CE 66 33 3F
> > > IN:  1C 00 01 00 | 06 00 0A 03 00 40 00 | 15 00 00 00 00 00 00 03 00
> 01 00
> > > 00 00 05 00 10 3F 70 BE 79 3F
> > >
> > > My guess is that the first 4 bytes is frame header (more frames can be
> > > combined into single packet, first byte is frame len - 4). The second
> part
> > > is the packet header (with type and source/destination flags of some
> kind,
> > > or so it seems - the 40/03 bytes there). I'm not sure if some part of
> the
> > > last thing could be a MIDI message - as I said, I don't know too much
> in
> > > this regard. Anyhow, the last 4 bytes is an IEEE 754 float (seems like
> > > it's
> > > in big endian). The 05 byte means the volume knob id.
> > >
> > > So... you said MIDI is extensible - do you think the last part of the
> > > above
> > > (or last two parts?) could be somehow directly used in the userspace?
> >
> > The CE and BE bytes indicate this is not part of a MIDI message.  MIDI
> > data is 7-bit, the top bit must be clear.  Therefore this cannot be
> > MIDI.
> Damn :-( This makes things more complicated in two ways:
>
> *) My previous proposal to use raw values won't work since not only the
> parameter range, but also the data type differs among devices. So a
> mapping to
> the most expressive data type (float in this case) is desirable.
>

*) Technically it is possible to map a virtual MIDI device to the USB
> interface (just as it is done by the PODxt driver) and then send arbitrary
> (not necessarily MIDI-conforming) data to that device. However, this is at
> least confusing since such device would be listed among available MIDI
> devices
> although it doesn't follow the MIDI standard. I tried to use libusb to
> directly access the USB interface in user-space code, but this requires to
> claim the interface, which is not possible if PCM data is transmitted over
> the
> interface at the same time by the kernel driver. This raises two questions:
> -) Is it possible to access a USB interface by libusb which is currently
> claimed by a kernel driver?
> -) If MIDI is not appropriate, which other interface can be used by the
> kernel
> driver as a "link" between the USB interface and user-space code?
>

Hmm, if it's possible to use arbitrary (number) formats in MIDI, and send
some custom data, I'd go this way. To me it makes sense - I would like to
be able to change/automate the device's settings by some standard way, and
I doubt there's any better standard for this than MIDI.

I'll try to figure out the basics of the X3 USB protocol - how to
upload/download profiles, and how to set individual knobs (and e.g.
input/output ports). All this would be exported via virtual MIDI. The
meaning of all the knobs would be up to the userspace, since (as you said),
it may change depending on the current settings and requires parsing of the
l6f files or whatever.

I guess we'll talk once/if I figure it out. I'll have a look on MIDI/SysEx,
maybe it will fit somehow?

How is the setup of the device "profile" done currently (e.g. changing AMP
type) - also via some MIDI command with encoded file attached? The GearBox
downloads all the settings from X3 during the start, which are some chunks
of data. Also, when AMP type is changed on PC, it seems like the complete
profile is uploaded (didn't check the opposite way, maybe it will be
simpler). The profiles also are 8-bit (bytes >= 0x80 are present)... We
could recode this somehow, to fit it into MIDI (if needed) - or we could
export some files into /sys (like profile0...profile32), which would
read/write the setting from/to the device. Depends on how it's done now -
probably it's not worth rewriting everything (again).


BUT. Currently, my device (w/o any intervention) just stopped working even
under Windows (gearbox won't talk to it properly, even though I can see USB
messages coming from the device like before). I hope it's just some USB
cable problem, I'll try it on some other machine, we'll see... This Line6
hardware is very flimsy :-(

--
Andrej

Re: [Line6linux-devel] (no subject)

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

On Thursday 02 May 2013 22:51:04 Stefan Hajnoczi wrote:
> On Thu, May 2, 2013 at 7:51 PM, Andrej Kruták <de...@an...> wrote:
> > On Thu, May 2, 2013 at 4:39 PM, Stefan Hajnoczi <ste...@gm...> 
> >> Can you explain what you mean regarding volume sent as a float?  Do
> >> you have a traffic capture?
> > 
> > This is how the frames look like, either incoming or outcoming.
> > 
> > OUT: 1C 00 01 00 | 06 00 0A 40 01 03 00 | 15 00 00 00 00 00 00 03 00 01 00
> > 00 00 05 00 10 3F CE 66 33 3F
> > IN:  1C 00 01 00 | 06 00 0A 03 00 40 00 | 15 00 00 00 00 00 00 03 00 01 00
> > 00 00 05 00 10 3F 70 BE 79 3F
> > 
> > My guess is that the first 4 bytes is frame header (more frames can be
> > combined into single packet, first byte is frame len - 4). The second part
> > is the packet header (with type and source/destination flags of some kind,
> > or so it seems - the 40/03 bytes there). I'm not sure if some part of the
> > last thing could be a MIDI message - as I said, I don't know too much in
> > this regard. Anyhow, the last 4 bytes is an IEEE 754 float (seems like
> > it's
> > in big endian). The 05 byte means the volume knob id.
> > 
> > So... you said MIDI is extensible - do you think the last part of the
> > above
> > (or last two parts?) could be somehow directly used in the userspace?
> 
> The CE and BE bytes indicate this is not part of a MIDI message.  MIDI
> data is 7-bit, the top bit must be clear.  Therefore this cannot be
> MIDI.
Damn :-( This makes things more complicated in two ways:

*) My previous proposal to use raw values won't work since not only the 
parameter range, but also the data type differs among devices. So a mapping to 
the most expressive data type (float in this case) is desirable.

*) Technically it is possible to map a virtual MIDI device to the USB 
interface (just as it is done by the PODxt driver) and then send arbitrary 
(not necessarily MIDI-conforming) data to that device. However, this is at 
least confusing since such device would be listed among available MIDI devices 
although it doesn't follow the MIDI standard. I tried to use libusb to 
directly access the USB interface in user-space code, but this requires to 
claim the interface, which is not possible if PCM data is transmitted over the 
interface at the same time by the kernel driver. This raises two questions:
-) Is it possible to access a USB interface by libusb which is currently 
claimed by a kernel driver?
-) If MIDI is not appropriate, which other interface can be used by the kernel 
driver as a "link" between the USB interface and user-space code?

Do you have any suggestions?

	Kind regards,
		Markus

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

Re: [Line6linux-devel] (no subject)

[Stefan H. <ste...@gm...>]

On Thu, May 2, 2013 at 7:51 PM, Andrej Kruták <de...@an...> wrote:
> On Thu, May 2, 2013 at 4:39 PM, Stefan Hajnoczi <ste...@gm...> wrote:
>>
>> On Wed, May 1, 2013 at 9:33 PM, Andrej Kruták <de...@an...> wrote:
>> > On Wed, May 1, 2013 at 7:30 PM, Stefan Hajnoczi <ste...@gm...>
>> > wrote:
>> >>
>> >> On Wed, May 1, 2013 at 11:11 AM, Andrej Kruták <de...@an...> wrote:
>> >> > 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? How is
>> >> > the
>> >> > profile uploading/downloading handled with the XT?
>> >>
>> >> Userspace should support multiple devices in a data-driven way -
>> >> adding support for a new device should (mostly) mean populating a
>> >> table of MIDI messages.
>> >>
>> > So in case there's no real MIDI in the device, you expect it to be
>> > somehow
>> > emulated by the driver, right? But for example the volume is send from
>> > X3 as
>> > a float number, while in MIDI (after a short look) it seems to be just
>> > an
>> > unsigned char....
>>
>> No, MIDI is not emulated by the driver.  In some cases the driver
>> spies on MIDI traffic or generates MIDI messages internally, but it
>> doesn't process MIDI messages and convert them into Line6-specific I/O
>> operations.
>>
>> MIDI is extensible and you can send arbitrary data over it (may
>> involve a 7-bit encoding).  Line6 uses a custom MIDI mapping and
>> parameters can be floats, fixed-point, etc.
>>
>> Can you explain what you mean regarding volume sent as a float?  Do
>> you have a traffic capture?
>>
>
> This is how the frames look like, either incoming or outcoming.
>
> OUT: 1C 00 01 00 | 06 00 0A 40 01 03 00 | 15 00 00 00 00 00 00 03 00 01 00
> 00 00 05 00 10 3F CE 66 33 3F
> IN:  1C 00 01 00 | 06 00 0A 03 00 40 00 | 15 00 00 00 00 00 00 03 00 01 00
> 00 00 05 00 10 3F 70 BE 79 3F
>
> My guess is that the first 4 bytes is frame header (more frames can be
> combined into single packet, first byte is frame len - 4). The second part
> is the packet header (with type and source/destination flags of some kind,
> or so it seems - the 40/03 bytes there). I'm not sure if some part of the
> last thing could be a MIDI message - as I said, I don't know too much in
> this regard. Anyhow, the last 4 bytes is an IEEE 754 float (seems like it's
> in big endian). The 05 byte means the volume knob id.
>
> So... you said MIDI is extensible - do you think the last part of the above
> (or last two parts?) could be somehow directly used in the userspace?

The CE and BE bytes indicate this is not part of a MIDI message.  MIDI
data is 7-bit, the top bit must be clear.  Therefore this cannot be
MIDI.

>> >> Don't expect anything close to the Line6 Editor working yet.
>> >> Personally, I care about a solid PCM and MIDI driver, but I don't care
>> >> so much about a Line6 Editor.  If someone invests the time then I'm
>> >> sure it would be doable in a couple of months.
>> >>
>> >
>> > For me, it'd be enough to just dump all the settings, put (some of) them
>> > back through some sys file, for example (or ioctl). According to the USB
>> > comm, it seems it's easily doable. Editing would be nice, I saw there's
>> > some
>> > work around that done already - but as yuo say, someone has to have time
>> > for
>> > it... :)
>>
>> Dumping the device is easy on the HD300, maybe it's the same on yours.
>>
> Not sure. X3 doesn't support MIDI (no midi in/out ports on the device
> itself) according to the specs. But I doubt they have completely different
> HW for X3 and X3 Live (which has MIDI), so the protocol could be the same -
> and the USB data could be indeed some encoded MIDI messages...
>
>
>> The device has a MIDI dump option available in an options menu.  You
>> can select whether to dump just the current patch or all patches.
>>
>> When you activate MIDI dump the device sends all the patches over
>> MIDI.  On your computer you can use amidi(1) to save this to file.
>>
>> Later you use amidi(1) to send the sysex back to the device, restoring
>> the patch(es).
>>
>> If you don't enjoy using amidi(1) I bet some of the graphical DAWs or
>> MIDI tools under Linux also support storing/loading sysex dumps.
>>
> I'll try to read something about this (sysex, MIDI format etc.) so I don't
> bother you with basic stuff..

http://www.midi.org/techspecs/midimessages.php

For example, switching to patch 1 would be:
Program Change (channel=0, patch=0):
C0 00

By the way, the table shows why MIDI uses 7-bit data.  Status bytes
have the top bit set, data bytes have the top bit cleared.

> Anyhow, back to the audio stream. How does the data transfer work on HD300?
> Is there any setup, or you just read/write the appropriate USB ports?

HD300 audio is just PCM data sent to/received via isochronous
transfer.  No setup is required.

Some of the other devices have more elaborate setup procedures where
several messages are exchanged with the device.  But once set up, they
also just use iso USB transfers of PCM data.

Stefan

Re: [Line6linux-devel] (no subject)

[Andrej K. <de...@an...>]

On Thu, May 2, 2013 at 4:39 PM, Stefan Hajnoczi <ste...@gm...> wrote:

> On Wed, May 1, 2013 at 9:33 PM, Andrej Kruták <de...@an...> wrote:
> > On Wed, May 1, 2013 at 7:30 PM, Stefan Hajnoczi <ste...@gm...>
> wrote:
> >>
> >> On Wed, May 1, 2013 at 11:11 AM, Andrej Kruták <de...@an...> wrote:
> >> > 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? How is the
> >> > profile uploading/downloading handled with the XT?
> >>
> >> Userspace should support multiple devices in a data-driven way -
> >> adding support for a new device should (mostly) mean populating a
> >> table of MIDI messages.
> >>
> > So in case there's no real MIDI in the device, you expect it to be
> somehow
> > emulated by the driver, right? But for example the volume is send from
> X3 as
> > a float number, while in MIDI (after a short look) it seems to be just an
> > unsigned char....
>
> No, MIDI is not emulated by the driver.  In some cases the driver
> spies on MIDI traffic or generates MIDI messages internally, but it
> doesn't process MIDI messages and convert them into Line6-specific I/O
> operations.
>
> MIDI is extensible and you can send arbitrary data over it (may
> involve a 7-bit encoding).  Line6 uses a custom MIDI mapping and
> parameters can be floats, fixed-point, etc.
>
> Can you explain what you mean regarding volume sent as a float?  Do
> you have a traffic capture?
>
>
This is how the frames look like, either incoming or outcoming.

OUT: 1C 00 01 00 | 06 00 0A 40 01 03 00 | 15 00 00 00 00 00 00 03 00 01 00
00 00 05 00 10 3F CE 66 33 3F
IN:  1C 00 01 00 | 06 00 0A 03 00 40 00 | 15 00 00 00 00 00 00 03 00 01 00
00 00 05 00 10 3F 70 BE 79 3F

My guess is that the first 4 bytes is frame header (more frames can be
combined into single packet, first byte is frame len - 4). The second part
is the packet header (with type and source/destination flags of some kind,
or so it seems - the 40/03 bytes there). I'm not sure if some part of the
last thing could be a MIDI message - as I said, I don't know too much in
this regard. Anyhow, the last 4 bytes is an IEEE 754 float (seems like it's
in big endian). The 05 byte means the volume knob id.

So... you said MIDI is extensible - do you think the last part of the above
(or last two parts?) could be somehow directly used in the userspace?


 >> Don't expect anything close to the Line6 Editor working yet.
> >> Personally, I care about a solid PCM and MIDI driver, but I don't care
> >> so much about a Line6 Editor.  If someone invests the time then I'm
> >> sure it would be doable in a couple of months.
> >>
> >
> > For me, it'd be enough to just dump all the settings, put (some of) them
> > back through some sys file, for example (or ioctl). According to the USB
> > comm, it seems it's easily doable. Editing would be nice, I saw there's
> some
> > work around that done already - but as yuo say, someone has to have time
> for
> > it... :)
>
> Dumping the device is easy on the HD300, maybe it's the same on yours.
>
> Not sure. X3 doesn't support MIDI (no midi in/out ports on the device
itself) according to the specs. But I doubt they have completely different
HW for X3 and X3 Live (which has MIDI), so the protocol could be the same -
and the USB data could be indeed some encoded MIDI messages...


The device has a MIDI dump option available in an options menu.  You
> can select whether to dump just the current patch or all patches.
>
> When you activate MIDI dump the device sends all the patches over
> MIDI.  On your computer you can use amidi(1) to save this to file.
>
> Later you use amidi(1) to send the sysex back to the device, restoring
> the patch(es).
>
> If you don't enjoy using amidi(1) I bet some of the graphical DAWs or
> MIDI tools under Linux also support storing/loading sysex dumps.
>
> I'll try to read something about this (sysex, MIDI format etc.) so I don't
bother you with basic stuff..


Anyhow, back to the audio stream. How does the data transfer work on HD300?
Is there any setup, or you just read/write the appropriate USB ports?


--
Andrej

Re: [Line6linux-devel] (no subject)

[Stefan H. <ste...@gm...>]

On Wed, May 1, 2013 at 9:33 PM, Andrej Kruták <de...@an...> wrote:
> On Wed, May 1, 2013 at 7:30 PM, Stefan Hajnoczi <ste...@gm...> wrote:
>>
>> On Wed, May 1, 2013 at 11:11 AM, Andrej Kruták <de...@an...> wrote:
>> > 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? How is the
>> > profile uploading/downloading handled with the XT?
>>
>> Userspace should support multiple devices in a data-driven way -
>> adding support for a new device should (mostly) mean populating a
>> table of MIDI messages.
>>
> So in case there's no real MIDI in the device, you expect it to be somehow
> emulated by the driver, right? But for example the volume is send from X3 as
> a float number, while in MIDI (after a short look) it seems to be just an
> unsigned char....

No, MIDI is not emulated by the driver.  In some cases the driver
spies on MIDI traffic or generates MIDI messages internally, but it
doesn't process MIDI messages and convert them into Line6-specific I/O
operations.

MIDI is extensible and you can send arbitrary data over it (may
involve a 7-bit encoding).  Line6 uses a custom MIDI mapping and
parameters can be floats, fixed-point, etc.

Can you explain what you mean regarding volume sent as a float?  Do
you have a traffic capture?

>> Don't expect anything close to the Line6 Editor working yet.
>> Personally, I care about a solid PCM and MIDI driver, but I don't care
>> so much about a Line6 Editor.  If someone invests the time then I'm
>> sure it would be doable in a couple of months.
>>
>
> For me, it'd be enough to just dump all the settings, put (some of) them
> back through some sys file, for example (or ioctl). According to the USB
> comm, it seems it's easily doable. Editing would be nice, I saw there's some
> work around that done already - but as yuo say, someone has to have time for
> it... :)

Dumping the device is easy on the HD300, maybe it's the same on yours.

The device has a MIDI dump option available in an options menu.  You
can select whether to dump just the current patch or all patches.

When you activate MIDI dump the device sends all the patches over
MIDI.  On your computer you can use amidi(1) to save this to file.

Later you use amidi(1) to send the sysex back to the device, restoring
the patch(es).

If you don't enjoy using amidi(1) I bet some of the graphical DAWs or
MIDI tools under Linux also support storing/loading sysex dumps.

Stefan

Re: [Line6linux-devel] (no subject)

[Andrej K. <de...@an...>]

On Wed, May 1, 2013 at 7:30 PM, Stefan Hajnoczi <ste...@gm...> wrote:

> On Wed, May 1, 2013 at 11:11 AM, Andrej Kruták <de...@an...> wrote:
> > 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? How is the
> > profile uploading/downloading handled with the XT?
>
> Userspace should support multiple devices in a data-driven way -
> adding support for a new device should (mostly) mean populating a
> table of MIDI messages.
>
> So in case there's no real MIDI in the device, you expect it to be somehow
emulated by the driver, right? But for example the volume is send from X3
as a float number, while in MIDI (after a short look) it seems to be just
an unsigned char....


> I can't help with specifics on your other questions because I only
> have a POD HD300 and don't know how the X3/XT work.  If you have time,
> please collect USB traffic captures of the interesting features so
> that you or someone else can implement the needed functionality.
>
> Yep, got them already - I think I saw some HD500 captures and they
resembled what I see (though just partly). If I can't put the captures to
use, I'll send them here for the future generations - it's 6 years old now,
so I wonder if there is any real user base for the device anymore (apart
from me :) ).


Don't expect anything close to the Line6 Editor working yet.
> Personally, I care about a solid PCM and MIDI driver, but I don't care
> so much about a Line6 Editor.  If someone invests the time then I'm
> sure it would be doable in a couple of months.
>
>
For me, it'd be enough to just dump all the settings, put (some of) them
back through some sys file, for example (or ioctl). According to the USB
comm, it seems it's easily doable. Editing would be nice, I saw there's
some work around that done already - but as yuo say, someone has to have
time for it... :)

Andrej

Re: [Line6linux-devel] (no subject)

[Stefan H. <ste...@gm...>]

On Wed, May 1, 2013 at 11:11 AM, Andrej Kruták <de...@an...> wrote:
> 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? How is the
> profile uploading/downloading handled with the XT?

Userspace should support multiple devices in a data-driven way -
adding support for a new device should (mostly) mean populating a
table of MIDI messages.

I can't help with specifics on your other questions because I only
have a POD HD300 and don't know how the X3/XT work.  If you have time,
please collect USB traffic captures of the interesting features so
that you or someone else can implement the needed functionality.

Don't expect anything close to the Line6 Editor working yet.
Personally, I care about a solid PCM and MIDI driver, but I don't care
so much about a Line6 Editor.  If someone invests the time then I'm
sure it would be doable in a couple of months.

Stefan

[Line6linux-devel] (no subject)

[Andrej K. <de...@an...>]

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.

I saw you did quite a rewrite in recent weeks/months, dropping most of the
code and putting it into the userspace qt tool. So, is there any
documentation for that stuff yet? 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?

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? How is the
profile uploading/downloading handled with the XT?

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?

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?


If you could give me some answers for the above... maybe we'll have the X3
support... hopefully :)

--
Best regards,

Andrej

Re: [Line6linux-devel] POD HD500

[L. A. G. <agi...@sy...>]

On Wed, Apr 17, 2013 at 05:39:55PM +0000, varomix wrote:
> Hey Sébastien
> 
> does USB audio recording works?
> I only want to be able to record, tone editing I can do in my laptop but I 
> love to record on my linux box

Hi,

I tested the driver some months ago and all I got was a system freeze :( I intend to
start working on it someday but you know, Real Life (tm) work and other
hobbies/chores keep me away of getting my hands dirty :(

If I get to work on it again, I'll post to the list my progress!

Regards,
-- 
L. Alberto Giménez
JabberID agi...@ja...
GnuPG key ID 0x3BAABDE1

Re: [Line6linux-devel] POD HD500

[varomix <va...@gm...>]

Hey Sébastien

does USB audio recording works?
I only want to be able to record, tone editing I can do in my laptop but I 
love to record on my linux box

thanks

[Line6linux-devel] Line6 POD Studio KB37

[Jesper B. <jep...@gm...>]

As a test, I changed the id of the UX1 to 0x4152 but nothing happened.
Still no lights or sounds from KB37. Then I changed the id of the UX2
to 0x4152, I could see life in my KB37. The meters light up but the needels
shows full scale. LEDs showing octave select lights all up. In Qjack I can
choose the UX2 interface and I get two inputs and two outputs but I'm unable
to get any sound from them.

Feels like it might be tricky to get KB37 to work in Linux.
I'll probably choose a different sound card or start making music with M$...

/Jeppe

[Line6linux-devel] Line6 POD Studio KB37

[Jesper B. <jep...@gm...>]

Here is the result of the "lsusb -v -d 0e41:" command.

Bus 002 Device 002: ID 0e41:4152 Line6, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0e41 Line6, Inc.
  idProduct          0x4152
  bcdDevice            0.01
  iManufacturer           1 Line 6
  iProduct                2 KB37
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          149
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              498mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x00c0  1x 192 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x00c8  1x 200 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       2
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x00b4  1x 180 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x00bc  1x 188 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       3
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0120  1x 288 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x012c  1x 300 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       4
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x010e  1x 270 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x011a  1x 282 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x87  EP 7 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

BR
Jeppe Bergvall

[Line6linux-devel] request for Line6 device ids

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

		Hi!

	As I just mentioned in my previous message, I noticed that several Line6 
devices are missing from the public list of USB vendor/product ids at 
"http://www.linux-usb.org/usb.ids". I guess it is easy to get this list 
updated, but to reduce the effort for the maintainer (and to increase the 
likelihood that the update request gets noticed :-), we should collect as much 
information as we can, and I'll send a single request then. May I ask for your 
help to complete the list in the attached file?

The attached file contains four sections:
*) the header of the original usb.ids file
*) the Line6 portion of the original usb.ids file
*) list of devices with known id, but missing from usb.ids
*) list of devices with unknown id

If you have a Line6 device with unknown id (according to this list) or a USB-
based Line6 device which is not on the list, please report its name and id to 
me (command "lsusb -d 0e41:"). Moreover, feel free to correct any errors (USB 
ids and/or product names) you find in the list.

	Thanks & kind regards,
		Markus

Re: [Line6linux-devel] Line6 POD Studio KB37

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

On Tuesday 22 January 2013 16:22:02 you wrote:
> Hi Marcus
> 
> I don't know if I'm grabbing air now, but I want to ask you if you, or if
> you know anybody, using the "Line6 POD Studio KB37" with your driver
> line6linux?  http://line6.com/podstudiokb37/
> It is supposed to be familiar with the UX1 and UX2.
> 
> I looked in your document *"Line6 Linux USB driver Version 0.9.1beta" *and
> the KB37 is not listed in the table.
> 
>  I could determine the id with the command:
> 
> *lsusb -d 0e41:*
> 
> I get.
> 
> *Bus 001 Device 004: ID 0e41:4152 Line6, Inc. *
> *
> *
> However I don't get any name at the end of the line.
That's because it is not listed in "/usr/share/usb.ids" (the file might be 
elsewhere under your Linux distribution, the original is maintained at 
http://www.linux-usb.org/usb.ids). I just noticed that the list is rather 
incomplete, I will start a request to collect the missing information in a 
separate message.

> In the document you say you can modify the arrays line6_id_table and
> line6_name_table in the file driver.c.
> 
> When I search for the driver.c file I get about 15 files. Witch one is
> active, if not all of them?
Where did you search? In case you searched in 
"https://line6linux.svn.sourceforge.net/svnroot/line6linux", then 
"driver/trunk/driver.c" is the most recent one. The version in 
"driver/branches/ux2" might also be relevant for you, but is currently quite 
experimental.

> I'm not much of a programmer but I'm willing to help collecting parameters
> and stuff to get KB37 work in Linux.
Unless the KB37 turns out to have an almost identical interface as another 
device supported by the driver, it is very hard to add support for it. The 
easiest way to find out is to just replace the id of a device you believe the 
KB37 could be similar to (e.g., the UX1) by the KB37 id (0x4152) in 
"usbdefs.h". The driver will then believe that the KB37 is actually a UX1 and 
try to communicate with it like with a UX1. The result could be anything 
between working, not working, and crashing your computer. If it's not working 
(or crashing), more effort is required to get the KB37 supported.

There is one useful piece of information which you can easily produce, namely 
the output of the command "lsusb -v -d 0e41:" (executed as root), can you 
please send this to me?

	Kind regards,
		Markus


P.S.: I forwarded this message to the mailing list for Line6 Linux stuff. 
Please consider joining the list(s) such that others can follow the 
discussion:

http://sourceforge.net/mail/?group_id=200399

Re: [Line6linux-devel] Php parser for h3e file

[jeanseb <jea...@fr...>]

Hi, you ca find last verison of the parser at
http://jeanseb.valette.free.fr

Le Fri, 18 Jan 2013 17:47:57 +0100,
Stefan Hajnoczi <ste...@gm...> a écrit :

> On Fri, Jan 18, 2013 at 3:47 PM,  <jea...@fr...> wrote:
> > You will find in PJ a test parser for h3e preset file.
> >
> > Name have to be tested as i reported them from the doc in  same
> > order (it workd for the 2 first amp and Brit J800 that i had
> > tested) ,  FX model  is a guess to be check (i will try to buil
> > preset file with != FX)this WE).
> >
> > For FX 400 effect I've include them in same order, but they may not
> > be "reserved" value, so last effect should be shift (or not).
> >
> > For the design ofa full php site, i guess, for the data model,  we
> > had to build a parent  class for file handling and children class
> > for != kind of files (hd 300, hd 400 , hd 500).
> >
> > Then a controler that produce an array  of object (amp, cab,
> > fx ...) and a viewer that parse the and display it content.
> >
> > Saving will be a matter of of choosing a format and give the array
> > to a controlller that call the good model class.
> 
> Nice start!
> 
> If you want testers throw the php file onto a server or free hosting
> and post a link on the Line6 POD forum.  I'm sure people will try
> their files and report back if something doesn't work.
> 
> If the parsing code gets more complicated it may be worth writing
> command-line tools and calling them from PHP (make them output both
> human-readable info and JSON).  I think Markus was working on this for
> previous POD generations:
> http://line6linux.svn.sourceforge.net/viewvc/line6linux/apps/trunk/toneview/tone.cpp?revision=513&view=markup
> http://line6linux.svn.sourceforge.net/viewvc/line6linux/apps/trunk/filedump_test/
> 
> Stefan