Fileformats, custom tools and API

[BarkingSpiders]

Hi there,

 

Is there any information out there on the file format of PGP (preset) and PGB (backup) files? I'm thinking about creating a tool that for instance quickly checks all volume settings, or is able to force identical colors for certain stompboxes. E.g., force all reverbs to be green and always in the 4th switch position. Stuff like that.

 

I'm not expecting these specialized features to ever end up in the POD Edit front end, so it would be great if programmers would be able to cook up something themselves. For this to work, obviously we would need some info on those file formats.

Or better still: provide us with an API to control the POD Go. Although I'm sure it's easier to share file format information :)

 

Any help would be greatly appreciated.

 

Cheers,

 

 

M

 

[usedbyanr]

I don't believe there's any public information but the PGP files are just simple JSON. You can make a change, export and diff the files to see what changes. Other's have figured out what's in there because there's a few websites that will load a Helix preset and display it visually. The formats are nearly the same with different extensions. If you look at the PGB files in a hex editor you will see they start with AF6L. Google "AF6L beginning of file" and you will stumble across a Helix backup file parser project. I assume the files are the same with different extensions. Not to rain on your parade but, my guess is that some of your ideas are not something that would be in a preset file. For example, the color of a delay is likely built into the Pod Go firmware and Pod Go Edit rather than reading it from the file. Volumes are dependent on the individual amp simulations and gain settings from whatever pedals you have selected.

[BarkingSpiders]

