grdGo33

Wow........ How dare they post a schematic.............. Must threaten legal action!

The Pod Go will work on its own but yeah if you wan to interact with it from a PC you'll need to install software; https://line6.com/software/

Also, with the multi function described above, more realistically; you could have ex; S1 = overdrive/clean S2 = chorus on /off + low settings S3 = reverb on/off + low settings S4 = delay on/off + low settings S5 = high settings for chorus + reverb + delay settings (doesn't on/off, just changes parameters) S6 = wah or boost or whatever That way, you could say hit S1, heavy drive, press S4 to engage delay, then hit S5 to boost it. Then hit S3 to engage reverb with low settings and hit S4 to disable delay, then later S5 to boost the reverb, etc. Then hit S3 twice to reset the reverb to low reverb settings. You could probably do some neat stuff using similar techniques. But then again, KISS is very likely the way to go. You should question the necessity of going with a more complex setup like this... But yeah, doesn't seem that bad, seems like it would be usable and useful!

Hard to understand your post. Would have been easier with notation Switch 1 = xyz Switch 2 = xyz2 etc. The way I see it, sure, the Go is limited, but what you're trying to do seems unreasonable. You can setup 4 snapshots, so you can theoretically setup 4 'sounds'; a sound for the verse, chorus, solo and maybe bridge or intro or whatever. That seems pretty reasonable... If you want more, you could probably bind the expression pedal to ex; delay length, % of chorus, drive, etc., which could likely give you an extra way to configure your sound per snapshot. Think that should work. But also, you can assign multiple functions to 1 switch 1st switch: 6/10 drive + reverb 50% 2nd switch: 7/10 drive + reverb 30% + chorus on with 50% 3rd switch: 3/10 drive + reverb off + chorus on with 70% 4th switch: reverb on + reverb 60% + chorus 50% So you can press 2nd then 4th and it just applies the binded values, giving you multiple ways of managing effects; like turning on/off and adjusting values without resetting everything 'per view' as per snapshots. Pressing 1 then 3 would give very different results than pressing 1 then 2 then 4 then 3. But then ........ I guess if you workout a system where that works better than snapshots....... But yeah seems like it would just be confusing and just things much more complicated than they should be, for maybe not a whole lot of practical gains. KISS = Keep It Simple Stupid.

Don't have the link, but you can try to reset the unit to factor settings, but if it's 'bricked'; not visible by USB because it crashed at startup, there's also a key shortcut to start the unit in debug mode by pressing some buttons during startup, you could give that a try, it if boots up, maybe you'll have some luck restoring factory settings or something. Been reading the forums for a while, and I think you're the 1st case of white screen I've seen here yet.

Wow good job so far! Sadly, well beyond my competence! 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. 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!

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

What are you comparing? Same amp vs same amp? Different amps behave differently, so unless you're comparing the same amps... Also, don't forget that with Go you're not emulating a guitar cab, you're emulating a recorded guitar cab, so you're not going to get the same results as the same amp + cab in a room. You'd be getting the same results as the same amp + cab as if you were recording it given a particular microphone. Also you may be experiencing placebo. Lots of blind tests (ex; https://www.youtube.com/results?search_query=helix+blind+test+) illustrate that the sounds are typically very very close. Very experienced guitar players can usually still tell the differences, but I'm not sure most guitar players could. Sure, most would likely claim that they could. But under blind conditions, I'm pretty sure many would be surprised that what they thought they perceived turned out to be placebo.

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.

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. 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. 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.

Yeah normally the IR needs to be in a particular slot to work, as described in the patch description. I don't recall if the Go validates just the slot # or if there is also the IR name saved in the patch, and if both don't concord, error message. Either way, if the correct IR is on the right IR slot, and when you open the patch you can see that the correct IR is selected, just saving the patch should fix the issue, and if it isn't the correct IR, just select the right one and save. If you don't have dozens of patches to fix, just fixing them manually would be faster than wasting more time looking to fix/troubleshoot the issue!

Normally you'd want a guitar amplifier with FX in/out and connect with 4 cable method, but yours doesn't seem to have FX loop... With 4 CM you use your amp's Amp section using the Go's FX out/in, so your amp is in the right spot of your chain) Or, you could connect to a sound system, something like stereo sound system, studio monitors, FRFR speaker, etc.! But yeah, you're getting double amp and double cab with the Go blocks on, and if your amp has any distortion then all Go effects will also get distorted... But it should still work, if you're getting 'buzzy' sounds, it could be indicative of an issue, but no idea really what 'buzzy sounds' is exactly so couldn't really tell you! Make sure to run your amp as clean and neutral as possible, and you could try also just using the Go's Amp section and bypass the cab section, since you're using your real cab.

It doesn't really work that way. Create patches for use with an amp. Create patches for use without an amp. Why would it not work that way? 4 cable method = amp passes through FX loop no? So you can run with that and disable the IR/cab and the amp, since you're getting your 'amp' sound from the amp, and the 'cab' sound from the cab, you'd be fine. Then when you want you can turn off your FX Loop block; bypassing the amp, and activate the Go's amp and cab. So yeah it should work that way, I don't see why it shouldn't!

you can set your FX Loop block at the end of the chain, and connect guitar -> Go -> Go FX out -> Looper pedal -> Go FX in -> Go -> amp or whatever or you can connect your looper at the end of your physical chain; guitar -> Go -> Looper -> Amp.

Plus, if you're sitting down, you'll be able to use both the Go's wah plus your Vox wah at the same time using both feet, giving you double wah, the wahssibilites will then be endless!!