A little longer read, maybe
@Digital Igloo could sort of take notice...
So, global blocks. AKA "the never ending story".
I kinda "hacked" global blocks into the Helix Floor, using my Behringer (I know, I know...) BCR2000 (a MIDI knob controller, actually one of Behringers genuine designs).
I was setting up all parameters I wanted to control "globally" via MIDI learn, so they were mapped to the encoders of the Behringer.
I would then copy that very patch and would/could change everything but the blocks under global control (could of course have changed them as well, but that'd be against the purpose of all that).
Note: My main incentive behind all that wasn't originally to achieve global block functionality but I simply wanted to control the most relevant things via always-available-and-in-reach hardware knobs (I planned to mount the BCR on a stand). Global blocks only turned out to be a neat side effect (at least I hoped so... read below).
Now, as we all know, once you switch patches, all settings made in patch A aren't reflected in patch B. This is where the BCR comes into play as it has a "send all parameter values" function. I would then just call up that command and *blam*, the settings would just reflect all changes made on the BCR - which was all I needed to adjust my patches to accomodate the situation anyway.
With this hack, any patch change on the Helix would've required to also perform the "send all values" on the BCR, but that would've been less of an issue for me as I'd only have to do so between songs (I'd never switch a patch within a song at all), so a kinda minor hassle, just that you have to remember doing so.
I can assure you that this was working marvellously well. Just that it wasn't.
Apart from having to carry the rather bulky BCR with me and having to mount/place it somewhere, the main reason why I ended up not using this approach was that all parameters controlled via MIDI automatically also became a victim of snapshot control. But snapshots by then had become an integral part of my patch organisation already, something that I didn't want to miss anymore (none of the snapshot recall modes would adress the problem). Now, there's been a FW update finally allowing you to decouple snapshot control from MIDI controller assignments, but unfortunately that update arrived when I had already traded my Floor for a Stomp, on which I didn't need the function anymore (I fooled around with it that way, though, this time using a tablet and TouchOSC).
Why am I writing all this? Because:
1) If a mere amateur hack such as me is able to kinda mimic global blocks, it shouldn't be too tough for some clever programmer's minds to implement it straight inside the unit.
2) The way I did it is actually a way that would adress some of the issues I'm having with the way Boss implements things.
Regarding (2): Think about the BCR I was using as the "global block layer". Copying patches and fooling around with their parameters would not directly affect any other patches at all. It'd only do so once I performed the "send all values" function after a patch change - which, should this function be implemented on the unit, would always only be performed automatically in case the patch called up would be part of that "global layer group" (in lack of better words). As soon as it wasn't assigned to that global group anymore, it'd behave just like any other patch, changes made would only be made for that very patch.
This would adress the main issue I could see coming up with any global block implementation (namely to accidentally destroy other patches) quite nicely. Obviously, there needed to be a decent way to index patches as being part of a global group. Which is why I think that they shouldn't really be truly global but needed to be added to a group/bank/control-layer or whatever you may call it.
Needless to say, there's some things not covered by this "method" yet, but I could easily think of some. For instance, one might want to have more than one global group. Had I used the BCR, a new patch on that one would've represented a new group.
Also, people might perhaps want to just use one global block of group 1 here and another global block of group 2 in the same patch. That's something Boss allows for - but I'd personally rather trash that idea. For me, the purposes of global blocks are not demanding anything like that.
So, what's those purposes?
Pretty much all of the reasons for me to use global blocks are live playing related. But within that realm, there's some different use cases.
- I for one only ever need two main amp "channels" per each gig (basically a clean and a dirty one). That's what my little brain is able to deal with properly. I will then slap various dirt boxes and what not in front of those to get different flavours. And I want these to be controlled globally, throughout all patches I may use on any single gig.
The reason being quite simple: You often just can't pre-program everything so well at home (or on rehearsals) that it would work in any situation. The two parameters I very, very often find myself adjusting during soundchecks (and sometimes inmidst gigs) would be channel volume and treble. Add ocassional tweakings of other tonestack parameters to that. And I want those adjustments to be valid for all patches. Just every bit the same as people are dealing with their analog amps since eons.
Same goes for dirt pedals.
I actually happen to think of this as being one of *the* main reasons for programmable setups to not work too well in many live situations. You simply can't adjust and re-save 7 clean and 13 dirt patches during a single soundcheck, especially in case you want the same (and multiple) tweaks to be applied to all of them. Only to find out you did too much during the first song. With a real amp, I'd lower the treble and raise the channel volume and be done. And could instantly reverse the process while holding a chord/note inmidst a song.
- You could use the very same thing for things such as overall delay/reverb balancing. You just need less overall reverb in a highly reflective environment (to put it very simple). Or you might just end up in a spacey jam and want to raise your delay mix.
- You might want to use the same patches programmed for fullrange monitoring through the return of an amp. So the least thing you want to do is to completely disable all cab simulations (and possibly the power amp simulations, too, if accessible separately).
- You might want to use the same patches in various routing scenarios. Maybe you wanted to go wet/dry/wet all of a sudden. In case signal splitters and output routings were part of global blocks, you could do that (change splitters and/or output routing, change delays/verbs to 100% wet). Same applies for situations when you might have to use an amp return for monitoring (see last point) but still send the cab simulated version to the FOH.
- On the OG Helix, it would've allowed you to utilize the gapless/spillover switching much more easily. Instead of building a "tough to reverse engineer" kitchen sink preset (just because you wanted spillovers and such), you could as well split the load to two patches while still being able to control all relevant things throughout the two patches.
Phew, guess that was it for now. Thanks for reading (if you did).
TL;DR: There's no real TL;DR. You're either not interested in global blocks or know everything about them already.