Thanks! I actually am a bit further with decoding the PGB file format. It's a little bit different than the HX one as it seems to have only 2 zlib sections: one containing the global settings + factory preset information. And the second section contains the user presets. ledcolor is actually defined in this information:

 

     "footswitch" : {
      "dsp0" : {
       "block0" : {
        "@fs_enabled" : false,
        "@fs_index" : 9,
        "@fs_label" : "Fassel",
        "@fs_ledcolor" : 196619,
        "@fs_momentary" : false,
        "@fs_primary" : true
       }

 

and also the ledcolor in snapshots:

 

     "snapshot1" : {
      "@ledcolor" : 0

 

I've attached the two decoded sections as json files. Might be interesting to take a look at it. Up next would be to modify it and store it as a PGB file again :)

 

section2.json section1.json

[grdGo33]

On 4/1/2022 at 7:41 AM, BarkingSpiders said:

 quickly checks all volume settings,

 

Problem is that there's no 'normalized' volume settings.   With a certain amp and distortion pedal, with ch. volume and master volume at 5 you might get ear bleeding volume, whereas another amp with the same 5 would be barely audible.  So normalizing volume by programming would be a very complex problem to solve.

 

Quote

or is able to force identical colors for certain stompboxes.

That should be pretty easy.  Modern programming languages all have libraries to load and save json files, so you'd basically define the structure of a patch (ex; patch contains blocks which can be of type X which contain X value), then changing a value and saving.  So you'd just loop through patches and change the value depending on type. 

 

Or, you can just code in particular values to loop through and if the name/type or contains said property, change X value inside this object

 

For the pgp format, it's json.  So nothing particular to do with that, you just save the json string in a file with .pgp extension and you're done.

 

Quote

force all reverbs to be green and always in the 4th switch position.

 

Yeah decoding the format to work with snapshots and all might not be as simple as I recall, just loaded a random downloaded patch and the snapshot...    Data contains a tone object, and this tone object contains a controller, footswitch, dsps and snapshots...   https://www.jsonvisual.com/  displays everything in easily readable format.

 

I think for Go you'll always only have a dsp0 with values, as the Helix has 2 paths, but Go only has one, the dsp1 will always be empty.   So dsp0 contains your patch settings.  Snapshots obviously contains snapshot info.  Footswitch contains footswitch info.  Not sure what's the purpose of 'controller', probably more related to Helix.

 

Actually no, I think 'controller' defines how the effect is controlled via the GUI of the Go; so if you select a particular reverb, that reverb will have have say 6 settings, 1st called x, 2nd y, etc., with values min 0 max 10, etc., so basically; defines how once loaded how everything is controlled.

 

So if you modify block order (ex; put reverb last),  you'll very likely have to modify this section, otherwise you're likely to encounter errors or very strange behaviour as ex; you'd be trying to assign reverb settings to a distortion pedal, which could result in random settings or make the Go crash ...  Ex; controller 2nd element contains Block 3 contains HBE, dsp0's 2nd element contains block3 contains HBE related values

 

But yeah to alter the footswitch position, that would be footswitch section, but not sure of the logic, they contain a @fs_index but many have the same index, (ex; 1, 2, 3, 5, 9, 9) so my guess would be that 9 means no switch, and you likely have fs_index 1-6 for the Go's foot switches.  yep, that would make sense.  the fs_label is even there, obviously from Helix, but again not useful for Go.

 

So yeah, you'd likely just have to modify the index.  Again, programatically, you'll have some issues, as you might have to switch or change to 9 an existing block at the footswitch 4 position you're trying to switch an effect to, otherwise, 2 blocks for 1 switch.  What if you have 2 reverbs?  Etc..  Just some 'edges' cases to fix.

[grdGo33]

So yeah, maybe a fun project, but...  As a programmer, lol, I think it would be more just a fun project rather than a useful tool.  Maybe switching LED color automatically might be useful, but then you'd have to export and re-import the patches, so unless you can do so automatically, might not be super useful, as that would be a PITA to do constantly; ex; after creating a patch.  Proably less trouble to manually set the LED color rather than export, run tool, import.

 

I think practically, you could change the default color values of effects, what is called 'favorites'.  Maybe you can even do it in a Go setting, can't recall if it's possible or not.

 

But again, your best bet would probably just be getting used to Go's colour scheme.  Don't try to fix the world; try to fix yourself.  ;)

 

But yeah, for learning programming project, could be fun!   :D   And later on, once you've learned the basics, then you could apply it to more useful features, not exactly sure what it could be for Go, but you never know, could lead to something!

 

What I'd be interested in doing, if I had not already an overload of programming, would be to 'attack' PGO Edit, and add in features such as add empty blocks, maybe have a tuner, but yeah that would involve some decompiling and that's a far greater PITA than just modifying JSON...  There's likely an API for the Go also, so building up on that could work; likely something like using wireshark to see how Go/Edit communicate together might lead to 'easily' decoding the communication between the 2 devices, but then you'd need to re-implement a GUI from scratch, BUT, yeah, if you could say use the tuner from Go, etc., turn on/off effects, maybe something like having a 'virtual' Go controller; not so much to edit, but maybe just bind some keyboard keys to footswitches, controlling snapshots, etc., could be very cool.  But yeah, that's a lot of hours of work.

[BarkingSpiders]

I'm currently also trying to reverse engineer the firmware (.hxf file), as I'm still trying to be able to rename the amps and stompboxes. I managed to identify various chunks and archive sections, but I don't seem to recognize the used encoding for the various archive sections. If anyone here is interested in helping out, let me know and I'll post my findings on GitHib.

[grdGo33]

On 4/7/2022 at 7:21 AM, BarkingSpiders said:

I'm currently also trying to reverse engineer the firmware (.hxf file), as I'm still trying to be able to rename the amps and stompboxes. I managed to identify various chunks and archive sections, but I don't seem to recognize the used encoding for the various archive sections. If anyone here is interested in helping out, let me know and I'll post my findings on GitHib.

 

How did you manage that?  What language is it even using?  Not sure what you mean for 'archive sections'.   The hxf is the firmware from what I remember right?  Likely is compiled, I know next to nothing about reverse engineering / decompiling / recompiling firmware, but normally, you'd need to decompile, modify the code and then recompile.  Just attempting to make changes to compiled code would likely not work, well, depending on what kind of software/firmware it is...  (pure guess here)

 

The issue also is that every change you make might have repercussions; but yeah if you just change the label of the amp, that should not break anything... in the patches; references by ID seems like;  ex;

@model

:

HD2_AmpPlacaterDirty

but yeah anything else might cause compatibility issues between patches/updates...  Say you hack your firmware, something changes in patches or anything, next L6 firmware versions, will you be stuck and have to apply similar fixes/changes to make your patches compatible with the new firmware?

 

Also, when comes time to pushing to the Go...  Again, far from being an expert, but there's been mentions of bricked units.  Modifying json patches is one thing, but firmware......  Even the patches, there's no guarantee that edited json patches will be compatible/work with next firmware...  It works now, sure, but if L6 makes some changes, who knows if such patches could cause issues ...

 

Even for your 'hacked' firmware, depending on changes/compilation/whatnot, who knows what issues it could cause...  If you know what you're doing, ok fine, but if you're new at this, well, you have to start somewhere I guess lol

[BarkingSpiders]

Thanks for your reply. And I know the risks that are involved with modifying firmware. So first of all I limit it to simply understanding what's going on in that file. If and only if I fully understand the format, would I attempt to modify it.

 

This is what I found yet:

 

https://github.com/MarByteBeep/podgo

 

Feel free to help me out decoding some of the missing parts (indicated with ??).

 

 

[grdGo33]

Wow good job so far!  Sadly, well beyond my competence!

 

Quote

compressed zlib size in bytes (size)

 

Quote

Archive Section Data

The data part of each archive section seems to be obfuscated, compressed and/or encrypted.

 

As it's firmware, I have absolutely no clue what anything would do; without even knowing the language, how it's used to interact with likely proprietary hardware/controllers/whatever, I would be absolutely zero help, really not my cup of tea.   When you're dealing with proprietary software/data, the formatting & bytes can be absolutely anything.  Some as you said delimited by indexes, set lengths, maybe pointers, honestly, I would have no idea how to go about reverse engineering everything ...!

 

Hell, it's firmware, so as far as we know, it's compiled code formatted for Line6 chips, so there's no way to unzip or make any sense out of it other than de-compiling as I said earlier and recompiling...   Just not human readable/manageable data format.

 

Quote

I'm still trying to be able to rename the amps and stompboxes.

 

Honestly,  you get used to the amp names very quickly.  LOL   Making your own custom/hacked firmware just do that.....................     Playing with JSON patches, sure......  But Firmware is on an entirely different plane of existence for difficulty!

[BarkingSpiders]

Haha, for me it's a nice puzzle. The goal is not to decompile the code (MainCode and Boot sections), but to see if I'm able to decode the data sections. My guess is that that should be doable and that in those sections we'd be able to find the various settings (probably in some JSON or BSON format).  But for now I'm just in the dark on the used compression/encoding technique.

[dethioux]

On 4/1/2022 at 10:55 AM, BarkingSpiders said:

 

 

     "footswitch" : {
      "dsp0" : {
       "block0" : {
        "@fs_enabled" : false,
        "@fs_index" : 9,
        "@fs_label" : "Fassel",
        "@fs_ledcolor" : 196619,
        "@fs_momentary" : false,
        "@fs_primary" : true
       }

 

Hi there,

Does anyone know on how to interpret the  "@fs_index" : ? I am trying to figure out a way to retrieve the default FS value for any preset/snapshot however, I have value of  "@fs_index"  higher than 5 or no "footswitch" section at all.

Thank you

P.  

[grdGo33]

By pure coincidence... 

Quote

Did you always want to have Helix Presets on POD GO? Now You CAN! | HELIX TO POD Converter

 

Hello, my name is Marcin and I'm an AI/ML Developer and Guitarist! A few months ago, my friends and I started working on a helix preset converter for POD GO devices. Today we present you a solution that allows you to automatically convert helix settings to pods.

 

https://www.youtube.com/watch?v=OJHfTDFu-Eg

 

BarkingSpiders, is that you? :)