Copy widget... with mapping?

Your project looks very similar to what I made, but I copy everything. I like that panic button, I also want one to be always accessible :slight_smile:

Anyway, may layout is very much like yours, but I couldn’t find a way to use the global rack space, as I need also rackspace specific plugins to have access (although I got some clues from somehow that it’s possible, but didn’t try yet, I will optimize later).

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.

1 Like

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.

image

1 Like

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

Thanks ! No. in my case are sripts Not a solution !

first: i can´t script ! no chance / and no chance to sit down and learn it, since my PC time is allready to high,…and dealing with a breaking health.
second: i had me some scripts written for me, professionally.
i need to keep the script thing blank for those scripts !
…“my” potential for confusions is other wise too high ! ( since i can´t script)

the “map widgets by new” is finally doable. I mean, it is allready quite quick.
enhacement would be the workflow, …saving time.

my racks have quite quick around 80-100 widgets involved btw.
Nowadays, numbers seem to go up to above 140 Widgets in busy Racks, lol
writing scripts would be here something workloady too, i´d figure

1 Like

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 :slight_smile:

Btw, I"m using a generic panel I copy to each rackspace, and this contains 42 widgets:

  • 9 for hammond drawbars
  • 3 for hammond drive, rotator speed slow/fast
  • 1 for toggling between hammond and audio sliders
  • 8 for 8 audio channels volume
  • 1 for master volume
  • 4 shape rectangles for a nice layout for the above widgets
  • 8 expression pedal widgets (as I need to control 4 channels)
  • 8 knobs (to control as alternatives for the expression pedals)

Then I have a chord widget and note widget, and typically 0 - 10 rack specific widgets, but 80-100 seems a lot.

2 Likes

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.

2 Likes

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

1 Like

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 :slight_smile: So far, I think it’s working well, even I can now do a lot more especially regarding controller flexibility.

going completly OT, answering vs. Davids curiosity :wink:

i understand your curiosity !
i have to open a own discussion on that matter at some point.
I´d say, there is something to discuss :wink:
in short: different usecases ! (which would be point of discussion / cause: it leeds to different forms how we would deal with GP)

David, you know eurorack modular, do you ? (you mentioned it)
I use GP like it was the blank frame for an eurorack synth.
the plugins, mainly the FX -and the GP internals for routing- are the “modules” i do “patch” with.
GP has turned my PC into a plugin based -kind of a- modularsynth :joy:

i do NOT play in band context ( while i have been a bandcontext musician bevore my accident. / Bassist. Had to quit afterwards)

what i do is the “realtime-play” thing.
I do quasi “realtime-play sounddesign”, sort of patches.
Think of Stephan Schmitts C-15 synth. What he has created within that synth, thats what i do within GP…we share same thinking shemes. ( just that i can´t programm in Reaktor)

My modular has around 900 Hardware knobs.
and a patch would consist of so and so many knobs that are relevant for a “performance” (home - jam)
I do same with GP, just now based on playing keyboard.
…and by mapping all relevant knobs to my HW controls.
So, i´m very much used to deal wit complex HW control setups :wink:
(key is: repeat ever and ever same thinking shemes)

also:
my patches have options inclouded.
i can mute (CPU-bypass quasi everything, or most of my FX,…and also mostoften all instruments)
So, one patch can be this, or it can be that.
I can use the different “FX thematics” each on its own, or combine them.
Fact is also: ALOTS of my widgets/mappings is vs. “Audio Routing options” !
there is ALOTS of Audio routings involved in my patches.

and no, so far i´m not on stage with this (keyboardplaying). (starts with: i have no car)
But my patches have reached a level, where “nice” -improvised- One man shows would become possible. I can do with GP stunnings things.
Ofcourse also thanks to todays plugin FX power. which is just insane ! to say the least.

sorry for OT !

not shure to whom this was going.

yes, i made it a habit to just bypass everything.
as much as possible automated, based on how i set some other controls.
volume faders vs. instruments on mixers.
or SEND levels vs. FX, where appropriate.
or otherwise, combine the bypass with a wet-dry control, or another control,
like drive vs. a Saturation plugin.
in short: whnever a HW control sets a plugin to do nothing, or not adding anything to the sound: bypass.
( not feasable in all situations / its not allways possible to avoid clicks)

i use to organise my FX mostly based on using SEND + mix. ( everything delay and Reverb)
so the bypass happens vs. the send.

instruments i organise based on setting up crossfades.
using a 4CH mixer.
if i mix 4 instruments, i would usually prefer to have a series of crossfaders.
2x2 for a grouping of 2x2 instruments, plus a third crossfader.
This type of setup is for me way easier to adjust/ or to jam with,
vs. having 4 instruments each on a own fader

GP allows here for tricks, not doable in any DAW, i would guess.
or very cumbersome to setup.
bypassing plugins is more than gold worth.
it opens up new doors

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 :slight_smile:

Thanks for the explanation.

2 Likes

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!

2 Likes

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 :slight_smile: