TWO POSSIBLE HOTSWITCH PROGRAMMING BUGS IN BOTH H9 AND SPACE ALGORITHMS
Hi. Please see the attached jpeg demonstrating two possible hotswitch bugs. For a long time I’ve noticed what seemed to be random hotswitch programming errors, but the attached jpeg shows that quirks exists but they are not random. They confused me for a very long time and after looking at the manual, I can’t believe this is considered normal. The same issues arise in Space and H9 algos and whether the presets changes are made to presets dragged into a new list or copied and pasted into a new list. I am running H9 control on Windows 10. Thanks.
Hi
#1 is not an issue. When you program the hotswitch mapping, it doesn’t remove the existing mappings automatically. Otherwise, it would confuse users if all old mappings are gone when they program new mappings. So what you noticed was correct. If you’d like to remove old mappings, you can either right click the HotSwitch button to remove all existing mappings or double click the knob/parameter that you’d like to remove mapping from.
#2 is not reproducable on my computer. When I program HotSwitch for all knobs, their existing Ribbon/HotKnob mappings are not affected. Could you please try it again? Maybe you right clicked the ribbon and removed the ribbon mappings accidentally?
Let me know. Thank you!
Thanks for the prompt response bohan.
#1 Not removing the mappings might avoid one source of confusion but it causes another. I note that this topic is not covered in the manual (at least the part I looked at). So these details are left to inference and assumptions developed from usage. And that’s fine.
FWIW here was my thought process: Whatever I see after long-pressing the hotswitch is the starting point. The existence of possible hidden mappings didn’t/doesn’t seem reasonable so that didn’t occur to me until I specifically tried to test and deduce source of my confusion (after many many frustrating efforts).
It seems to me that the problem is not in maintaining prior mappings, but in hiding them after long-pressing the hotswitch. Why not display the prior mappings upon long-pressing the hotswitch? That way the starting point is always totally unambiguous.
#2 My apologies for the confusion. In this case I intentionally removed the blue range values but inadvertently changing or eliminating them happens to me fairly often. The aspect that surprised me is that it is possible to change/remove those ranges for the primary present sound when programming the hotswitch. I guess this arises from my assumption that whatever happens after I long-press the hotswitch applies to the hotswitch mapping sound. Thus, after long-pressing the hotswitch I shouldn’t have an ability to make any changes to the primary sound (intentionally or accidentally) until I exit the hotswitch mapping. That would prevent inadvertent errors from arising.
By way of background/explanation, I’ll say that I often use the ribbon controller and hotswitch for radically different sounds, not just one-parameter tweaks. It’s easy to get confused when trying to vary 6-8 parameters for each, especially when switching back and forth to zero them all in.
Whether or not you make changes, thanks for looking into my concerns. ~Tony
P.S. I know it’s a lost cause to mention it but we really do need ribbon control of the output fader. :o)
