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

Re: [Line6linux-devel] Fwd: [Line6linux-user] line6 edit equivalent

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

On Thu, Jan 17, 2013 at 04:07:39PM +0800, Steve Underwood wrote:
> Hi,
> 
> It looks like the HD300 file format has a lot in common with the HD500. 
> I figured out much of the contents of the .h5e files some time ago, and 
> wrote some basic code to dump the contents of those files, or load them 
> into an HD500 using USB. Its quite a while since I had any free time to 
> work on this. My latest code can be found at 
> http://www.soft-switch.org/downloads/line6 if anyone else would like to 
> work on it.
> 

Hey Steve, have you been able to make the HD500 work on Linux? I'm doing several
tests but I have not a lot of time :(

Did the staging driver work for you?


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

[Line6linux-devel] [PATCH 1/2] staging: line6: clean up line6_pod_process_message()

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

Previous versions of the line6 driver snooped MIDI traffic in order to
make device state accessible via sysfs attributes.  This involved a lot
of logic in line6_pod_process_message() that has since been removed.

Drop unused conditionals in line6_pod_process_message() and reduce the
levels of indentation.  Only two MIDI messages are still tracked: the
POD version message on startup and monitor level changes originating
from the device.

Signed-off-by: Stefan Hajnoczi <ste...@gm...>
---
 drivers/staging/line6/pod.c | 96 +++++++++------------------------------------
 1 file changed, 19 insertions(+), 77 deletions(-)

diff --git a/drivers/staging/line6/pod.c b/drivers/staging/line6/pod.c
index ba6fed4..74898c3 100644
--- a/drivers/staging/line6/pod.c
+++ b/drivers/staging/line6/pod.c
@@ -135,85 +135,27 @@ void line6_pod_process_message(struct usb_line6_pod *pod)
 {
 	const unsigned char *buf = pod->line6.buffer_message;
 
-	/* filter messages by type */
-	switch (buf[0] & 0xf0) {
-	case LINE6_PARAM_CHANGE:
-	case LINE6_PROGRAM_CHANGE:
-	case LINE6_SYSEX_BEGIN:
-		break;		/* handle these further down */
-
-	default:
-		return;		/* ignore all others */
+	if (memcmp(buf, pod_version_header, sizeof(pod_version_header)) == 0) {
+		pod->firmware_version = buf[13] * 100 + buf[14] * 10 + buf[15];
+		pod->device_id = ((int)buf[8] << 16) | ((int)buf[9] << 8) |
+				 (int) buf[10];
+		pod_startup3(pod);
+		return;
+	}
+
+	/* Only look for sysex messages from this device */
+	if (buf[0] != (LINE6_SYSEX_BEGIN | LINE6_CHANNEL_DEVICE) &&
+	    buf[0] != (LINE6_SYSEX_BEGIN | LINE6_CHANNEL_UNKNOWN)) {
+		return;
+	}
+	if (memcmp(buf + 1, line6_midi_id, sizeof(line6_midi_id)) != 0) {
+		return;
 	}
 
-	/* process all remaining messages */
-	switch (buf[0]) {
-	case LINE6_PARAM_CHANGE | LINE6_CHANNEL_DEVICE:
-	case LINE6_PARAM_CHANGE | LINE6_CHANNEL_HOST:
-		break;
-
-	case LINE6_PROGRAM_CHANGE | LINE6_CHANNEL_DEVICE:
-	case LINE6_PROGRAM_CHANGE | LINE6_CHANNEL_HOST:
-		break;
-
-	case LINE6_SYSEX_BEGIN | LINE6_CHANNEL_DEVICE:
-	case LINE6_SYSEX_BEGIN | LINE6_CHANNEL_UNKNOWN:
-		if (memcmp(buf + 1, line6_midi_id,
-			   sizeof(line6_midi_id)) == 0) {
-			switch (buf[5]) {
-			case POD_SYSEX_DUMP:
-				break;
-
-			case POD_SYSEX_SYSTEM:{
-					short value =
-					    ((int)buf[7] << 12) | ((int)buf[8]
-								   << 8) |
-					    ((int)buf[9] << 4) | (int)buf[10];
-
-					if (buf[6] == POD_MONITOR_LEVEL)
-						pod->monitor_level = value;
-					break;
-				}
-
-			case POD_SYSEX_FINISH:
-				/* do we need to respond to this? */
-				break;
-
-			case POD_SYSEX_SAVE:
-				break;
-
-			case POD_SYSEX_STORE:
-				dev_dbg(pod->line6.ifcdev,
-					"message %02X not yet implemented\n",
-					buf[5]);
-				break;
-
-			default:
-				dev_dbg(pod->line6.ifcdev,
-					"unknown sysex message %02X\n",
-					buf[5]);
-			}
-		} else
-		    if (memcmp
-			(buf, pod_version_header,
-			 sizeof(pod_version_header)) == 0) {
-			pod->firmware_version =
-			    buf[13] * 100 + buf[14] * 10 + buf[15];
-			pod->device_id =
-			    ((int)buf[8] << 16) | ((int)buf[9] << 8) | (int)
-			    buf[10];
-			pod_startup3(pod);
-		} else
-			dev_dbg(pod->line6.ifcdev, "unknown sysex header\n");
-
-		break;
-
-	case LINE6_SYSEX_END:
-		break;
-
-	default:
-		dev_dbg(pod->line6.ifcdev, "POD: unknown message %02X\n",
-			buf[0]);
+	if (buf[5] == POD_SYSEX_SYSTEM && buf[6] == POD_MONITOR_LEVEL) {
+		short value = ((int)buf[7] << 12) | ((int)buf[8] << 8) |
+			      ((int)buf[9] << 4) | (int)buf[10];
+		pod->monitor_level = value;
 	}
 }
 
-- 
1.8.0.2

[Line6linux-devel] [PATCH 2/2] staging: line6: clean up line6_variax_process_message()

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

Previous versions of the line6 driver snooped MIDI traffic in order to
make device state accessible via sysfs attributes.  This involved a lot
of logic in line6_variax_process_message() that has since been removed.

Drop unused conditionals in line6_variax_process_message().

Signed-off-by: Stefan Hajnoczi <ste...@gm...>
---
 drivers/staging/line6/variax.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/line6/variax.c b/drivers/staging/line6/variax.c
index 4fca58f..bd0f694 100644
--- a/drivers/staging/line6/variax.c
+++ b/drivers/staging/line6/variax.c
@@ -133,13 +133,6 @@ void line6_variax_process_message(struct usb_line6_variax *variax)
 	const unsigned char *buf = variax->line6.buffer_message;
 
 	switch (buf[0]) {
-	case LINE6_PARAM_CHANGE | LINE6_CHANNEL_HOST:
-		break;
-
-	case LINE6_PROGRAM_CHANGE | LINE6_CHANNEL_DEVICE:
-	case LINE6_PROGRAM_CHANGE | LINE6_CHANNEL_HOST:
-		break;
-
 	case LINE6_RESET:
 		dev_info(variax->line6.ifcdev, "VARIAX reset\n");
 		break;
@@ -154,13 +147,6 @@ void line6_variax_process_message(struct usb_line6_variax *variax)
 			variax_startup4((unsigned long)variax);
 		}
 		break;
-
-	case LINE6_SYSEX_END:
-		break;
-
-	default:
-		dev_dbg(variax->line6.ifcdev,
-			"Variax: unknown message %02X\n", buf[0]);
 	}
 }
 
-- 
1.8.0.2

[Line6linux-devel] [PATCH 0/2] staging: line6: clean up MIDI post-processing functions

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

The line6 driver inspects fewer MIDI messages than in previous versions.  The
conditionals to match these MIDI messages were left in place.  This series
removes unused conditionals in order to make the MIDI post-processing functions
easier to read.

Applies to linux-next/master.

Stefan Hajnoczi (2):
  staging: line6: clean up line6_pod_process_message()
  staging: line6: clean up line6_variax_process_message()

 drivers/staging/line6/pod.c    | 96 +++++++++---------------------------------
 drivers/staging/line6/variax.c | 14 ------
 2 files changed, 19 insertions(+), 91 deletions(-)

-- 
1.8.0.2

[Line6linux-devel] [PATCH] staging: line6: drop CONFIG_LINE6_USB_DUMP_PCM

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

The CONFIG_LINE6_USB_DUMP_PCM config option prints a hexdump of PCM
audio data as URBs are sent and received.  The usbmon feature should be
used instead of manually dumping PCM URBs.  There are a few advantages
to using usbmon:

 * Can be turned on/off at runtime
 * Provides full USB-level traffic
 * tcpdump and wireshark support for powerful analysis
 * No driver-specific code is required

This is the last user of line6_write_hexdump() so we drop it too.

Signed-off-by: Stefan Hajnoczi <ste...@gm...>
---
Applies on linux-next/master.

 drivers/staging/line6/Kconfig    | 10 ----------
 drivers/staging/line6/capture.c  | 10 ----------
 drivers/staging/line6/driver.c   | 41 ----------------------------------------
 drivers/staging/line6/driver.h   |  9 ---------
 drivers/staging/line6/playback.c |  9 ---------
 5 files changed, 79 deletions(-)

diff --git a/drivers/staging/line6/Kconfig b/drivers/staging/line6/Kconfig
index b635436..4f1219b 100644
--- a/drivers/staging/line6/Kconfig
+++ b/drivers/staging/line6/Kconfig
@@ -23,16 +23,6 @@ menuconfig LINE6_USB
 
 if LINE6_USB
 
-config LINE6_USB_DUMP_PCM
-	bool "dump PCM data"
-	default n
-	help
-	  Say Y here to write PCM data sent to and received from Line6
-	  devices to the syslog. This will produce a huge amount of
-	  syslog data during playback and capture.
-
-	  If unsure, say N.
-
 config LINE6_USB_IMPULSE_RESPONSE
 	bool "measure impulse response"
 	default n
diff --git a/drivers/staging/line6/capture.c b/drivers/staging/line6/capture.c
index 389c41f..f8316b7 100644
--- a/drivers/staging/line6/capture.c
+++ b/drivers/staging/line6/capture.c
@@ -216,16 +216,6 @@ static void audio_in_callback(struct urb *urb)
 		if (urb == line6pcm->urb_audio_in[index])
 			break;
 
-#ifdef CONFIG_LINE6_USB_DUMP_PCM
-	for (i = 0; i < LINE6_ISO_PACKETS; ++i) {
-		struct usb_iso_packet_descriptor *fout =
-		    &urb->iso_frame_desc[i];
-		line6_write_hexdump(line6pcm->line6, 'C',
-				    urb->transfer_buffer + fout->offset,
-				    fout->length);
-	}
-#endif
-
 	spin_lock_irqsave(&line6pcm->lock_audio_in, flags);
 
 	for (i = 0; i < LINE6_ISO_PACKETS; ++i) {
diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 1b05633..9f9a21a 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -135,47 +135,6 @@ static void line6_stop_listen(struct usb_line6 *line6)
 	usb_kill_urb(line6->urb_listen);
 }
 
-#ifdef CONFIG_LINE6_USB_DUMP_ANY
-/*
-	Write hexdump to syslog.
-*/
-void line6_write_hexdump(struct usb_line6 *line6, char dir,
-			 const unsigned char *buffer, int size)
-{
-	static const int BYTES_PER_LINE = 8;
-	char hexdump[100];
-	char asc[BYTES_PER_LINE + 1];
-	int i, j;
-
-	for (i = 0; i < size; i += BYTES_PER_LINE) {
-		int hexdumpsize = sizeof(hexdump);
-		char *p = hexdump;
-		int n = min(size - i, BYTES_PER_LINE);
-		asc[n] = 0;
-
-		for (j = 0; j < BYTES_PER_LINE; ++j) {
-			int bytes;
-
-			if (j < n) {
-				unsigned char val = buffer[i + j];
-				bytes = snprintf(p, hexdumpsize, " %02X", val);
-				asc[j] = ((val >= 0x20)
-					  && (val < 0x7f)) ? val : '.';
-			} else
-				bytes = snprintf(p, hexdumpsize, "   ");
-
-			if (bytes > hexdumpsize)
-				break;	/* buffer overflow */
-
-			p += bytes;
-			hexdumpsize -= bytes;
-		}
-
-		dev_info(line6->ifcdev, "%c%04X:%s %s\n", dir, i, hexdump, asc);
-	}
-}
-#endif
-
 /*
 	Send raw message in pieces of wMaxPacketSize bytes.
 */
diff --git a/drivers/staging/line6/driver.h b/drivers/staging/line6/driver.h
index 2e0f134..a8341f9 100644
--- a/drivers/staging/line6/driver.h
+++ b/drivers/staging/line6/driver.h
@@ -20,10 +20,6 @@
 
 #define DRIVER_NAME "line6usb"
 
-#if defined(CONFIG_LINE6_USB_DUMP_PCM)
-#define CONFIG_LINE6_USB_DUMP_ANY
-#endif
-
 #define LINE6_TIMEOUT 1
 #define LINE6_BUFSIZE_LISTEN 32
 #define LINE6_MESSAGE_MAXLEN 256
@@ -219,9 +215,4 @@ extern int line6_version_request_async(struct usb_line6 *line6);
 extern int line6_write_data(struct usb_line6 *line6, int address, void *data,
 			    size_t datalen);
 
-#ifdef CONFIG_LINE6_USB_DUMP_ANY
-extern void line6_write_hexdump(struct usb_line6 *line6, char dir,
-				const unsigned char *buffer, int size);
-#endif
-
 #endif
diff --git a/drivers/staging/line6/playback.c b/drivers/staging/line6/playback.c
index 4cf23af..f9135c7 100644
--- a/drivers/staging/line6/playback.c
+++ b/drivers/staging/line6/playback.c
@@ -264,15 +264,6 @@ static int submit_audio_out_urb(struct snd_line6_pcm *line6pcm)
 		}
 #endif
 	}
