call for brainstroming
Status: Pre-Alpha
Brought to you by:
mgrabner
Menu
▾
▴
Dear Line6/Linux enthusiasts!
Many of you have been using the Line6 Linux USB driver which I started to develop in 2004. Now as the Line6/Linux community is growing, I repeatedly receive requests for a Linux "clone" of the Line6Edit application provided by Line6 for Windows and Mac. Several people independently started to develop such a tool. However, I think we can do better if we join forces and bring together all these talented programmers and musicians and work on a single project. I therefore invite everybody who is interested in contributing to such a common project to share their thoughts with me on the following issues:
*) How should a Line6Edit clone for Linux be called? Line6Edit may be problematic due to legal reasons, let's call it Line6Access for the moment.
*) Which features should Line6Access support? Short answer: all the features of Line6Edit, so let's put the question a little bit different: which of the Line6Edit features should be implemented first?
*) Which GUI library should Line6Access be based on? I think this is the single one question which has the largest potential to delay the entire project by creating yet another instance of a Qt/GTK/... religious war. While I personally prefer Qt4, I think it's perfectly acceptable to create different GUI bindings if the underlying software layers are well designed.
*) This already implies the next question: which modules should the project be separated into? A few come into my mind immediately: communication with Line6 devices, data exchange with Line6Edit, and GUI.
*) Which build system should be used? I prefer cmake since it can handle complex projects with surprisingly little effort. Any other suggestions?
*) Which packaging system and Linux distributions should be supported? This question is probably answered by the personal preferences of the contributors (I volunteer to provide RPM packages for SuSE :-)
*) Do you see any other issues that should be discussed before we start coding?
If you already have some code that you would like to contribute, please explain in a few words what you have achieved so far (a screenshot would be very interesting if available).
I'm looking forward to a successful collaboration!
Kind regards,
Markus
Hi Markus,
your e-mail reached me and here I am with some feedback.
Regarding the name: I'm not very creative, so I cannot provide you with any ideas about that.
My device is a PODxt.
In my opinion some features (especially those related to the Internet, e.g. submitting tones to the library) may be problematic to implement maybe even due to legal issues. I don't really like the GUI of Line6 Edit and would propose a 'virtual floor board view' where one can see an overview of all stomp boxes currently active side by side and some 'spare pedals' which can be dragged and dropped to their final position. The version with those grayed icons and the arrows to move around those boxes is not that 'natural way' like connecting a floor board. The settings for the currently selected stomp box should be displayed under this floor board and it would be somehow nice if that looks like a real stomp box. But I am no gfx guy either, so my help regarding the optics would be limited.
When using Qt as GUI framework, I think that qmake could be used since that project probably won't get too complex and maybe cmake and/or KDE4 is not used in all distributions and needs to be installed. From my point of view the depedencies on other packages should be kept low (I'm using Gentoo and Gnome -- but nevertheless, I have cmake and Qt [but only version 3] installed, but surely prefer GTK).
I can create an ebuild (Gentoo package) from the sources.
As I am more that bit twister type of GUI, I volunteer working on the communications to the device. For connecting the GUI and the device, POSIX message queues could be used. Currently I don't really know much about your existing source code (haven't looked into it yet - or if I did, I forgot about it) but surely some parts could be used.
I have a bit of spare time now (~ 1 month) and plan on doing a vacation somewhere around next week for about 10 days. But after that I would be available (from August on possibly only on the evenings resp. weekends -- I don't know yet if I am going to have some Internet connection at the place I am going to stay then), so maybe this would be a good way to kill some time in the evenings while I'm working away from home.
This is it for now, since I have written quite a lot and now want to get my CPLD doing what I want it to do.
Cheers,
Florian
> I can create an ebuild (Gentoo package) from the sources.
Thank you!
> As I am more that bit twister type of GUI, I volunteer working on the communications to the device. For connecting the GUI and the device, POSIX message queues could be used. Currently I don't really know much about your existing source code (haven't looked into it yet - or if I did, I forgot about it) but surely some parts could be used.
Thanks again! An important issue in this context is a proper method to find out which Line6 devices are available. The software should really try hard to find them, and if it fails, provide detailed feedback on what went wrong (is the driver loaded, is the device connected, is the device supported etc.). I personally hate messages like "initialization failed" or "read the docs" (at least if no link to the docs is included in the message).
The attempt I made is based on ALSA and Qt4. We should get rid of Qt4 at this level, but I propose to stick with ALSA because this makes it trivial to also support Line6 devices which only have a MIDI interface (I think the "plain" PODs don't have USB). There should probably be a separate thread for the device communication to avoid GUI "hangups" during lenghty operations (such as uploading patches).
Kind regards,
Markus
> Thanks again! An important issue in this context is a proper method to find out which Line6
> devices are available. The software should really try hard to find them, and if it fails,
> provide detailed feedback on what went wrong (is the driver loaded, is the device connected,
> is the device supported etc.).
Well... the library should have something like an line6_enumerate_devices() that would
take an increasing integer index and return brief informations about the available devices
in the system. Then one would eventually call line6_open() on one of them....
I've been looking in the driver sources (0.7.1) for a suitable method of "opening" the device
and found out that there is no unique device that one can open.
The driver itself exposes a sort of "half-userspace interface" via several devices in /sys.
I think that this should be handled by the libline6 instead. The driver should
expose only one device (or two: alsa and raw) and handle everything via ioctl.
In this way the library can open one of the devices (without being afraid of
"loosing" them by the way) and translate user-friendly function calls to ioctls.
Otherwise it ends up that the library has no real "handle" to the physical
device and one can end up mixing devices by swapping the physical usb inputs...
Has this changed in more recent driver releases ?
Szymon Stefanek
I just took a look into the source. Please forget my thoughts about IPC and message queues. If I understand the sources correctly (please correct me if I'm wrong here), then everything we need is transmitted via MIDI (or MIDI encapsulated in USB). So then of course the solution with device files is appropriate. A simple MIDI device is needed which acts as the interface between library and kernel module. The kernel module itself shouldn't expose those /sys files anymore (they are marked as deprecated anyway).
> If I understand the sources correctly (please correct me if I'm wrong here), then everything we need is transmitted via MIDI (or MIDI encapsulated in USB).
That's right, the line6usb kernel driver registers an ALSA MIDI device and internally routes MIDI messages via USB. The entire bidirectional communication with the Line6 hardware can be done via this MIDI device (which is equivalent to using a user-space library like libusb for explicit USB access, besides the fact that the MIDI approach can easily be ported to "true" MIDI devices (i.e., those without USB).
> A simple MIDI device is needed which acts as the interface between library and kernel module.
There are two options with ALSA:
*) The kernel-space portion of ALSA creates device files somewhere under /sysfs, which can be used via regular I/O methods in C (open, read, write, ioctl).
*) The user-space portion of ALSA provides some dedicated function to access MIDI interfaces registered with ALSA (including the virtual MIDI interface provided by the line6usb kernel driver).
The first method is certainly easier to use and can also be used with higher-level tools such as C++ iostreams (at least in principle, this is probably not very useful here).
> The kernel module itself shouldn't expose those /sys files anymore (they are marked as deprecated anyway).
I find them still useful for command-line access (e.g., to check if the device responds). We won't need them in our GUI application, though, so they could be made optional in the kernel driver. BTW, what do you mean by deprecated here? Has there been a statement by the kernel developers that the sysfs will become obsolete?
Kind regards,
Markus
>BTW, what do you mean by deprecated here? Has there been a statement by the kernel developers that the sysfs will become obsolete?
My fault. Just rechecked that. I got a bit mislead by CONFIG_SYSFS_DEPRECATED. This seems to relate only to some special files.
> Well... the library should have something like an line6_enumerate_devices() that would
> take an increasing integer index and return brief informations about the available devices
> in the system. Then one would eventually call line6_open() on one of them....
Yes, such a procedure is convenient for the software layers above it.
> I've been looking in the driver sources (0.7.1) for a suitable method of "opening" the device
> and found out that there is no unique device that one can open.
> The driver itself exposes a sort of "half-userspace interface" via several devices in /sys.
The driver registers a MIDI interface for each connected device, which can be queried via ALSA (such as "amidi -h" does). At the same time, the USB device can be found via libusb (which is a very reliable method to find Line6 devices due to the unique vendor id assigned to Line6). What is missing is a link between these two. Once this is established, the library can uniquely identify each device and talk to it via ALSA/MIDI or directly via the kernel driver interface. I will think about that (and created a tracker entry to remind myself :-).
> I think that this should be handled by the libline6 instead. The driver should
> expose only one device (or two: alsa and raw) and handle everything via ioctl.
> In this way the library can open one of the devices (without being afraid of
> "loosing" them by the way) and translate user-friendly function calls to ioctls.
Exposing only one device would require a major modification of the driver code. The kernel USB subsystem calls the device probe method for each device that matches a list of supported devices provided at module initialization (see "line6_probe" and "line6_id_table" in "driver.c"). Mapping them all to a single one would break this concept and require additional effort. An ioctl interface to the features currently provided via sysfs might be worthwhile to consider, however.
> Has this changed in more recent driver releases?
No, 0.7.2 is just a bugfix release.
Kind regards,
Markus
> The driver registers a MIDI interface for each connected device,
> which can be queried via ALSA (such as "amidi -h" does).
> At the same time, the USB device can be found via libusb
> (which is a very reliable method to find Line6 devices due
> to the unique vendor id assigned to Line6).
This makes the things clearer. So one can just open the
alsa device and fiddle with the line6 device by sending midi
messages over it.
> What is missing
> is a link between these two. Once this is established, the
> library can uniquely identify each device and talk to it via
> ALSA/MIDI or directly via the kernel driver interface.
> I will think about that (and created a tracker entry to remind
> myself :-).
An idea could be to have a /sys/something/line6_ctl common
file, which could enumerate all the line6 devices present
in the system (the driver *knows*). This could be done
in a binary format via ioctl loop or maybe via some simple
parseable text format. The returned enumeration structure
could contain the paths of the midi/usb files that each physical
line6 device "owns" (again, the driver should *know*).
So the libline6 steps would be: open line6_ctl, enumerate
the devices and find the one that the user is looking for
(probably by matching the description or looking at
the order on bus...). Then open the associated alsa midi.
> Exposing only one device would require a major modification
> of the driver code. The kernel USB subsystem calls the device
> probe method for each device that matches a list of supported
> devices provided at module initialization (see "line6_probe"
> and "line6_id_table" in "driver.c"). Mapping them all to
> a single one would break this concept and require additional
> effort.
Well.. maybe I've expressed things in a slightly wrong way
which generated a "qui pro quo" :)
Anyway, the answer above cleared my doubts.
So, as long as the physical line6 device has at least
one device file associated that the userspace library can
reliably "keep open", it's ok.
> An ioctl interface to the features currently provided
> via sysfs might be worthwhile to consider, however.
I'm not a guru in MIDI so please correct me.
Well.. the alternative to ioctl is to send raw midi
packets over the alsa device and (generally)
wait for an answer. Right ?
Which is the practical difference between sending them
over the alsa midi device and sending them over
the usb device (via libusb ?).
These are the only messages that the line6 devices
use to communicate ?
#define LINE6_PARAM_CHANGE 0xb0
#define LINE6_PROGRAM_CHANGE 0xc0
#define LINE6_SYSEX_BEGIN 0xf0
#define LINE6_SYSEX_END 0xf7
#define LINE6_RESET 0xff
Say that I want to change the "tone" on my PodXt.
The steps to do it would be:
- open the midi/usb device
- send a program change packet (like line6_send_program() in the driver)
- wait for the message echo from the pod
Right ?
Szymon Stefanek
Hi there!
Nice to see that you're starting this project.
I think that it will be useful :)
*) How should a Line6Edit clone for Linux be called? Line6Edit may be problematic due to legal reasons, let's call it Line6Access for the moment.
I'd suggest libline6 for the library (see below) and linuxline6 for the app.
line6access sounds also ok, anyway.
*) Which features should Line6Access support? Short answer: all the features of Line6Edit, so let's put the question a little bit different: which of the Line6Edit features should be implemented first?
My suggested macro "steps" in order:
- basic interaction with the devices (device info pages)
- listing of sound patches present on the device
- sound patch switching from the pc
- backup of sound patches to disk (in line6edit compatible format...)
- upload of sound patches (backupped or downloaded from the net)
- editing of sound patches (huge work)
*) Which GUI library should Line6Access be based on? I think this is the single one question which has the largest potential to delay the entire project by creating yet another instance of a Qt/GTK/... religious war. While I personally prefer Qt4, I think it's perfectly acceptable to create different GUI bindings if the underlying software layers are well designed.
My vote goes for Qt4.
*) This already implies the next question: which modules should the project be separated into? A few come into my mind immediately: communication with Line6 devices, data exchange with Line6Edit, and GUI.
I'd say two modules.
- a library that provides device communication primitives and standardized data structures
- an end-user graphical application
Three modules if you also take into account the kernel driver.
The library could be eventually used by third party applications.
The question is eventually if the library should use or not the toolkit choosen above (between Qt and GTK).
If the library sticks with a toolkit then the UI will be forced to interact with it...
*) Which build system should be used? I prefer cmake since it can handle complex projects with surprisingly little effort. Any other suggestions?
My vote goes for cmake too.
*) Which packaging system and Linux distributions should be supported? This question is probably answered by the personal preferences of the contributors (I volunteer to provide RPM packages for SuSE :-)
This question will automatically find an answer in later development stages.
It will take a while to write an usable app: distributions might change and new strong
ones might come out. Enthusiast users will also provide packages for their favorite distros
if the project becomes widely known.
*) Do you see any other issues that should be discussed before we start coding?
We should attempt a "friendly" collaboration with line6 by notifying them
of the project at a very early stage (substantially once it's known that
the project has started and WILL exist).
This might help in preventing future "cease and desist" e-mails. Line6 could
also decide to provide more details about their device internals and/or line6edit
and/or their proprietary file formats.
Szymon Stefanek
> *) Do you see any other issues that should be discussed before we start coding?
>
> We should attempt a "friendly" collaboration with line6 by notifying them
> of the project at a very early stage (substantially once it's known that
> the project has started and WILL exist).
> This might help in preventing future "cease and desist" e-mails. Line6 could
> also decide to provide more details about their device internals and/or line6edit
> and/or their proprietary file formats.
This is also my opinion. Actually they are aware of the Linux driver and told me that they like it a lot, they even answered several questions regarding implementation details of their hardware, though I didn't receive the specifications. So there has already been a certain amount of "friendly collaboration" so far, which makes me optimistic for the future.
There is one area where they can make a significant contribution: if we want our tool to look cool, we should use the same artwork (background images, dials etc.) as Line6Edit, but this probably requires their permission. I already asked a Line6 engineer this question, he forwarded it to their legal department, from where no answer came back. Once our project has "taken off", I will certainly repeat the question, but it would be good to provide some licensing options. I am not at all a legal expert (are there any who can comment on this?), but from what I understand about open source licensing I see several possibilities:
*) The most convenient option for the community would be if Line6 would provide their artwork under the GPL.
*) However, it's probably easier to get them agree that the images may only be used in our project and nowhere else, which violates the GPL. So I can image some "skinning" approach, where the application can be used with some basic skin included in the package, and a "Line6 skin" which can be loaded dynamically and can be distributed separately with a different license (one that Line6 is fine with). As far as I know, this is not in conflict with the GPL.
As I told above, this is just my understanding of this issue, so any legal advice would be highly appreciated!
Kind regards,
Markus
>The question is eventually if the library should use or not the toolkit choosen above (between Qt and GTK).
>If the library sticks with a toolkit then the UI will be forced to interact with it...
I advice against that. For clearliness the library should be independent on the GUI toolkit as it's functions have nothing to do with the GUI), so a plain old GNU like C library would be enough. The idea of using a library is a good idea and introduces other possibilities for later work e.g. some kind of fader automation plugin for whichever sequencer program.
We would then have the modified kernel module which keeps sending an receiving through a posix message queue, the library which provided functions to interact with this message queue and the GUI which uses that library.
>There is one area where they can make a significant contribution: if we want our tool to look cool, we should use the same artwork >(background images, dials etc.) as Line6Edit, but this probably requires their permission.
That would imply that the application looks about the same way Line6 Edit does. As said, my opinion is that I don't like that GUI.
>>The question is eventually if the library should use or not the toolkit choosen above (between Qt and GTK).
>>If the library sticks with a toolkit then the UI will be forced to interact with it...
>I advice against that. For clearliness the library should be independent on the GUI toolkit as it's functions have nothing to do with the GUI),
I agree with that.
> so a plain old GNU like C library would be enough.
It might be necessary to include another library for the communication. ALSA is a good candidate as it allows communication using the MIDI standard, which is a natural choice for musical equipment as I stated before.
> The idea of using a library is a good idea and introduces other possibilities for later work e.g. some kind of fader automation plugin for whichever sequencer program.
I think ardour can do this with little effort if the device can receive MIDI events. However, I never tried this.
> We would then have the modified kernel module which keeps sending an receiving through a posix message queue, the library which provided functions to interact with this message queue and the GUI which uses that library.
I have never used POSIX message queues in my software. What are the benefits of them compared with ALSA MIDI?
>>There is one area where they can make a significant contribution: if we want our tool to look cool, we should use the same artwork >(background images, dials etc.) as Line6Edit, but this probably requires their permission.
>That would imply that the application looks about the same way Line6 Edit does. As said, my opinion is that I don't like that GUI.
Ok, that's a matter of personal taste (I like the Line6 GUI). Making this configurable is certainly a good idea, but also more work...
Kind regards,
Markus
> It might be necessary to include another library for the communication. ALSA
> is a good candidate as it allows communication using the MIDI standard, which
> is a natural choice for musical equipment as I stated before.
A message queue is used for interprocess communications (IPC). This can be used for connecting the kernel driver with the library in case of USB. libusb cannot be used since the USB device is already occupied. It might be possible to create a device (i.e. file under /dev) for the communication between the kernel and the library but low latency for either direction should be provided, meaning that when you turn a knob on either the POD or in the GUI, the changes should be applied to 'the other end' with a minimum delay. Maybe polling a device handle for changes is not the best way for doing this. Also, with a message queue it would be possible to provide data to different listeners, e.g. the GUI and some kind of plugin at the same time.
> I think ardour can do this with little effort if the device can receive MIDI
> events. However, I never tried this.
My POD got dusty lately so I don't know of these methods either.
> I have never used POSIX message queues in my software. What are the benefits
> of them compared with ALSA MIDI?
See above. MIDI or USB would be the hardware connection type to the device. I think that USB should be used where possible and thus both methods should be implemented.
> Ok, that's a matter of personal taste (I like the Line6 GUI). Making this
> configurable is certainly a good idea, but also more work...
Without the artwork of the original tool, the GUI certainly would look different (at first).
Hi there Markus, thanks for the e-mail.
I'd be interested in this, and am in agreement with Qt. ASLA, I think, is the best idea as well - along with USB connection if available.
For the record, I have a PodXT Live.
I should also, hopefully, be able to help out and make deb packages.
Feel free to add me as a contributer for this project.
Regards,
Dan
> I should also, hopefully, be able to help out and make deb packages.
Thank you! I think we are complete then with respect to the major packaging systems.
Kind regards,
Markus
Hi Markus,
thank you or setting up this project on sf.net.
Not long ago I've started to develop a small C++ console application to collect some experience in communicating to the interface your driver provides. It should end up in a QT based application. Until now.
I've also collected developing some small applications for MIDI control via ALSA for other devices like the Creamware Noah and the Vamp-Pro from Behringer.
I aggree with the selection of ALSA to communicate with MIDI-only devices.
As well as to ask Line6 for allowance to use their artwork of the stompboxes and devices, which will make work much more easier. The look and feel of the GUI itself could be different to Line6Edit in my opinion.
Regarding the name, at the moment I know two simliar projects:
qtpod:
QT and ALSA based, for POD, POD2 and POD-PRO via MIDI
Author: Dirk Jagdmann <doj@cubic.org>
podgui:
TCL and ALSA based, for POD
Author: Rub Cohen rub0612@yahoo.fr
"Unfortunately" the pod term is often used by free software interacting with Apple's iPod.
Is it also a legal problem for naming an application with line6*?
My opinion to the software design:
A library that uses either the usb driver from markus or the ALSA MIDI interface.
A GUI based on QT, GTK or WxWidgets. All three frameworks allow crossplatform development.
The selection of the GUI framework depends also in the effort to build and customize the controls like rotarys, faders and switches to make it look a little bit user friendly.
I'm an opensuse user and for the i've a strong sidelook to the JAD distribution. (JackLab Audio Distribution). They're using Enlightenment 17 as their window manager.
Anyway, I'm interested to take part in the project; my skills allow to contribute to the library and the GUI.
Kind regards,
Hartmut
> Regarding the name, at the moment I know two simliar projects:
Thanks for pointing this out, I will notify them of our discussion here.
> Is it also a legal problem for naming an application with line6*?
This might be the case, although they know about the line6usb kernel driver and didn't complain about the name. Technically, changing the name of the application is easy, but it's certainly easier in early stages. I will ask Line6.
> Anyway, I'm interested to take part in the project; my skills allow to contribute to the library and the GUI.
Thanks a lot!
Kind regards,
Markus
*) How should a Line6Edit clone for Linux be called? Line6Edit may be problematic due to legal reasons, let's call it Line6Access for the moment.
It may be problematic as well if we use the words "line6" and/or "pod" in general. We have to ask line6 for an official statement to avoid problems. I started a GUI project a few days ago and I named it "PODit!" but that's just a work title for now. We could use the original name change it a little bit to make clear that this one ist for linux. I would suggest something like "Lineux6Edit". Another idea would be PODrod or hotline6. And if lin6 does not cooperate we name it decline6edit *g* (just joking).
*) Which features should Line6Access support? Short answer: all the features of Line6Edit, so let's put the question a little bit different: which of the Line6Edit features should be implemented first?
That's not really the question imho. It just doesn't make sense to implement some features first (like reverb settings or stomp effects). It makes sense to implement reading and storing data first, then make the user able to edit amp and A.I.R. stuff, then effects and all the other stuff. The last step should be to design some nice graphical controls and replace the original ones (from qt).
*) Which GUI library should Line6Access be based on? I think this is the single one question which has the largest potential to delay the entire project by creating yet another instance of a Qt/GTK/... religious war. While I personally prefer Qt4, I think it's perfectly acceptable to create different GUI bindings if the underlying software layers are well designed.
In general I don't mind. I use KDE with Qt and GTK apps. O.k., if I think twice I'd prefer Qt I think.
But I would like to see myself coding some stuff. Unfortunately I've got low skills at C++ and GUI development with linux. I really like Gambas which is a lot like Visual Basic. It's very easy, it ships with some controls and you can use Qt controls as well. I don't think that we need more than that. It's just a frontend, not a high end app. Some sort of file input and output, not more.
*) Which packaging system and Linux distributions should be supported? This question is probably answered by the personal preferences of the contributors (I volunteer to provide RPM packages for SuSE :-)
Since the Ubuntu community is growing dramatically and the new distribution "Ubuntu Studio" got very famous already, I'd say a debian package is a must!
*) Do you see any other issues that should be discussed before we start coding?
We should discuss the hole thing with line6 before starting. We shold make clear that:
- line6 gets more customers with better linux support
- it's a good marketing to support the linux community
- they don't need to spend an money and get a great benefit
- we put a message into the GUI that line6 is not involved or responsable in any way.
We should ask to:
- use their names or part of their names and other for the GUI (like line6, line6edit, POD, A.I.R.)
- use the original images of the windows GUI.
- have the protocol to load presets directly from the internet (customtone.com). O.k., we could sniff the pakets instead.
> It just doesn't make sense to implement some features first (like reverb settings or stomp effects).
I meant goodies like the guitar tuner, which can be postponed to the second version. Once you can turn one dial, it's probably just copy&paste to support any other parameter (maybe a bit more effort for effects where the parameter meaning depends on the selected effect).
> It makes sense to implement reading and storing data first, then make the user able to edit amp and A.I.R. stuff, then effects and all the other stuff.
Reading and storing data is simple when using POD's native storage format (which is a fixed-size binary data block and can be accessed via the "dump" special file of the driver). However, a codec for the l6t format is much more difficult, so we probably should stick with the native format at the beginning.
> Since the Ubuntu community is growing dramatically and the new distribution "Ubuntu Studio" got very famous already, I'd say a debian package is a must!
Fortunately there is already a volunteer :-)
> We should discuss the hole thing with line6 before starting.
Absolutely! They should understand the benefits for them. They like the Linux driver, so they might also like our application...
> have the protocol to load presets directly from the internet (customtone.com). O.k., we could sniff the pakets instead.
As far as I understand, this is just plain HTTP (which, BTW, Qt4 can handle) to access the l6t-files available on the web-site. Support for the l6t format is more challenging (see above).
Kind regards,
Markus
>As far as I understand, this is just plain HTTP (which, BTW, Qt4 can handle) to access the l6t-files available on the web-site. Support >for the l6t format is more challenging (see above).
Just sniffed a few packets.
GET /getdata/type=line6/ttw_filename=Still%20got%20Blues1/table=tones/field=tone_hum/ttw_filetype=l6file/product_id=12/id=160830/ext=.data HTTP/1.1\r\n
It is plain HTTP.
> Just sniffed a few packets. It is plain HTTP.
Thanks, good to know!
Kind regards,
Markus
> a codec for the l6t format is much more difficult
FWIW, I did some work in this in the past. I have a python script that can parse an l6t and display the parameters. I already mapped out the main parts (e.g. which part is the AMP, where's the STOMP, etc), but never got around to mapping the different models (e.g. which STOMP is 0x0004 ? How do the 5 generic stomp parameters map to the 'Red Comp' Sustain and Level params ?)
Seems like you'll need to do this mapping exercise for the editor anyway, seeing as the line6usb driver also only provides generic parameters.
The script's a bit messy, but it may help you get started.
I'm not posting it anywhere (not sure about the legal position on reverse engineering the data format), but if you need it, I can mail it.
> I'm not posting it anywhere [...] but if you need it, I can mail it.
Please mail that script to me. Seems that I now volunteer to figure out that file format.
> Please mail that script to me. Seems that I now volunteer to figure out that file format.
Good luck. :-)
I'll clean it up a bit and send it to you this evening.