Oh glad to hear we similar!
I did figure out that if I use a 2 space global… it will sit nicely on the bottom right of the screen real estate. Anything larger needed scrolling on my portable laptop i take to gigs.
Oh glad to hear we similar!
I did figure out that if I use a 2 space global… it will sit nicely on the bottom right of the screen real estate. Anything larger needed scrolling on my portable laptop i take to gigs.
I also might go for a global rackspace, but have to analyze if all my functionality can be used (and exceptions).
I also use a 2 space size at the bottom, and 1 space on top for chords/notes. I also prefer not to scroll as I don’t have a mouse on stage, and no time to control the keypad.
Yes! Exactly. There is no time to mouse on stage.
As a test… I will try the new ‘scrollFrontPanel’ feature in Systems Actions. so far so good in testing at home. (for using with touchscreen laptop) I assume i could even map it to a hardware slider on the midi controller.

I started with something similar but then decided to add my most used instruments into the global rackspace and make the controls available to other rackspaces via the Global Parameter Assignment function.
As a result, when I open the global rackspace from the bottom, it comes up too high as there are a bunch of RU spaces taken up in it. It would be great if there was an option to limit that to 2U, so I can just show the top 2U panel, which I could use for some global widget functions for each rackspace and still have enough space for my individual rackspace’s panel
I’m curious - why so many? Do you really need to change so many parameters in real time during a show?
I’m glad you found a solution that works best for you ![]()
Btw, I"m using a generic panel I copy to each rackspace, and this contains 42 widgets:
Then I have a chord widget and note widget, and typically 0 - 10 rack specific widgets, but 80-100 seems a lot.
I generally have an average of about 3, but very occasionally it can go as high as 15
I just want to understand why some users have so many widgets — i.e, what they’re wanting to do, etc.
Helps to make the product better.
Instead of having to copy and remap controls/plugins to widgets for the audio mixer and in 30% of cases a hammond, I’m using a template rackspace which is flexible enough to be used in all rackspaces.
Another reason that I use somewhat double the amount of widgets is that I like to control it with both my MIDI food pedal, but also as alternative directly from my keyboard.
In my current setup, I’m trying to use as many instruments in the global rackspace, so I can conserve system resources and just use variations to change parameters in the global rackspace for different songs.
For instance, I have one instance of Pianoteq loaded in the global rackspace. When I need a piano sound, I add widgets in the local rackspace to change certain parameters on the global rackspace like midi channel, max and min midi range, FX levels, EQ, Volume, etc.
This allows me to customize the sound a bit for each rackspace/variation I create, but not duplicate the VST all over the system. And any non mapped parameters of that sound can be set and changed for any variation.
In the past, using my Kronos, I ended up changing something on one patch and then had to update all of my combis to match the new piano sound.
As a cover band keyboard player, I have a lot of sounds and songs to create patches for, so I end up having one for every song, but I’m hoping to use the global rackspace to consolidate some of the most used sounds and help them be more consistent from song to song with minor changes as needed.
That said, even with about 8 instruments in the global rackspace, I’m finding I need to link a bunch of widgets to the Global Parameter Assignment which then need to be added to various rackspaces when that sound is needed. I was going to ask if that parameter assignment limit is hard set or can be increased, as I can see myself using the current available 128 spots eventually
You don’t get problems with some plugins using CPU even when not used or do you bypass them?
I also came from a Kronos … guess people owned a Kronos are used to a lot of flexibility and they want to mimic that in GP
So far, I think it’s working well, even I can now do a lot more especially regarding controller flexibility.
Ah ok - thanks for the explanation - yes, I’m familiar with modular systems (I’m old!) though I must admit that given my first synth was an AKS Synthi I still have a preference for matrix patching rather than cables ![]()
Thanks for the explanation.
Currently, I’m disabling Note On for their Midi Blocks and most of them are Physical Modeling instruments that use very little CPU when loaded but not playing. This may change as I use more sounds in GP vs my Kronos sounds, but I also plan on eventually upgrading the M1 Mac I’m using if needed. Still way cheaper than getting a new/used Kronos!
Not sure if I would like bypassing (and forgetting to switch them on in time).
But my (not that high end) laptop still keeps up (or I just use different sounds when I get towards 100% CPU).
What buffer size are you using?
I changed it to 128 (it was 192), and 44.1 KHz … I found one rackspace that I think I heard a few glitches, but couldn’t reproduce it (unless I played more keys than I typically do for that song).
@dhj
About the number of widgets (see my post above), where I calculate I have 42 widgets now … I’m intending to add level metering for each channel, including peak indication, this will result in 2 level meters, 2 sliders to be able to use it in gscript, and 2 widgets to show if the peak is reached, meaning 6 per channel, so 48 extra widgets, resulting in 90 in total … and probably I will find more features I want to build in ![]()
I control a 32 GP Mixer plugin with widgets and it makes quickly more than 3 widgets… I don’t control them manually when playing live, I use them in variations and shortly with an EXP pedal too.
Did the copy widget with mapping ever make it into the product? I am wondering about the copy widget from 1 rack space and pasting to another rack space. I seem to remember there was some key to press during the copy that would retain the mapping of the widget. (Or maybe I dreamt this)……