-#ifdef CONFIG_LINE6_USB_DUMP_PCM
-	for (i = 0; i < LINE6_ISO_PACKETS; ++i) {
-		struct usb_iso_packet_descriptor *fout =
-		    &urb_out->iso_frame_desc[i];
-		line6_write_hexdump(line6pcm->line6, 'P',
-				    urb_out->transfer_buffer + fout->offset,
-				    fout->length);
-	}
-#endif
 
 	ret = usb_submit_urb(urb_out, GFP_ATOMIC);
 
-- 
1.8.0.2

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

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

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

Re: [Line6linux-devel] Fwd: [Line6linux-user] line6 edit equivalent

[Steve U. <st...@co...>]

Hi,

It looks like the HD300 file format has a lot in common with the HD500. 
I figured out much of the contents of the .h5e files some time ago, and 
wrote some basic code to dump the contents of those files, or load them 
into an HD500 using USB. Its quite a while since I had any free time to 
work on this. My latest code can be found at 
http://www.soft-switch.org/downloads/line6 if anyone else would like to 
work on it.

Regards,
Steve


On 01/17/2013 03:26 PM, jea...@fr... wrote:
>
>
>
>
> Hi
>
> here my first notes about HD 300 :
>
> First file format (h3e)
> ----------
>
> all value are hex
>
> Byte offset        Field                        Value
> --
> 0 - 4                File Sig                "H3EP"
> 4 -27                Unknown
> 28 -37                Name                        Ascii codes
> 38                ??                        always 0 ?
> 39                Amps on ?                80 for amp on, 81 Amp on + 
> gate, C0 Amp on + wha on
> 3A
> 3B                Amps code ?                Set to 0C in Brit 800 
> file, 00 in BlackFace one
> 3C
> 3D                Cab code ?                Set to 12 for brit 800 no 
> cab, 0D in brit 800 +screamer ,  00 in BlackFace one
> 3E - 3F                Drive                        Value 00 for 0, 40 
> 00 for 50%, 7F FF for 100%
> 40 -41                 Bass                        Value 00 for 0, 40 
> 00 for 50%, 7F FF for 100%
> 42 -43                Mid                        Value 00 for 0, 40 00 
> for 50%, 7F FF for 100%
> 44 -45                Treble                        Value 00 for 0, 40 
> 00 for 50%, 7F FF for 100%
> 46 -47                CH Volume                Value 00 for 0, 40 00 
> for 50%, 7F FF for 100%
> 48 -49                 Presence                Value 00 for 0, 40 00 
> for 50%, 7F FF for 100%
> 4A -4B                ??
> 4C                Mic code ?                04 for 4308 Ribbon ?
> 4D -4F
> 50 -51                 Bypass Volume                Value 00 for 0, 40 
> 85  for 50%, 7F FF for 100%
> 52 -53
> 54 -55                ???
> 5C -65                 ????                Change from all 00 to 3F FF 
> repeated 5 time if when changing wha to weeper, change when editing 
> bias setting
> 66 -71                 ???
> 72                FX1 code ?                Set 04 When screamer is 
> set on and routed pre, 06 when on and set post, 0 if FX2 off
> 73 -79                FX 1 param ?
> 74                 FX2 code ?                Set to 04 when Analog 
> Chorus is on, 0 if FX3 off
> 75 -81                FX2 param ?
> 82                FX3 code ?                Set to 04 when Digital 
> Delay is on, 0 if FX3 off
> 83 -C7                Unknown
>
>
> --------
>
> then midi code i've found :
>
> Mode button :
> To effect mode :
> F0 00 01 0C 14 00 63 00 04 15 00 00 02 F7
>
> To Preset mode :
> F0 00 01 0C 14 00 63 00 04 15 00 00 00 F7
>
> To looper mode
> F0 00 01 0C 14 00 63 00 04 15 00 00 01 F7
>
> Preset Mode
> A switch
> B0 00 00
> B0 20 00
> C0 04
> B0 07 7F
>
> B switch :
> B0 00 00
> B0 20 00
> C0 05
> B0 07 7F
>
> C switch :
> B0 00 00
> B0 20 00
> C0 06
> B0 07 7F
>
>
> D switch :
> B0 00 00
> B0 20 00
> C0 07
> B0 07 7F
>
>
> FX mode :
>
> Amp off then on
> F0 00 01 0C 14 00 63 00 02 14 00 00 00 F7
> F0 00 01 0C 14 00 63 00 02 14 00 00 01 F7
>
> Fx1 off then on
> F0 00 01 0C 14 00 63 00 10 03 00 00 00 F7
> F0 00 01 0C 14 00 63 00 10 03 00 00 01 F7
>
> Fx 2 on then off
> F0 00 01 0C 14 00 63 00 11 03 00 00 01 F7
> F0 00 01 0C 14 00 63 00 11 03 00 00 00 F7
>
> Fx 3 on then off
> F0 00 01 0C 14 00 63 00 12 03 00 00 01 F7
> F0 00 01 0C 14 00 63 00 12 03 00 00 00 F7
>
> Tap 3 times
> F0 00 01 0C 14 00 63 00 02 06 07 56 55 F7
> F0 00 01 0C 14 00 63 00 02 06 08 07 27 F7
>
> Tap 4 times
> F0 00 01 0C 14 00 63 00 02 06 09 0E 02 F7
> F0 00 01 0C 14 00 63 00 02 06 08 2E 18 F7
> F0 00 01 0C 14 00 63 00 02 06 08 2E 18 F7
>
>
> Vol pedal up then down
>
> B0 07 7F
> B0 07 7E
> B0 07 7C
> B0 07 79
> B0 07 77
> B0 07 73
> B0 07 6F
> B0 07 6B
> B0 07 66
> B0 07 62
> B0 07 5D
> B0 07 59
> B0 07 53
> B0 07 4E
> B0 07 49
> B0 07 44
> B0 07 3F
> B0 07 39
> B0 07 33
> B0 07 2C
> B0 07 25
> B0 07 1D
> B0 07 14
> B0 07 0C
> B0 07 02
> B0 07 00
> B0 07 04
> B0 07 0B
> B0 07 11
> B0 07 19
> B0 07 20
> B0 07 27
> B0 07 2D
> B0 07 33
> B0 07 3A
> B0 07 40
> B0 07 45
> B0 07 4A
> B0 07 4E
> B0 07 53
> B0 07 58
> B0 07 5D
> B0 07 61
> B0 07 65
> B0 07 6B
> B0 07 70
> B0 07 74
> B0 07 78
> B0 07 7C
> B0 07 7F
>
>
> Amp change :
> F0 00 01 0C 14 00 63 00 00 0A 00 00 06 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 07 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 08 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 09 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 0A F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 0B F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 0C F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 0D F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 0E F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 0F F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 10 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 11 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 12 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 13 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 14 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 15 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 16 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 17 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 18 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 19 F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 1A F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 1B F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 1C F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 1D F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 1E F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 1E F7
> F0 00 01 0C 14 00 63 00 00 0A 00 00 1E F7
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
>
>
> _______________________________________________
> Line6linux-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/line6linux-devel

