Please ensure Javascript is enabled for purposes of website accessibility Jump to content

Pod Go/Helix Converter


bishopuniverse
 Share

Recommended Posts

I have been working on understanding the Pod Go files and the Helix files so I could determine how to convert between them. I have completed the first draft of the format document that explains the file formats and shows how we could convert between them. The document can be found here

 

For me, the next steps are:

  1. Verification of the information, by creating files and verifying against Helix (I only have the Pod Go).
  2. Creating a conversion document that shows how to convert for each item.
  3. Creating a converter. The convertor would simply "dumb down" a Helix file for Pod Go, and beef up a Pod Go file for Helix.

 

Is this something anyone is interested in? It was a lot of fun, but a lot of work. I would like to know how much interest there is before I go further.

 

(Side note: it looks like steps 4 and 5 could be using Rocksmith to create a presets from your favorite Rocksmith songs.)

 

Thanks for your time. I would love to hear your thoughts.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Wow!  Impressive work.  It got me thinking that trying to reach someone from L6 might be really beneficial.  There really is nothing sensitive about the json patch format imho, and if community tools popped up which allowed to convert helix patches to pod go patches or the such, I'm sure it would be for the benefit of L6; having Go users having access to Helix patches might influence potential buyers to going with Go rather than a competitor.

 

It's even something I'm sure L6 would like to put out; if they had free devs, I'm certain they'd love to offer such tools to their user base.  So if community tools might be a thing, maybe L6 could provide some documentation about the 2 formats; helix and go.

 

BTW, there already exists a Helix patch visualizer:   https://dbagchee.github.io/helix-preset-viewer/

 

Maybe contacting the creator of the above for coop, as if you could collaborate to create an exporter using his reader, that would save you a lot of work and likely improve both projects; harnessing power of the community.

  • Like 1
Link to comment
Share on other sites

  • 8 months later...
  • 2 weeks later...
On 4/8/2023 at 11:08 PM, jonny4rd said:

I'd be willing to pay a nominal fee to developer or crowdsourced solution for similar utility; I'm sure many others would too.   

 

How many though?  It would take a lot of people paying 'nominal' (5? 10? 20? 50? 100?) fees to pay for the dev hours for such a project.

 

The other big problem would be working around the PGO limitations, not sure what would be the value of such converter in most cases;  unless the majority of Helix patches are small and simple enough so that the Go can support them; meaning; DSP, single path, existing effects, etc., the value of partially importing a patch might be marginal, as some patches might not entirely work, or work at all, without all the blocks...

 

And yeah, you would need to factor DSP limitations, blocks, etc.  So there would have to surely be some user input;  ex;  


- 2 paths detected, choose path to use

[ ]  cab1 -> effect 1 -> effect2 -> effect 3

[x]  cab2 -> effect 4 -> effect 5

 

Too many blocks for Go, choose 4 effects to keep

- Distortion1

- Distortion2

- Reverb1

- Reverb2

- Chorus1

- Chorus2

- Delay1

 

Too much DSP for Go, choose 1 effect to remove

- Distortion1

- Reverb1

- Chorus1

- Delay1

 

... So yeah, maybe you'd want to have some built-in alternative effects/presets to mitigate the non-existing PGO effects...  Anyway, really not sure there would be enough PGO users to either fund or develop the feature.. 

  • Like 1
  • Upvote 1
Link to comment
Share on other sites

grdGo33,

I obviously don't have any real numbers to support interest and could in no way predict what it would cost to write such a program.  My point is I think there is just as much of a case for writing the program as there is for not writing a program. If a nominal fee is enough to increase the odds above 50/50 in favor of writing, then I want that to be known.  

 

Someone took the time to build a converter for the HD series and managed to make that work even with DSP and dual signal chain differences for free.   bishopsuniverse has as already laid quite a bit of the groundwork for such a program, again for free.  Moreover, you took an albeit small amount of time, without compensation, to write some problem statements that would need to be overcome in order for the program to work with the helix family.  In some way the crowdsourcing work has already begun. See what I did there. ;) 

 

It also strikes me as interesting that you were such a fan of bishopuniverse's initial post yet seem more critical of my comment; which was my attempt to reinforce your comment.  I'm curious what changed?

 

To further my point, you might also want to check out the opensource Neural Amp Modeler project.  Lots of "free" work being done over there to bring profiling to the masses.  Crowdsourcing works, people solve hard problems and do stuff for "free" all the time.  I

  • Like 1
Link to comment
Share on other sites

Quote

I'm curious what changed?

 

Nothing has changed.  If anyone is interested writing a program for it, go for it!  Could be fun learning experience for someone, could turn out to be a useful app for some.

 

