Has there been any thought to including macro capability for widget control?
For instance, a series of fader, switch and/or dial control moves that could be recalled via MIDI trigger.
I know much of that can be scripted currently, but macro recording would be much more accessible to the average user.
It would be quite useful for me.
Would anyone else find that useful?
Has there been any thought to including macro capability for widget control?
Why do you speak from macros? What you explain is equivalent to record a MIDI sequence of MIDI controls. Or did I misunderstood?
For example, Let’s say I had 2 guitar plugin blocks attached to a 4-channel Audio Mixer block, with the volume and pan attached to their own widgets. Let’s also say I’d want to pre-record fader and pan moves that cross-fades the signals from each guitar plugin blocks over a 5 second time period while doing a 5 second L to R pan and engaging the leslie speaker plugin from slow to fast, save it --and then be able to label that recorded macro, and trigger it via widget I set up for Macro control.
OK, I understand you would like to have some kind of widget automation. Probably not the easiest request…
Do you think it needs a separate concept of macro vs having this achieved by using midi to move the widgets? What comes to mind is using Ableton linked with GP. You could draw the midi curves that are mapped to the widgets, and have this as a clip you trigger when needed.
Along with scripting, yes that’s another way to accomplish the task.
The point was, the average user is not going to be that savvy with scripting or using other apps to draw midi curves and link them, but chances are they HAVE used another DAW before, and therefore have been privy to the mix automation that is available in most every other DAW out there.
Recording automation for fader moves, panning etc is very common, and it’s one element that is lacking in GP. Considering GP works best when you assign all MIDI controls to widgets, using rackspaces and variations for changes, it only follows that the automation for all those widgets, rackspaces, and variations should happen on the GP level as well. Automation should not be left to only those who know how to script or link other apps. It’s too common a task for that.
Are you imagining some sort of system plugin (Automation Player) that would give you access to the widgets used in the rackspace and be able to draw time-based automation curves? And then that can be triggered by another widget that you have mapped to a controller?
Correct, the ability to set the automation(whether drawing curves or actually recording fader moves), save it to an (or as an) Automation Block , and then be able to create a widget, assign it to an Automation Block, and trigger that preset like you would any other widget. We do that now, except the widgets trigger static value changes, while the automation would be able to trigger dynamic value changes.
The Automation Block could have many presets assigned to it, where a list would show in the Mapping section in Edit mode, or if that’s too complicated it could be one preset per block. Either way would be great.
I’m also wondering if what you’re describing could be viewed as a morphing/transition from one variation to another. So your current variation is the starting point, and the next variation is the end point. For any widgets that change between these variations you would want to set the timing and curve shape of how it moves from the original value to the new value.
That’s an alternate way of approaching it, and a good idea. It works within the framework of the current infrastructure. Would still need some way to bridge that gap, to save the automation somehow and trigger it. That’s why I was leaning toward an Automation block, since the we already have the framework for assigning widgets to blocks.
For the transition concept, I was thinking of only needing 2 options added to the widget properties: Transition Time (seconds), Transition Shape (same graph as the widget value scale). This would be the settings for transitioning To this widget value.
I think there is no real “timeline” in GP like in a DAW. So recording some widget automation could be tricky. Perhaps that the idea of a per widget transition time between variations could be a nice start. I like the idea.
I understand the usefulness of automation, so as to modulate some parameters over time. This can already be done via scripting using function generators (right now there’s one for ramp, squarewave and an ADSR). Obviously that’s not accessible to everyone but it is a useful way to experiment with features that can later be implemented directed into GP.
However, I’m trying to understand the use case for your specific examples. If I’m on stage playing my guitar or keyboards with a band, how does having automation that is timed (e.g. do this over 5 seconds) when the band could be playing at a different tempo than when that 5 seconds was calculated.) as opposed to using an expression controller (pedal or knob) that is tied to a widget group that changes the parameters under the musician’s direct control?
Like in studio automation, the time-based events suit those who play with the same tempo every time. I play with a metronome click in my ear (at least to start), and my performances are sequenced, and any variations in tempo, whether they be slow downs or speed ups, happen at prescribed times with known exit strategies back into time. Any automation I enable happens on cue and in perfect time, every time.
I do a one man show with many instruments coming in and out, so the less I have to directly monitor and keep track of at any one time, the better. I use ALK2 as my looping/sequencing app, and I perform many automated moves there also. However, GP is the first link in my chain, and is a far more powerful and flexible interface. There are places where I could see one trigger performing numerous series of automated moves to enhance my performance.
In cases where a metronomic playing is not being employed, there are still automated moves that can be used, such as triggered fade in/fade-out sequences, where more than volume moves are part of the sequence. Even the ability to trigger a simple 10 second fade-out or crossfade without a pedal or scripting would be useful.
At any rate, the topic was about more than my own needs. I was thinking more about the overall usability of GP, and how adding some automation to widget behavior could benefit the average user who is daunted by scripting, and expand the reach to those who are used mix automation in their DAW’s.
While GP isn’t a sequenced app, it can used as the link in a chain that ends with sequencing.
I use GP as the first link of my chain for its efficiency and flexibility, which frees up the sequencing portion of my chain to do what it does best. Each song has its tempo and MIDI triggered rackspace/variation changes relayed back to GP from the sequencing app, so it is very much a player in the overall timeline.
Can you use a DAW to send CC messages to Gig Performer?
I am using Ableton Live and with IAC on Mac this wis working perfect.
Yes, I use ALK2 to send both PC and CC messages back to GP to trigger rackspace/variation changes, and trigger widgets. I can certainly perform what I need to, but for those who don’t use multiple apps or scripting, I thought this concept would be useful.
totally ! i can follow you.
I´d personally “envision” such “function block” as a right now (afaik) non existing type of a VST,
a inbetween between of a sampler and a sequenzer, “somehow”.
load your midi sequenzes into that “midi sampler” like we would load one shot drum hits onto the pads of an MPC.
Create those “midi-samples” in a midi sequenzer ( just to start the idea) , import it as a midi file onto pads, similar to a mpc, couple the pads as needed,
give the pads the ability to set up start-delays per “midi-file”, etc.
then, trigger that bunch of “one shot midi events” just with one trigger.
( one thing to note here vs. the aformentioned non existing timeline:
sorry, but “Time” is allways a given thing within our reality
and within music making do we have the BPM aspect too.
Such tool could even have a own tap tempo button, so that preloaded midi automation files could be “mapped” to a tempo that suits the moment as is, just by tapping in the tempo when, and as needed )
( i have layed out such tools in my head allready, just with the purpose to load and send CV-samples ( manually created or recorded CVs from a modularsynth) to my modular.
i used to abuse Battery 4 sometimes for this, sending my CVs out, but ended up also with the wish, that i would want to have groups of events, been triggered at once, and more so, been saved as one file ! …plus having also events been triggered "within the app/VST itself.
There are quite nifty scenarios thinkable)
the scene of the VST makers is probably more hunting to create the things that a mass of people would purchase, rather than delivering to a niche market.
But such a “niche”- tool would imho definitly suit perfectly into what GP allready is !
i don´t know how old GP is, but i see it as a door, opening new horizons, …and not just as a platform for Guitarists who want to replece a stack of amps with a laptop ( no pun intended )
i could see such a tool been made in a way, that it indeed could suit different needs and purposes,
just think in terms of: “trigger activated one shot events” ( as groups)
we humans have just so and so many hands, right ?
so how about to activate some soon to come events with a trigger beeing sent out “a few seconds bevore the events which have to come”, "since the musician might want to use both hands then " ?
sorry, keeping it short is not so my thing (also since i´m not native english)