[Line6linux-devel] Fwd: [Line6linux-user] line6 edit equivalent

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

Hi 

here my first notes about HD 300 : 

First file format (h3e) 
---------- 

all value are hex 

Byte offset Field Value 
-- 
0 - 4 File Sig "H3EP" 
4 -27 Unknown 
28 -37 Name Ascii codes 
38 ?? always 0 ? 
39 Amps on ? 80 for amp on, 81 Amp on + gate, C0 Amp on + wha on 
3A 
3B Amps code ? Set to 0C in Brit 800 file, 00 in BlackFace one 
3C 
3D Cab code ? Set to 12 for brit 800 no cab, 0D in brit 800 +screamer , 00 in BlackFace one 
3E - 3F Drive Value 00 for 0, 40 00 for 50%, 7F FF for 100% 
40 -41 Bass Value 00 for 0, 40 00 for 50%, 7F FF for 100% 
42 -43 Mid Value 00 for 0, 40 00 for 50%, 7F FF for 100% 
44 -45 Treble Value 00 for 0, 40 00 for 50%, 7F FF for 100% 
46 -47 CH Volume Value 00 for 0, 40 00 for 50%, 7F FF for 100% 
48 -49 Presence Value 00 for 0, 40 00 for 50%, 7F FF for 100% 
4A -4B ?? 
4C Mic code ? 04 for 4308 Ribbon ? 
4D -4F 
50 -51 Bypass Volume Value 00 for 0, 40 85 for 50%, 7F FF for 100% 
52 -53 
54 -55 ??? 
5C -65 ???? Change from all 00 to 3F FF repeated 5 time if when changing wha to weeper, change when editing bias setting 
66 -71 ??? 
72 FX1 code ? Set 04 When screamer is set on and routed pre, 06 when on and set post, 0 if FX2 off 
73 -79 FX 1 param ? 
74 FX2 code ? Set to 04 when Analog Chorus is on, 0 if FX3 off 
75 -81 FX2 param ? 
82 FX3 code ? Set to 04 when Digital Delay is on, 0 if FX3 off 
83 -C7 Unknown 