But.  Topic was discussed about like 8 months ago, so apparently very little user interest...   How many people 1) own Pod Go and 2) what % of them would be interested in the app?  And again, realistically, what % of Helix patches would be convertible to Pod Go?   I would question the pertinence of the app given the complexity and limitations of Go..   Btw, we're really talking weeks of full time work here for a decent tool, so basically paying for a meal or a coffee, or I don't know what is 'nominal' in terms of $$$ exactly, would be a tiny amount compared to the work. 

 

Quote

you were such a fan of bishopuniverse's initial post yet seem more critical of my comment; which was my attempt to reinforce your comment.

 

Well yeah as I stated I was impressed by the leg work...  Reverse engineering code or format is hard work.  But L6 could simply release the info...  But even if it did release its doc for the 2 formats, you'd still have tons of issues to solve...  Like again DSP, a user went to the trouble to calculate the costs, it's available, could be used, but integrating it in a user friendly way would be a real challenge.  But even if you solved it, still the # of blocks, lack of dual path, missing effects, etc., Is it really worth the effort?  The Pod Go isn't getting any younger.   I would have no use for such an app, would a lot of people? 

 

I think there already exists other tools which do so much better; doesn't BOSS or something have a sort of tone clone where it'll listen to a song and just 100% replicate the tone?  There's already a visualizer for Helix patches.. 

 

But yeah, think the issue would be that the usefulness of the tool would be very limited, given that likely most Helix patches simply won't fit or won't make any sens on the Pod Go...  But, maybe I'm wrong!  :)

  • Like 1
Link to comment
Share on other sites

