first version of file reading functions
Status: Pre-Alpha
Brought to you by:
mgrabner
Menu
▾
▴
Hi there,
you can reach the sources on https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/trunk/filedump_test/ via svn.
Comments welcome. If anyone uses a big-endian platform, I would be happy if he/she could test the application on that platform.
It accepts one command line parameter which is a filename to a l6t file and dumps the contents of that file. I am interested especially in any files which are not readable (you will probably only see -3 as output) or any files producing output where model info lines are not labeled. I only tested this application with files generated with Line6 Edit 3 using a PODxt.
Also, if someone has purchased some expansion packs and could produce a file for each additional function (e.g. amp, stomp) and write down the name of that selection, the labels of the knobs (if different from the usual knobs), the value ranges for those knobs and the actual values used, that would be very helpful. Also trying this with different devices can be helpful. Maybe someone can figure out if the differences for the other PODs.
Cheers,
Florian
I'm using an AMD64 and replaced all "long" by "uint32_t" because "long" are 64 bit on my machine.
I also created a "testsuite" framework under libline6tone where I propose to upload tones into "./testing" and to move them to "./working" once they passed all tests. The following test procedure tells us if a file is handled correctly (i.e., the same way as Line6Edit does):
1.) boot Windows
2.) use Line6Edit to upload the l6t to the POD to channel, say, 1A
3.) boot Linux
4.) use our software to upload the l6t to the POD to channel, say, 1B
5.) make channel dumps of 1A and 1B (using the sysfs "dump" entry) and compare the files
If the l6t is "complete" (i.e., specifies all parameters), then the two files of step 5.) must be identical. I will com eback to this issue in a separate thread.
Kind regards,
Markus
>1.) boot Windows
>2.) use Line6Edit to upload the l6t to the POD to channel, say, 1A
>3.) boot Linux
>4.) use our software to upload the l6t to the POD to channel, say, 1B
This is possible now. Check svn. I created a small app and lots of functions for converting l6t to a dump. I am not sure if it is working perfectly (I guess not, since I marked some parts in my source with 'TODO' -- maybe s/o can take a look at that). I think that I give it a break for a few days (unfortunately had to postpone my vacation due to some diarrhea I caught) for you guys to check those functions (maybe ~2.500 lines of code is enough for the planning phase ;-))
>5.) make channel dumps of 1A and 1B (using the sysfs "dump" entry) and compare the files
Hello,
I've run the dumper against a l6t and a gpt file of the same tone. The only differences I've seen are in the order of the output. For that case it is a bit difficult to make a simple diff. I'll try to sort out it manually and then compare it again.
For the records I own a Pod XT Live with all model packs available and a Variax 700.
(With the line6usb driver i get two entries in the /sys directory.)
Hartmut
OK
I've done now the manual ordering of the output of the two files.
If you like you can watch them via
http://www.gbhardy.ch/files/output.l6t
and
http://www.gbhardy.ch/files/output.gpt
It seems that line6Edit stores a bit more complete parameter list than Gearbox.
Another remark is that a time stamp of the saving time is stored in the files, but this should not torpedo Markus test scenario.
Hartmut
Just to remark:
the extensions of the files linked above are not meaning that they are real .lt6 and .gpt files. They are only to name the differend outputs.
Hartmut
> It seems that line6Edit stores a bit more complete parameter list than Gearbox.
> Another remark is that a time stamp of the saving time is stored in the files, but this should not torpedo Markus test scenario.
No, since this information will not be transferred to the POD anyway. The procedure I sketched is just to verify if we program the POD to produce the same sound as the Windows/Mac version does, which I think is the most important issue here.
Kind regards,
Markus
Great progress. Two things:
1. The program fails to parse some patches I retrieved from vettaville. I added some debugging in read_l6t() and it fails because the header.size doesn't match the patch size:
Header size: 1736, but 1824 bytes remaining
-2
I can't find the patches anymore on vettaville, so I've put them at http://www.rebelbase.com/~chris/podxt200%20AZ%20patches%20072304.zip
2. The params for the Compressor STOMPs may be wrong:
model info <0200> <0004> 2 3 active STOMP -- Compressor
parameter <3F10> 1 active 3f458b16 0.7717
parameter <3F10> 2 active 3f55ab57 0.8346
parameter <3F10> 3 *inactive* 00000000 0.0000 Sustain
parameter <3F10> 4 *inactive* 00000000 0.0000 Level
parameter <3F10> 5 *inactive* 00000000 0.0000
Looks like Sustain and Level are params 1 and 2.
>2. The params for the Compressor STOMPs may be wrong:
Already fixed that today. Please pull the latest source code from svn.
> 1. The program fails to parse some patches I retrieved from vettaville. I added some debugging in read_l6t() and it fails because the header.size doesn't match the patch size:
Those files seem to load well in Line6 Edit, so maybe this error can be ignored.
> Those files seem to load well in Line6 Edit, so maybe this error can be ignored.
Indeed, I looked at the files Christophe posted, and the length of the first FORM chunk seems to be a bit random :-( Maybe you can downgrade this to a warning for now.
Kind regards,
Markus
> I can't find the patches anymore on vettaville, so I've put them at http://www.rebelbase.com/~chris/podxt200%20AZ%20patches%20072304.zip
Thanks for the data, I checked them in into the testsuite/testing.
Kind regards,
Markus
I have added file writing support.
The application now takes a second parameter and writes back the file loaded. I haven't tried disabling the check that prevented the files Christophe mentioned from loading and then writing back these files, so I don't know if Line6 Edit will also read those 'corrected' files.
One big thing to do is to figure out all parameters (unfortunately they are also dependent on the type of effect selected). Do you know of any method besides of buying a model pack to get Line6 Edit to letting me select the grayed out entries in offline mode?
I remember some guys posting here with only little programming knowledge. Maybe one of them has some spare time to kill and can figure out the relation between the EQ frequency values (range [0, 1]) and the actual frequency. I did that for Band 1 of my PODxt, the equation is:
val = (f - 50) / 635
I began with the second band, but that seems to be constructed of 4 different lines. This also needs to be done (or at least checked) for the EQs of all other products. If you don't own that product, you can add it in offline mode to Line6 Edit.
Enough for now. I think that I put enough work into this for today.
Thank you Florian for your admirable effort.
While being in the "brain storming period" of the project I've nothing contributed to the codebase yet. (I've a full time job on Traffic Control Systems)
But I will, if the tasks are coordinated distributed. Maybe managed by Markus.
Meanwhile I'll do my best to do basic research on file formats relating to Line6 POD XT Live (which I own) and up- and downloading of them.
I'm using Line6Edit and GearBox on a MacIntel MacMini (as universal binary) which should provide the same byte order as an x86 WIntel PC. (But if it is necessary, I'm able to boot a Windows XP System with this software as well)
As I mentioned above, I'm able to provide information about every model pack available for our PODs.
I recognized that Christophe was posting about the vetta amp device files. I assume, that they are using the same core application in the Vetta Amps (which I not own) as in the PODs. If that is right our user focus is somewhat more spreaded and we've to take care of them.
Kind Regards,
Hartmut
> Christophe was posting about the vetta amp device files
Vetta ? Me ? I wish ! :-)
To clarify: the patches were from the vettaville website, but they were for the PODxt.
Sorry for that overbearance ;-)
I thought for using a word with "vetta" in it will manifest a Vetta user. ;-)
Mainly because Line6Edit is also for Vetta II.
http://www.gbhardy.ch/files/line6EditHelp.bmp
Hartmut
> As I mentioned above, I'm able to provide information about every model pack available for our PODs.
Thanks you, that's actually important input since we otherwise have no way to find out e.g. the ids associated with the extra stuff.
> I recognized that Christophe was posting about the vetta amp device files. I assume, that they are using the same core application in the Vetta Amps (which I not own) as in the PODs. If that is right our user focus is somewhat more spreaded and we've to take care of them.
Definitely, but that's hard to accomplish without being able to test the software with such an amp. It will probably work in some cases, but not all. So keep your eyes open for Vetta users :-)
Kind regards,
Markus
Got another failing patch:
http://www.rebelbase.com/~chris/slingy%20big%20bottom.l6t
The original l6t in svn was able to read this one, but now fails with -3.
> The original l6t in svn was able to read this one, but now fails with -3
Actually, should have looked closer: the original also failed with -3, but dumped the patch regardless.
Anyway, it's failing because there's a tag 'ISST' in the UNFO section. Seems to be for 'style', just as ISTL. Unfortunately, they both seem to appear in the same patch.
> Anyway, it's failing because there's a tag 'ISST' in the UNFO section.
> Seems to be for 'style', just as ISTL. Unfortunately, they both seem to appear in the same patch.
I noticed that today and added ISST as an allowed tag. The value is not mapped yet to the internal format.
Also one file (name was something starting with 'Zen') was padded with garbage. This file is readable now.
Please pull the recent svn versions; I changed a lot today.
> Please pull the recent svn versions; I changed a lot today
Almost. :-) Latest svn still fails on patch I mentioned above. This time:
reading /home/clambin/Desktop/slingy\ big\ bottom.l6t
CHUNK IINS unexpected
-3
A hexdump of the patch:
[...]
00000880 00 2e 00 31 00 30 49 49 4e 53 00 00 00 1e 00 45 |...1.0IINS.....E|
00000890 00 6c 00 65 00 63 00 74 00 72 00 69 00 63 00 20 |.l.e.c.t.r.i.c. |
000008a0 00 47 00 75 00 69 00 74 00 61 00 72 |.G.u.i.t.a.r|
000008ac
Looking through my patch collection, I get the following values:
IINS Bass Guitar
IINS Electric Guitar
IINS Male Vocal
IINS Miscellaneous
IINS Vocal/Mic
I guess IINS stands for 'Instrument' ?
> CHUNK IINS unexpected
Just added IINS to the svn version. As with ISST, this data is not transferred to the internal format yet.
> Just added IINS to the svn version
Works now. One more thing: I think it would be better if read_l6t() gets passed a buffer, or perhaps a file pointer. The reason is that I've been looking at the format of bundles (l6b) and collections (l6c) and they both contain the standard L6PA format for the actual patches, amp settings and fx settings. This way, the existing function will be able to handle the L6PA's within bundles and collections without resorting to intermediate files.
> Works now. One more thing: I think it would be better if read_l6t() gets passed a buffer, or perhaps a file pointer. The reason is that I've been looking at the format of bundles (l6b) and collections (l6c) and they both contain the standard L6PA format for the actual patches, amp settings and fx settings. This way, the existing function will be able to handle the L6PA's within bundles and collections without resorting to intermediate files.
Good point. Communication between the GUI and the underlying file handling code via intermediate files is not the optimal solution.
Kind regards,
Markus
> Good point. Communication between the GUI and the underlying file handling code via intermediate files is not the optimal solution.
The point is indeed good but I don't see the connection to the GUI. Why would the GUI want to communicate with l6t files or data anyway? I thought that we agreed on using the native POD format (aka dump) for that.