-------- 

then midi code i've found : 

Mode button : 
To effect mode : 
F0 00 01 0C 14 00 63 00 04 15 00 00 02 F7 

To Preset mode : 
F0 00 01 0C 14 00 63 00 04 15 00 00 00 F7 

To looper mode 
F0 00 01 0C 14 00 63 00 04 15 00 00 01 F7 

Preset Mode 
A switch 
B0 00 00 
B0 20 00 
C0 04 
B0 07 7F 

B switch : 
B0 00 00 
B0 20 00 
C0 05 
B0 07 7F 

C switch : 
B0 00 00 
B0 20 00 
C0 06 
B0 07 7F 


D switch : 
B0 00 00 
B0 20 00 
C0 07 
B0 07 7F 


FX mode : 

Amp off then on 
F0 00 01 0C 14 00 63 00 02 14 00 00 00 F7 
F0 00 01 0C 14 00 63 00 02 14 00 00 01 F7 

Fx1 off then on 
F0 00 01 0C 14 00 63 00 10 03 00 00 00 F7 
F0 00 01 0C 14 00 63 00 10 03 00 00 01 F7 

Fx 2 on then off 
F0 00 01 0C 14 00 63 00 11 03 00 00 01 F7 
F0 00 01 0C 14 00 63 00 11 03 00 00 00 F7 

Fx 3 on then off 
F0 00 01 0C 14 00 63 00 12 03 00 00 01 F7 
F0 00 01 0C 14 00 63 00 12 03 00 00 00 F7 

Tap 3 times 
F0 00 01 0C 14 00 63 00 02 06 07 56 55 F7 
F0 00 01 0C 14 00 63 00 02 06 08 07 27 F7 

Tap 4 times 
F0 00 01 0C 14 00 63 00 02 06 09 0E 02 F7 
F0 00 01 0C 14 00 63 00 02 06 08 2E 18 F7 
F0 00 01 0C 14 00 63 00 02 06 08 2E 18 F7 


Vol pedal up then down 

B0 07 7F 
B0 07 7E 
B0 07 7C 
B0 07 79 
B0 07 77 
B0 07 73 
B0 07 6F 
B0 07 6B 
B0 07 66 
B0 07 62 
B0 07 5D 
B0 07 59 
B0 07 53 
B0 07 4E 
B0 07 49 
B0 07 44 
B0 07 3F 
B0 07 39 
B0 07 33 
B0 07 2C 
B0 07 25 
B0 07 1D 
B0 07 14 
B0 07 0C 
B0 07 02 
B0 07 00 
B0 07 04 
B0 07 0B 
B0 07 11 
B0 07 19 
B0 07 20 
B0 07 27 
B0 07 2D 
B0 07 33 
B0 07 3A 
B0 07 40 
B0 07 45 
B0 07 4A 
B0 07 4E 
B0 07 53 
B0 07 58 
B0 07 5D 
B0 07 61 
B0 07 65 
B0 07 6B 
B0 07 70 
B0 07 74 
B0 07 78 
B0 07 7C 
B0 07 7F 


Amp change : 
F0 00 01 0C 14 00 63 00 00 0A 00 00 06 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 07 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 08 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 09 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 0A F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 0B F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 0C F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 0D F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 0E F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 0F F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 10 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 11 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 12 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 13 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 14 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 15 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 16 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 17 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 18 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 19 F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 1A F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 1B F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 1C F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 1D F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 1E F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 1E F7 
F0 00 01 0C 14 00 63 00 00 0A 00 00 1E F7 

[Line6linux-devel] [PATCH 6/6] staging: line6: avoid CamelCase POD_* enums in pod.c

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

Fix the following checkpatch.pl warnings:

  WARNING: Avoid CamelCase: <POD_monitor_level>
  #4512: FILE: staging/line6/pod.c:41:
  +       POD_monitor_level  = 0x04,

  WARNING: Avoid CamelCase: <POD_system_invalid>
  #4513: FILE: staging/line6/pod.c:42:
  +       POD_system_invalid = 0x10000

Signed-off-by: Stefan Hajnoczi <ste...@gm...>
---
 drivers/staging/line6/pod.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/line6/pod.c b/drivers/staging/line6/pod.c
index 1a11906..ba6fed4 100644
--- a/drivers/staging/line6/pod.c
+++ b/drivers/staging/line6/pod.c
@@ -40,8 +40,8 @@ enum {
 };
 
 enum {
-	POD_monitor_level  = 0x04,
-	POD_system_invalid = 0x10000
+	POD_MONITOR_LEVEL  = 0x04,
+	POD_SYSTEM_INVALID = 0x10000
 };
 
 /* *INDENT-ON* */
@@ -170,7 +170,7 @@ void line6_pod_process_message(struct usb_line6_pod *pod)
 								   << 8) |
 					    ((int)buf[9] << 4) | (int)buf[10];
 
-					if (buf[6] == POD_monitor_level)
+					if (buf[6] == POD_MONITOR_LEVEL)
 						pod->monitor_level = value;
 					break;
 				}
@@ -372,7 +372,7 @@ static int snd_pod_control_monitor_put(struct snd_kcontrol *kcontrol,
 
 	pod->monitor_level = ucontrol->value.integer.value[0];
 	pod_set_system_param_int(pod, ucontrol->value.integer.value[0],
-				 POD_monitor_level);
+				 POD_MONITOR_LEVEL);
 	return 1;
 }
 