Thanks for all the support and great discussion here! (There's also more discussion on the CustomForge Discord channel, for anyone interested).

 

Sorry for dropping this then dropping off the face of the earth. Life suddenly became overwhelming with lots of high demand events crammed into a small timeframe.

 

That being said, things have slowed down. I would love to see this finalized, and I know at least one person had enough interest to ask for special access to the file. If there are coders, people willing to document (such as the Rocksmith tones format from the tools found in the CustomForge Discord), and people willing to try it out on their devices (Pod Go, Helix, etc), I'd be up for participating.

 

I guess the easiest way to see how much traction this has is to just reply to this message with the role you would be willing to participate in. Let's see how that goes. :)

 

We have the information to make this. If we can find the people and the time, we'd have one really badass tool that people like us would love.

 

 

  • Like 2
Link to comment
Share on other sites

On 7/15/2022 at 9:46 AM, silverhead said:

I agree that it’s very practical, right now, to use a Helix preset viewer and manually create the corresponding POD Go preset, within the limitations of the POD Go.
 

Here’s another Helix preset viewer that includes some additional info….

https://hxview.netlify.app

I'm re-posting this with a supportive, not oppositional, intent. For those considering the utility of developing this converter it might help to understand the development cost and overall applicability vs. the alternative quoted above.

 

Try downloading a couple of dozen of the most highly rated Helix presets from Customtone. View them using the above link, and attempt to recreate them manually in POD Go Edit. What percentage of Helix presets can be converted directly, with no decision making? Each time you need to make a compatibility decision (i.e. something in the Helix preset that can't be directly translated to Pod Go) ask yourself how difficult it might be to automate that decision in code. For those that require decisions, what's the likelihood that 'good' decisions can be made (a clear inarguable decision in each case) that doesn't dissatisfy as many people as it satisfies? To what extent would user interaction be required (e.g. a prompting question) to answer key questions?

 

Notes:

- I think Helix presets available for purchase on Helix Marketplace are likely to be more, not less, complex than Customtone presets. If you have access to some Marketplace presets use those too. Using only Customtone presets may leave you with unwarranted optimism if you really want to appeal to users.

- In my days of software development (a long time ago in a Galaxy far. far away...) about 80% of the code in an average software product was dedicated to handling user interaction I/O with the unpredictable user actions. That's probably been reduced by now but I expect it's still the majority of code.

 

This exercise may provide you with some insight to the key question: Is it worth it to develop a converter, or just convert manually for yourself on an ad hoc basis as outlined above?

  • Like 2
Link to comment
Share on other sites

I can’t seem to get this off my mind this morning. It’s like a song that gets into your head and just keeps repeating….

 

If I were to go ahead with development on this I would, like most software development, do it in stages.

 

Phase 1: Compatibility Tester. This first piece of development would take a Helix preset as Input. Output is a Yes/No answer to the question “Is this Helix preset fully compatible with a POD Go preset in all respects: structure and routing, amp/FX block selection, number of snapshots, controller assignments, and any other considerations?” Without this basic capability I don’t think you can do anything meaningful.

 

Phase 2: Compatible Converter. This would follow quickly after Phase 1 and would convert fully compatible Helix presets (inputs) into POD Go presets (outputs).

 

Phase 3: Compatibility Analyzer: This would produce a report that identifies all incompatible elements of a Helix preset that is not fully compatible with a POD Go preset, and provides options and/or recommendations for manual conversion. It provides users with an itemized list of all items in a Helix preset and the manual additions and changes they would need to make using POD Go Edit to get as close as possible to the Helix preset, starting with a POD Go New Preset.

 

Phase 4 and ongoing: General Converter. A series of iterations and product updates that gradually address the automation of the items in the Phase 3 reports, from relatively simple to more difficult. The first iteration would invoke the Phase 2 Compatibility Converter applied to the Phase 3 Compatibility Analyzer, make some clearly identified ’best guess’ decisions, and produce a POD Go preset that could be used as a starting point for further manual edits.

 

EDIT: An afterthought (as it usually is). Don’t forget to factor in ongoing maintenance to this utility. If people are going to pay for it, and for it to remain relevant, it will need to be at least reviewed and usually updated as both Helix and POD Go receive firmware updates.

  • Like 2
Link to comment
Share on other sites

Silverhead, you are correct. This would take some effort. In my mind the coding would be minor compared to the planning and testing.

 

We would need to break all conversions into three options:

  • As Is: This is where the conversions match as is. (This sounds like your Phase 1)
  • Simple: This is where there isn't a match but decisions can be made by the program. (This sounds like Phase 2)
  • Complex: This is one that would require a person to decide what changes to make. This could be done with or without the program making suggestions.

As the models are in JSON, it should be easy to create objects, modify them, then spit the JSON out for the right output. Except for UI and decision making, a lot of the code should be straightforward.

 

However, as you can see by the document I attached, discovery is a big animal. Determining what models exist, how they map to other models, how branches work between models, when users need to be involved in decision making, etc. would be a much bigger piece. Then, testing these mappings on various devices would be a big animal.

 

The plus side is that most anyone can do most of the work here, with just a little bit of direction. Coding would be possibly 25-30% of the total work.

 

The thing I find most intriguing is that CustomForge has done the work of decoding a ton of tones for Rocksmith (Just under 6000). Tapping into that resource to pull tones for Pod Go and Helix seems like a huge win.

 

You are correct, Silverhead: this will be a big undertaking. It would provide access to many tones and convert between models. The good news is anyone who is interested can contribute if they are willing to read JSON and/or spreadsheets and document them. if that sounds valuable to anyone, just reply. If not, no worries.

Link to comment
Share on other sites

Guys, I've been following this thread with interest but I found my self asking some key questions?

 

1. Is there really enough interest to justify the huge work involved? 

2. How would this square the circle re different effects and facilities in Helix that Pod Go doesn't have, especially dual routing/2 amps and 2 cabs at once, that Pod Go currently can't do?  And with more processing power Helix can have much longer signal chains that won't 'convert' to Pod Go.  So if it can't accurately replicate Helix tones, is there any real point?

3. How would this be adaptive to future Helix upgrades eg Helix v3.5 has a new cab engine and amps/cabs that Pod Go doesn't yet have. And even if Line 6 build a version of the new cab engine in Pod Go, it won't be the same version as Helix and it now seems likely that v3.6 Helix will be dropped before v1.5 Pod Go.  Pod Go might fall more and more behind Helix and it will always be a 2nd priority to Helix. 

4. Helix was launched in 2015. That's ultimately an 8 yr old architecture which is now 'old'. We've got to assume that Line 6 is already developing something completely new and its likely that Line 6 will launch something in eg 24 mths.  So will this conversion program be really worth it?

 

  

 

 

  • Upvote 1
Link to comment
Share on other sites

I'd also mention that I have and still use a Vox Tonelab SE and LE.  These are much simpler mfx units from 2004 & 2007 respectively. These used the same modelling architecture and although largely all the amp/fx models were the same there were some differences.  The TLLE was essentially a smaller slightly 'stripped down' version with only a single expression pedal and no A/B amp/cab switching facilities in the same patch.  Although a program was developed to convert patches between each other, the accuracy varied depending on whether the amp/fx were the same or not.  These units had 'fixed DSP' so there were no problems with different processing power. Selections were limited to one option only from each of the amp, cab, delay, reverb, modulation & pedal sections. 

 

My point is that if,even at this much more simplistic level, a patch converter wasn't terribly accurate and not hugely popular or even known about, the problems and variations will be way more complex for Helix/Pod Go. 

Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...