@@ -463,7 +463,7 @@ static int pod_try_init(struct usb_interface *interface,
 	 */
 
 	if (pod->line6.properties->capabilities & LINE6_BIT_CONTROL) {
-		pod->monitor_level = POD_system_invalid;
+		pod->monitor_level = POD_SYSTEM_INVALID;
 
 		/* initiate startup procedure: */
 		pod_startup1(pod);
-- 
1.8.0.2

[Line6linux-devel] [PATCH 5/6] staging: line6: drop ToneportSourceInfo CamelCase name

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

Fix the following checkpatch.pl warning:

  WARNING: Avoid CamelCase: <ToneportSourceInfo>
  #5383: FILE: staging/line6/toneport.c:90:
  +struct ToneportSourceInfo {

Since the struct is only used to define the global
toneport_source_info[] table, I have chosen to make the struct
anonymous and part of the table definition.

Signed-off-by: Stefan Hajnoczi <ste...@gm...>
---
 drivers/staging/line6/toneport.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/line6/toneport.c b/drivers/staging/line6/toneport.c
index a529dd3..2f44d56 100644
--- a/drivers/staging/line6/toneport.c
+++ b/drivers/staging/line6/toneport.c
@@ -87,12 +87,10 @@ static struct line6_pcm_properties toneport_pcm_properties = {
 static int led_red = 0x00;
 static int led_green = 0x26;
 
-struct ToneportSourceInfo {
+static const struct {
 	const char *name;
 	int code;
-};
-
-static const struct ToneportSourceInfo toneport_source_info[] = {
+} toneport_source_info[] = {
 	{"Microphone", 0x0a01},
 	{"Line", 0x0801},
 	{"Instrument", 0x0b01},
-- 
1.8.0.2

[Line6linux-devel] [PATCH 4/6] staging: line6: wrap lines to 80 chars in pod.c

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

Fix the following checkpatch.pl warnings:

  WARNING: line over 80 characters
  #4508: FILE: staging/line6/pod.c:37:
  +       /* POD_SYSEX_DUMPMEM2  = 0x76 */   /* dumps entire internal memory of PODxt Pro */

  WARNING: line over 80 characters
  #4630: FILE: staging/line6/pod.c:159:
  +               if (memcmp(buf + 1, line6_midi_id, sizeof(line6_midi_id)) == 0) {

Signed-off-by: Stefan Hajnoczi <ste...@gm...>
---
 drivers/staging/line6/pod.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/line6/pod.c b/drivers/staging/line6/pod.c
index e542540..1a11906 100644
--- a/drivers/staging/line6/pod.c
+++ b/drivers/staging/line6/pod.c
@@ -34,7 +34,9 @@ enum {
 	POD_SYSEX_DUMPMEM   = 0x73,
 	POD_SYSEX_DUMP      = 0x74,
 	POD_SYSEX_DUMPREQ   = 0x75
-	/* POD_SYSEX_DUMPMEM2  = 0x76 */   /* dumps entire internal memory of PODxt Pro */
+
+	/* dumps entire internal memory of PODxt Pro */
+	/* POD_SYSEX_DUMPMEM2  = 0x76 */
 };
 
 enum {
@@ -156,7 +158,8 @@ void line6_pod_process_message(struct usb_line6_pod *pod)
 
 	case LINE6_SYSEX_BEGIN | LINE6_CHANNEL_DEVICE:
 	case LINE6_SYSEX_BEGIN | LINE6_CHANNEL_UNKNOWN:
-		if (memcmp(buf + 1, line6_midi_id, sizeof(line6_midi_id)) == 0) {
+		if (memcmp(buf + 1, line6_midi_id,
+			   sizeof(line6_midi_id)) == 0) {
 			switch (buf[5]) {
 			case POD_SYSEX_DUMP:
 				break;
-- 
1.8.0.2

[Line6linux-devel] [PATCH 3/6] staging: line6: use pr_err() instead of printk(KERN_ERR, ...)

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

Fix the following checkpatch.pl warning:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  to printk(KERN_ERR ...
  #1861: FILE: staging/line6/driver.h:56:
  +       printk(KERN_ERR "line6usb driver bug: missing case in %s:%d\n", \

Signed-off-by: Stefan Hajnoczi <ste...@gm...>
---
 drivers/staging/line6/driver.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/line6/driver.h b/drivers/staging/line6/driver.h
index 1dd768c2..2e0f134 100644
--- a/drivers/staging/line6/driver.h
+++ b/drivers/staging/line6/driver.h
@@ -53,7 +53,7 @@
 #define LINE6_CHANNEL_MASK 0x0f
 
 #define MISSING_CASE	\
-	printk(KERN_ERR "line6usb driver bug: missing case in %s:%d\n", \
+	pr_err("line6usb driver bug: missing case in %s:%d\n", \
 		__FILE__, __LINE__)
 
 #define CHECK_RETURN(x)		\
-- 
1.8.0.2

[Line6linux-devel] [PATCH 1/6] staging: line6: rename MidiBuffer to avoid CamelCase

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

Fix checkpatch.pl warnings related to MidiBuffer:

  WARNING: Avoid CamelCase: <MidiBuffer>
  #947: FILE: staging/line6/driver.c:363:
  +       struct MidiBuffer *mb = &line6->line6midi->midibuf_in;

Rename MidiBuffer to midi_buffer.

Note that "midibuf" would be another good name but sound/oss/midibuf.c
already uses it for a different concept.  Avoid possible confusion by
using "midi_buffer" instead.

Signed-off-by: Stefan Hajnoczi <ste...@gm...>
---
 drivers/staging/line6/driver.c  |  2 +-
 drivers/staging/line6/midi.c    |  2 +-
 drivers/staging/line6/midi.h    |  4 ++--
 drivers/staging/line6/midibuf.c | 25 +++++++++++++------------
 drivers/staging/line6/midibuf.h | 22 +++++++++++-----------
 5 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index ecb461e..96cfbc9 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -360,7 +360,7 @@ char *line6_alloc_sysex_buffer(struct usb_line6 *line6, int code1, int code2,
 static void line6_data_received(struct urb *urb)
 {
 	struct usb_line6 *line6 = (struct usb_line6 *)urb->context;
-	struct MidiBuffer *mb = &line6->line6midi->midibuf_in;
+	struct midi_buffer *mb = &line6->line6midi->midibuf_in;
 	int done;
 
 	if (urb->status == -ESHUTDOWN)
diff --git a/drivers/staging/line6/midi.c b/drivers/staging/line6/midi.c
index 6982eca..e3f9a53 100644
--- a/drivers/staging/line6/midi.c
+++ b/drivers/staging/line6/midi.c
@@ -45,7 +45,7 @@ static void line6_midi_transmit(struct snd_rawmidi_substream *substream)
 	struct usb_line6 *line6 =
 	    line6_rawmidi_substream_midi(substream)->line6;
 	struct snd_line6_midi *line6midi = line6->line6midi;
-	struct MidiBuffer *mb = &line6midi->midibuf_out;
+	struct midi_buffer *mb = &line6midi->midibuf_out;
 	unsigned long flags;
 	unsigned char chunk[line6->max_packet_size];
 	int req, done;
diff --git a/drivers/staging/line6/midi.h b/drivers/staging/line6/midi.h
index 19dabd5..78f903f 100644
--- a/drivers/staging/line6/midi.h
+++ b/drivers/staging/line6/midi.h
@@ -57,12 +57,12 @@ struct snd_line6_midi {
 	/**
 		 Buffer for incoming MIDI stream.
 	*/
-	struct MidiBuffer midibuf_in;
+	struct midi_buffer midibuf_in;
 
 	/**
 		 Buffer for outgoing MIDI stream.
 	*/
-	struct MidiBuffer midibuf_out;
+	struct midi_buffer midibuf_out;
 };
 
 extern int line6_init_midi(struct usb_line6 *line6);
diff --git a/drivers/staging/line6/midibuf.c b/drivers/staging/line6/midibuf.c
index 968e0de..f0adb7b 100644
--- a/drivers/staging/line6/midibuf.c
+++ b/drivers/staging/line6/midibuf.c
@@ -33,23 +33,23 @@ static int midibuf_message_length(unsigned char code)
 	}
 }
 
-static int midibuf_is_empty(struct MidiBuffer *this)
+static int midibuf_is_empty(struct midi_buffer *this)
 {
 	return (this->pos_read == this->pos_write) && !this->full;
 }
 
-static int midibuf_is_full(struct MidiBuffer *this)
+static int midibuf_is_full(struct midi_buffer *this)
 {
 	return this->full;
 }
 
-void line6_midibuf_reset(struct MidiBuffer *this)
+void line6_midibuf_reset(struct midi_buffer *this)
 {
 	this->pos_read = this->pos_write = this->full = 0;
 	this->command_prev = -1;
 }
 
-int line6_midibuf_init(struct MidiBuffer *this, int size, int split)
+int line6_midibuf_init(struct midi_buffer *this, int size, int split)
 {
 	this->buf = kmalloc(size, GFP_KERNEL);
 
@@ -62,14 +62,14 @@ int line6_midibuf_init(struct MidiBuffer *this, int size, int split)
 	return 0;
 }
 
-void line6_midibuf_status(struct MidiBuffer *this)
+void line6_midibuf_status(struct midi_buffer *this)
 {
 	pr_debug("midibuf size=%d split=%d pos_read=%d pos_write=%d full=%d command_prev=%02x\n",
 		 this->size, this->split, this->pos_read, this->pos_write,
 		 this->full, this->command_prev);
 }
 
-int line6_midibuf_bytes_free(struct MidiBuffer *this)
+int line6_midibuf_bytes_free(struct midi_buffer *this)
 {
 	return
 	    midibuf_is_full(this) ?
@@ -78,7 +78,7 @@ int line6_midibuf_bytes_free(struct MidiBuffer *this)
 	    1;
 }
 
-int line6_midibuf_bytes_used(struct MidiBuffer *this)
+int line6_midibuf_bytes_used(struct midi_buffer *this)
 {
 	return
 	    midibuf_is_empty(this) ?
@@ -87,7 +87,7 @@ int line6_midibuf_bytes_used(struct MidiBuffer *this)
 	    1;
 }
 
-int line6_midibuf_write(struct MidiBuffer *this, unsigned char *data,
+int line6_midibuf_write(struct midi_buffer *this, unsigned char *data,
 			int length)
 {
 	int bytes_free;
@@ -130,7 +130,8 @@ int line6_midibuf_write(struct MidiBuffer *this, unsigned char *data,
 	return length + skip_active_sense;
 }
 
-int line6_midibuf_read(struct MidiBuffer *this, unsigned char *data, int length)
+int line6_midibuf_read(struct midi_buffer *this, unsigned char *data,
+		       int length)
 {
 	int bytes_used;
 	int length1, length2;
@@ -234,7 +235,7 @@ int line6_midibuf_read(struct MidiBuffer *this, unsigned char *data, int length)
 	return length + repeat;
 }
 
-int line6_midibuf_ignore(struct MidiBuffer *this, int length)
+int line6_midibuf_ignore(struct midi_buffer *this, int length)
 {
 	int bytes_used = line6_midibuf_bytes_used(this);
 
@@ -246,7 +247,7 @@ int line6_midibuf_ignore(struct MidiBuffer *this, int length)
 	return length;
 }
 
-int line6_midibuf_skip_message(struct MidiBuffer *this, unsigned short mask)
+int line6_midibuf_skip_message(struct midi_buffer *this, unsigned short mask)
 {
 	int cmd = this->command_prev;
 
@@ -257,7 +258,7 @@ int line6_midibuf_skip_message(struct MidiBuffer *this, unsigned short mask)
 	return 0;
 }
 
-void line6_midibuf_destroy(struct MidiBuffer *this)
+void line6_midibuf_destroy(struct midi_buffer *this)
 {
 	kfree(this->buf);
 	this->buf = NULL;
diff --git a/drivers/staging/line6/midibuf.h b/drivers/staging/line6/midibuf.h
index 444cb3a..707482b 100644
--- a/drivers/staging/line6/midibuf.h
+++ b/drivers/staging/line6/midibuf.h
@@ -12,7 +12,7 @@
 #ifndef MIDIBUF_H
 #define MIDIBUF_H
 
-struct MidiBuffer {
+struct midi_buffer {
 	unsigned char *buf;
 	int size;
 	int split;
@@ -21,18 +21,18 @@ struct MidiBuffer {
 	int command_prev;
 };
 
-extern int line6_midibuf_bytes_used(struct MidiBuffer *mb);
-extern int line6_midibuf_bytes_free(struct MidiBuffer *mb);
-extern void line6_midibuf_destroy(struct MidiBuffer *mb);
-extern int line6_midibuf_ignore(struct MidiBuffer *mb, int length);
-extern int line6_midibuf_init(struct MidiBuffer *mb, int size, int split);
-extern int line6_midibuf_read(struct MidiBuffer *mb, unsigned char *data,
+extern int line6_midibuf_bytes_used(struct midi_buffer *mb);
+extern int line6_midibuf_bytes_free(struct midi_buffer *mb);
+extern void line6_midibuf_destroy(struct midi_buffer *mb);
+extern int line6_midibuf_ignore(struct midi_buffer *mb, int length);
+extern int line6_midibuf_init(struct midi_buffer *mb, int size, int split);
+extern int line6_midibuf_read(struct midi_buffer *mb, unsigned char *data,
 			      int length);
-extern void line6_midibuf_reset(struct MidiBuffer *mb);
-extern int line6_midibuf_skip_message(struct MidiBuffer *mb,
+extern void line6_midibuf_reset(struct midi_buffer *mb);
+extern int line6_midibuf_skip_message(struct midi_buffer *mb,
 				      unsigned short mask);
-extern void line6_midibuf_status(struct MidiBuffer *mb);
-extern int line6_midibuf_write(struct MidiBuffer *mb, unsigned char *data,
+extern void line6_midibuf_status(struct midi_buffer *mb);
+extern int line6_midibuf_write(struct midi_buffer *mb, unsigned char *data,
 			       int length);
 
 #endif
-- 
1.8.0.2

[Line6linux-devel] [PATCH 2/6] staging: line6: wrap comment to 80 chars in driver.c

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

Fix the following checkpatch.pl warning:

  WARNING: line over 80 characters
  #1107: FILE: staging/line6/driver.c:523:
  +       /* Wait for data length. We'll get a couple of 0xff until length arrives. */

Signed-off-by: Stefan Hajnoczi <ste...@gm...>
---
 drivers/staging/line6/driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 96cfbc9..1b05633 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -520,7 +520,7 @@ int line6_read_data(struct usb_line6 *line6, int address, void *data,
 		return ret;
 	}
 
-	/* Wait for data length. We'll get a couple of 0xff until length arrives. */
+	/* Wait for data length. We'll get 0xff until length arrives. */
 	do {
 		ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67,
 				      USB_TYPE_VENDOR | USB_RECIP_DEVICE |
-- 
1.8.0.2

[Line6linux-devel] [PATCH 0/6] staging: line6: more checkpatch.pl warnings fixes

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

This series addresses the remaining checkpatch.pl warnings that are easy to
fix.  This takes the line6 driver another step closer to getting merged as an
ALSA driver.

Stefan Hajnoczi (6):
  staging: line6: rename MidiBuffer to avoid CamelCase
  staging: line6: wrap comment to 80 chars in driver.c
  staging: line6: use pr_err() instead of printk(KERN_ERR, ...)
  staging: line6: wrap lines to 80 chars in pod.c
  staging: line6: drop ToneportSourceInfo CamelCase name
  staging: line6: avoid CamelCase POD_* enums in pod.c

 drivers/staging/line6/driver.c   |  4 ++--
 drivers/staging/line6/driver.h   |  2 +-
 drivers/staging/line6/midi.c     |  2 +-
 drivers/staging/line6/midi.h     |  4 ++--
 drivers/staging/line6/midibuf.c  | 25 +++++++++++++------------
 drivers/staging/line6/midibuf.h  | 22 +++++++++++-----------
 drivers/staging/line6/pod.c      | 17 ++++++++++-------
 drivers/staging/line6/toneport.c |  6 ++----
 8 files changed, 42 insertions(+), 40 deletions(-)

-- 
1.8.0.2

[Line6linux-devel] Which version for HD300

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

Hi, 


I'm looking for what line 6 POD HD 300 driver, compatible with debian
wheezy  (kernel 3.2.0) or squeeze (kernel 2.6.32) ?

I've tried to compile last trunk but module isn't called when the card
plugged.

at compile time there is this warning :
------
/home/jeanseb/line6linux/driver/trunk/driver.c:1284:1: warning: data
definition has no type or storage class [enabled by
default] /home/jeanseb/line6linux/driver/trunk/driver.c:1284:1:
warning: type defaults to ‘int’ in declaration of
‘module_usb_driver’ [-Wimplicit-int] /home/jeanseb/line6linux/driver/trunk/driver.c:1284:1:
warning: parameter names (without types) in function declaration
[enabled by
default] /home/jeanseb/line6linux/driver/trunk/driver.c:1272:26:
warning: ‘line6_driver’ defined but not used [-Wunused-variable]
------


Last one seemed suspect to me so i did a "grep usb_register *" and the
is no answer.


best regards 

Re: [Line6linux-devel] line6 out of staging

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

Am Samstag, 29. Dezember 2012, 21:16:44 schrieb L. Alberto Giménez:
> On Thu, Dec 20, 2012 at 10:09:05PM +0100, L. Alberto Giménez wrote:
> > On Thu, Nov 29, 2012 at 10:13:00AM +0100, Stefan Hajnoczi wrote:
> Hi,
> 
> I've installed some USB monitors on my Windows machines (some of them are
> trial versions, so I downloaded a handful of them and will try them out for
> features, ease of use, etc).
> 
> So, anyone could point me to documentation on how to begin? I'm not familiar
> with inner USB workings though I have some basic background (I've read
> LDD). I can now get the URBs running between the Windows box and the POD
> after connecting the device via USB, but I don't know what to do or how to
> parse all of that data... any help?
I once had the optimistic assumption that it would be possible to write code 
for devices which are not available to me for testing. With this intention in 
mind, I wrote up some instructions what data to record to be able to figure 
our the protocol by which host and device communicate (basically reflecting 
the experiments I made to implement the PODxt Pro driver):

http://www.tanzband-scream.at/line6/usblog.html

Although it turned out to be very difficult to actually write code based on 
these data without being able to test myself, it might provide some hints for 
you.

For the kernel part of the ALSA interface, you should read this:

http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/index.html

For the USB stuff, I only used the documentation included in the kernel 
sources.

Hope that helps, feel free to ask if you are looking for a particular piece of 
information!

	Kind regards,
		Markus

Re: [Line6linux-devel] line6 out of staging

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

On Thu, Dec 20, 2012 at 10:09:05PM +0100, L. Alberto Giménez wrote:
> On Thu, Nov 29, 2012 at 10:13:00AM +0100, Stefan Hajnoczi wrote:

Hi,

I've installed some USB monitors on my Windows machines (some of them are trial
versions, so I downloaded a handful of them and will try them out for features, ease
of use, etc).

So, anyone could point me to documentation on how to begin? I'm not familiar with
inner USB workings though I have some basic background (I've read LDD). I can now get
the URBs running between the Windows box and the POD after connecting the device via
USB, but I don't know what to do or how to parse all of that data... any help?


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

Re: [Line6linux-devel] fix coding style issues

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

Am Donnerstag, 20. Dezember 2012, 22:12:24 schrieb Laurent Navet:
> Hi,
> 
> As my previously sended patches seems lost, i will resend at the
> beginning of 2013.
> 
> this comments generate a switch/case non alignment warning, i think it
> could be removed.
> 
> ....
>         case LINE6_DEVID_PODSTUDIO_UX2:
>         case LINE6_DEVID_TONEPORT_GX:
>         case LINE6_DEVID_TONEPORT_UX1:
>         case LINE6_DEVID_TONEPORT_UX2:
>                 ep_read = 0x82;
>                 ep_write = 0x01;
>                 break;
> 
>                 /* this is for interface_number == 1:
>                    case LINE6_DEVID_TONEPORT_UX2:
>                    case LINE6_DEVID_PODSTUDIO_UX2:
>                    ep_read  = 0x87;
>                    ep_write = 0x00;
>                    break;
>                  */
> 
>         default:
>                 MISSING_CASE;
> 
> You agree ?
Yes, we don't need this comment.

	Kind regards,
		Markus

[Line6linux-devel] fix coding style issues

[Laurent N. <lau...@gm...>]

Hi,

As my previously sended patches seems lost, i will resend at the
beginning of 2013.

this comments generate a switch/case non alignment warning, i think it
could be removed.

....
        case LINE6_DEVID_PODSTUDIO_UX2:
        case LINE6_DEVID_TONEPORT_GX:
        case LINE6_DEVID_TONEPORT_UX1:
        case LINE6_DEVID_TONEPORT_UX2:
                ep_read = 0x82;
                ep_write = 0x01;
                break;

                /* this is for interface_number == 1:
                   case LINE6_DEVID_TONEPORT_UX2:
                   case LINE6_DEVID_PODSTUDIO_UX2:
                   ep_read  = 0x87;
                   ep_write = 0x00;
                   break;
                 */

        default:
                MISSING_CASE;

You agree ?

Regards,
Laurent
-- 
« On ne résout pas un problème avec les modes de pensée qui l’ont engendré. »
« You cannot solve current problems with current thinking. Current
problems are the result of current thinking »

Re: [Line6linux-devel] line6 out of staging

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

On Thu, Nov 29, 2012 at 10:13:00AM +0100, Stefan Hajnoczi wrote:
> > I didn't know that would alter the number of endpoints that the device shows
> > to the system.
> >
> > I use a hub just because it's easier to me to reach the hub on my desk with
> > the USB cable than the rear of my computer, but I can try to connect
> > directly to the root hub and see if I see any changes.
> 
> Does it work under Windows through your hub?

Hi again,

Sorry for the late reply. I've been offline for some weeks and I couldn't test it.

It seems that the culprit was the hub. In my Windows box, it failed as well, so I
tried to connect the POD directly to my Linux system (well... with an extension USB
cable) and now lsusb sees the audio interface. When connecting the device I get some
errors though, but I think that that's caused by the code itself:

Dec 20 21:42:06 bart kernel: [ 3394.007846] usb 8-1: config 1 interface 1 altsetting
0 bulk endpoint 0x1 has invalid maxpacket 64
Dec 20 21:42:06 bart kernel: [ 3394.007850] usb 8-1: config 1 interface 1 altsetting
0 bulk endpoint 0x81 has invalid maxpacket 64

At least, it's some progress. Even aplay -l shows the audio device:

card 2: PODHD500 [POD HD500], device 0: POD HD500 [POD HD500]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: PODHD500_1 [POD HD500], device 0: POD HD500 [POD HD500]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

I haven't been able to test it with real sound, but I think that it's something
already.

What I don't quite understand is why the hub causes the problem. Shouldn't it be
'transparent'?

I'll post the results when I actually try to get sound from the device.


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

Re: [Line6linux-devel] Opened a support ticket with Line6

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

On Thu, Nov 29, 2012 at 04:08:54PM +0100, "L. Alberto Giménez" wrote:
> El 28/11/2012 21:33, L. Alberto Giménez escribió:
> > Hi,
> >
> > I've just opened a support request with Line6. I'm trying to convince the to help us
> > to support their hardware on Linux.
> 
> Well, this is sad. After adding a message this morning to clarify the 
> 'reverse engineering stuff' as asked by Markus, now I can't see the 
> support ticket anymore.

Hey, after a couple of weeks, the ticket re-appeared with a support guy reply. It
said the standard 'Linux is not supported' and that the support tickets should be
used for problems using their supported systems.

The guy directed me to the feedback form. I resent the same text with the
modifications pointed out by Markus (i.e. change 'reverse-engineered' by 'used a USB
monitor'). I don't have any hope of getting a reply, but not doing anything at all
wouldn't mean a reply either :)

If you want, and/or if you have friends using Linux and owing a Line6 device, please
ask them to write to Line6. It may be futile, but it's better than not doing anything
at all.

I'll keep you updated!


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

Re: [Line6linux-devel] [PATCH] line6: Use kmemdup rather than duplicating its implementation

[Dan C. <dan...@or...>]

On Mon, Dec 03, 2012 at 05:34:07PM +0100, Stefan Hajnoczi wrote:
> On Mon, Dec 3, 2012 at 2:20 PM, Laurent Navet <lau...@gm...> wrote:
> > staging: line6: driver.c
> >  The semantic patch that makes this output is available
> >  in scripts/coccinelle/api/memdup.cocci.
> >
> > Signed-off-by: Laurent Navet <lau...@gm...>
> > ---
> >  drivers/staging/line6/driver.c |    5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
> > index f5c19b2..e1d6241 100644
> > --- a/drivers/staging/line6/driver.c
> > +++ b/drivers/staging/line6/driver.c
> > @@ -331,14 +331,13 @@ int line6_version_request_async(struct usb_line6 *line6)
> >         char *buffer;
> >         int retval;
> >
> > -       buffer = kmalloc(sizeof(line6_request_version), GFP_ATOMIC);
> > +       buffer = kmemdup(line6_request_version,
> > +                       sizeof(line6_request_version), GFP_ATOMIC);
> >         if (buffer == NULL) {
> >                 dev_err(line6->ifcdev, "Out of memory");
> >                 return -ENOMEM;
> >         }
> >
> > -       memcpy(buffer, line6_request_version, sizeof(line6_request_version));
> > -
> >         retval = line6_send_raw_message_async(line6, buffer,
> >                                               sizeof(line6_request_version));
> >         kfree(buffer);
> > --
> > 1.7.10.4
> 
> Your change is fine but I'm not sure whether we should allocate memory
> in the first place:
> 
> line6_send_raw_message_async() returns before the transfer is
> complete.  It submits one or more URBs but I cannot see a guarantee
> that the buffer is no longer needed.  It seems unsafe to kfree(buffer)
> before the request is complete.
> 

As Greg pointed out we do need to allocate the memory to make DMA
work.  But you're right that it is a use after free bug.  We should
move the kfree(msg->buffer) to inside line6_async_request_sent().
I can send a fix for this tomorrow or if someone else wants to do it
while I'm sleeping that's fine too.  :)

regards,
dan carpenter

Re: [Line6linux-devel] [PATCH] line6: Use kmemdup rather than duplicating its implementation

[Greg Kroah-H. <gr...@li...>]

On Tue, Dec 04, 2012 at 10:22:12PM +0100, Markus Grabner wrote:
> Am Montag, 3. Dezember 2012, 17:34:07 schrieb Stefan Hajnoczi:
> > On Mon, Dec 3, 2012 at 2:20 PM, Laurent Navet <lau...@gm...> 
> wrote:
> > > staging: line6: driver.c
> > > 
> > >  The semantic patch that makes this output is available
> > >  in scripts/coccinelle/api/memdup.cocci.
> > > 
> > > Signed-off-by: Laurent Navet <lau...@gm...>
> > > ---
> > > 
> > >  drivers/staging/line6/driver.c |    5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/staging/line6/driver.c
> > > b/drivers/staging/line6/driver.c index f5c19b2..e1d6241 100644
> > > --- a/drivers/staging/line6/driver.c
> > > +++ b/drivers/staging/line6/driver.c
> > > @@ -331,14 +331,13 @@ int line6_version_request_async(struct usb_line6
> > > *line6)> 
> > >         char *buffer;
> > >         int retval;
> > > 
> > > -       buffer = kmalloc(sizeof(line6_request_version), GFP_ATOMIC);
> > > +       buffer = kmemdup(line6_request_version,
> > > +                       sizeof(line6_request_version), GFP_ATOMIC);
> > > 
> > >         if (buffer == NULL) {
> > >         
> > >                 dev_err(line6->ifcdev, "Out of memory");
> > >                 return -ENOMEM;
> > >         
> > >         }
> > > 
> > > -       memcpy(buffer, line6_request_version,
> > > sizeof(line6_request_version)); -
> > > 
> > >         retval = line6_send_raw_message_async(line6, buffer,
> > >         
> > >                                               sizeof(line6_request_version
> > >                                               ));
> > >         
> > >         kfree(buffer);
> > > 
> > > --
> > > 1.7.10.4
> > 
> > Your change is fine but I'm not sure whether we should allocate memory
> > in the first place:
> I can't remember the precise reason for this copy operation, it was related to 
> which type of memory is allowed for a URB data block, and memory declared with 
> "static const char[]" at global scope in the driver is not allowed. I just 
> verified on my system (kernel 3.4.11) that requesting the device's firmware 
> version doesn't work when passing the line6_request_version pointer directly 
> (instead of its kmemdup copy), so I think the kmemdup is necessary here. It's 
> a bit unsatisfactory to make a copy just because the original data is not 
> accessible for whatever reason, but I don't know of a better solution. Maybe 
> somebody else can clarify this or propose an alternative method?

Yes, all data sent to the USB bus must be dynamically created, so
kmemdup is correct to use here.

thanks,

greg k-h

Re: [Line6linux-devel] [PATCH] line6: Use kmemdup rather than duplicating its implementation

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

Am Montag, 3. Dezember 2012, 17:34:07 schrieb Stefan Hajnoczi:
> On Mon, Dec 3, 2012 at 2:20 PM, Laurent Navet <lau...@gm...> 
wrote:
> > staging: line6: driver.c
> > 
> >  The semantic patch that makes this output is available
> >  in scripts/coccinelle/api/memdup.cocci.
> > 
> > Signed-off-by: Laurent Navet <lau...@gm...>
> > ---
> > 
> >  drivers/staging/line6/driver.c |    5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/staging/line6/driver.c
> > b/drivers/staging/line6/driver.c index f5c19b2..e1d6241 100644
> > --- a/drivers/staging/line6/driver.c
> > +++ b/drivers/staging/line6/driver.c
> > @@ -331,14 +331,13 @@ int line6_version_request_async(struct usb_line6
> > *line6)> 
> >         char *buffer;
> >         int retval;
> > 
> > -       buffer = kmalloc(sizeof(line6_request_version), GFP_ATOMIC);
> > +       buffer = kmemdup(line6_request_version,
> > +                       sizeof(line6_request_version), GFP_ATOMIC);
> > 
> >         if (buffer == NULL) {
> >         
> >                 dev_err(line6->ifcdev, "Out of memory");
> >                 return -ENOMEM;
> >         
> >         }
> > 
> > -       memcpy(buffer, line6_request_version,
> > sizeof(line6_request_version)); -
> > 
> >         retval = line6_send_raw_message_async(line6, buffer,
> >         
> >                                               sizeof(line6_request_version
> >                                               ));
> >         
> >         kfree(buffer);
> > 
> > --
> > 1.7.10.4
> 
> Your change is fine but I'm not sure whether we should allocate memory
> in the first place:
I can't remember the precise reason for this copy operation, it was related to 
which type of memory is allowed for a URB data block, and memory declared with 
"static const char[]" at global scope in the driver is not allowed. I just 
verified on my system (kernel 3.4.11) that requesting the device's firmware 
version doesn't work when passing the line6_request_version pointer directly 
(instead of its kmemdup copy), so I think the kmemdup is necessary here. It's 
a bit unsatisfactory to make a copy just because the original data is not 
accessible for whatever reason, but I don't know of a better solution. Maybe 
somebody else can clarify this or propose an alternative method?

	Kind regards,
		Markus