And yet another Forte user

So wow, just found out Brainspawn was no longer. I guess it was some testament to its reliability and utility to me that I have been happily working away, unaware. Can anyone tell me what happened?, as the site seems down completely at this point, what were the last words, if any?

Anyway, I am quite happy to find myself here at GP, already being detained and distracted by a different thread on Controllers. More importantly I do have some questions about GP. I have taken some time to read the manual and checked out videos. In fact I had an initial moment of panic when the video “Gig Performer 2 - Main Features” only mentioned clicking in the software, stepping through with a MIDI pedal and using a touchpad as ways to change racks. But in the manual it of course also mentions MIDI PC messages. And it sounds like PC #s can be assigned to variations as well.

Ok so, here is my situation, I’m not doing “songs” or “setlists” … I have about 8 vsts and a couple of FX plugins and have various configurations of all of those that I want to be able to just call up with a program change message. Maybe one configuration is everything off/muted? except for VB3 and I thus have virtual dual manual B3. Another just has a Rhodes on for my bottom keyboard and a Prophet 5 for the top keyboard, with both going into an FX. And so on. So, it sounds like maybe just making one rack and using variations assigned to MIDI PC messages is the way to go?

I want the settings to be same basic setting every time i send the PC #. However I do need to be able to send program messages to the various vsts and FX when they are active, separately from the program change messages being sent to GP for the variations.

Also by chance, does Novation Automap map to the widgets? That would be awesome.

Appreciate the help!

Hi,

I am just wondering what you mean by not doing “Songs” or Setlists.
In my bands I am using rackspaces and variations.
Most of the rackspaces represent 1 song, but this not necessarily the case.

In your use case I would build rackspaces with variations for the sounds you need for a song or
whatever you call it.

The only thing that should be controlled by incoming PC messages is switch to specific rackspaces
or Variations.
I would not change presets of your vst with incoming PC messages.
The advantage with this concept is, when you change a vst and the needed program change is totally differnt - it does not matter, as the used state of the plugin is part of the rackspace.

Hope this suggestion helps.

@LilyM First of all, I would encourage you to read the blog article on our site that was written by another ex-Forte user, he does a great job of explaining the workflow differences between Forte and Gig Performer.
https://www.gigperformer.com/what-brainspawn-forte-users-should-know-about-gig-performer

Secondly, although we do support the ability to send program changes to VSTs, we really only added that mechanism to handle some legacy issues. We strongly encourage users to embrace the modern way to handle plugins using rackspaces to control sounds instead of trying to make GIg Performer behave like older MIDI-centric applications.
There is another blog article on our site that discusses this topic and while it does explain how to do what you want, it explains in more detail why you shouldn’t do it that way :slight_smile:
https://www.gigperformer.com/rackspaces-vs-program-changes

Automap is vaguely irrelevant for Gig Performer. Just configure the keyboard to send out regular CC messages from the sliders/knobs on your controller and then GP widgets will be able to respond to them. You will then associate GP widgets with plugin parameters using host automation.

ok, my experience has been that most people seem to be using this kind of software in a more sequential way, as evidenced by GP’s predictive loading… stepping through “rack spaces” “scenes” or whatever for a song and or set list. I don’t work in any sort of sequential way, I just need various configurations of my plugins available at the press of a button… so, as I mentioned originally, these configurations could be piano on bottom keyboard, single manual B3 on top keyboard, Dual manual B3, Rhodes on bottom, with layer of MiniV and Diva on top, and so on.

My workflow with this is determined more by my physical keyboards and the demands of the music I play than any old fashioned MIDIcentric approach. My bottom keyboard is a CP300 with 16 buttons I can use for PC messages (yes there are additional banks, but I find that too fiddly on stage). So I have 16 basic configurations (as I have been calling them) and that works for me. I then use PC messages from my top keyboard to change patches on vsts and FX in those configurations. This works real well for me.

I like this hierarchical approach. It sounds like I can probably still do this with GP…with rackspaces being what I call configurations, and the variations being my ability to change patches within those configurations. However I still don’t quite get it, particularly this passage… If you create multiple variations and the knob position is different in each variation, then every time you switch variations, a program change MIDI event can be sent out. Can’t the variations already HAVE the different patch or patches in the vsts therein? That being the variation?

Automap provides two way communication, so the LED s on the buttons and 8 encoders on my controller actually change to reflect any changes in the vst (say you changed patches or rackspaces). A small thing and doesn’t include the faders, but ideally I’d love to just be looking at my keyboard, rather than at my laptop screen. But the widgets seem cool ( I had looked into Blue Cat Remote Control trying to do something similar) so maybe I’ll like that.

One last question, i also need to control volume of vsts in two ways in some of my configurations. So that I can change the usual volume of the vst (CC#7) but also control the overall output of that independently… if that makes sense. I think there is something about a mixer that will allow me to do this?

Predictive loading is intended for when a user doesn’t have enough RAM to hold everything in one go.

Understood – but in Gig Performer, you would generally have each of those configurations in its own rackspace which gives you instant switching. When you send program changes to plugins, there’s no guarantee as to how long it will take for the plugin to respond to the change.

Variations only store widget values. They do not store the entire state of the plugin (for the same reason as above, you wouldn’t be able to get instantaneous switching. The intent of variations is to allow changes such as

  • Turn phaser on and turn flanger off simultaneously
  • Change the depth of the flanger
  • Change the cutoff frequency of some plugin filter

Now having said that, you can most certainly associate a widget with the PC parameter of a MidiIn block and configure it so that as you switch from one variation to another, the widget will send out a program change to a connected plugin. (The link in my earlier post shows how to do that) We just can’t guarantee how long it will take the plugin to change over.

Built-in control surface support is coming but you can use GP Script and some callbacks to implement this now in Gig Performer.

And as I was trying to explain earlier, you should not be doing that. Instead, you should be using the plugin’s host automation support for such things. For example, if you look at the image below, I have a widget that is being controlled by a slider on an Arturia keyboard. That slider happens to send out CC68 but we don’t care about that. The widget is associated with the Master Volume parameter of the FM8 via host automation.
The critical point here being that one no longer has to be concerned with sending the “correct” CC values to a plugin from the outside world. That stuff gets isolated so you just focus on

  • Physical device controls a widget using some MIDI message that is learned
  • Plugin parameter is controlled by the widget, typically by learning the host automation parameter.

Actual CC numbers become completely irrelevant inside of Gig Performer with the sole exception of CC64 which is used for sustain along with our Patch Persist feature. And at some point, we’ll make that learnable as well.

Understood… the point was that the functioning of predictive loading is based on the idea that people are generally working in a sequential manner, using the rackspace right near the previous one, no? From the manual… However, in many if not most live situations, musicians tend to follow a setlist.

I was trying to convey the idea that I do not work at all in that manner. It is a much more improvisational situation and I probably have some different needs and priorities than many, if not most, as you say. It just will not work at all for me to have 100 or more rackspaces to maneuver amongst, to cover all the possibilities I want to have at my fingertips. A hierarchical approach is the only way I can see that will work for me. So I will have to see if your workaround with variations sending out PC messages will work for me.

Again, understood. I should not have used CC#7… the point was I need two ways to address the volume of the vst… the Master Volume parameter of the vst as well as another volume control after that. And as I write this I realize there is probably a volume fader plugin that I could insert before the audio out in the rackspace chain. But I had been wondering if there was easy way to do that within GP.

I would certainly look forward to that!

If you connect the output of your VST plugin to a GP Gain Control plugin (or if you want to use more than one plugin, then a GP AudioMixer plugin), the gain control sliders of that plugin can be controlled by widgets (just like any other plugin) and your widgets can be controlled by some arbitrary external MIDI device as well.

That’s pretty easy.

No, there are two benefits to predictive loading. Both are intended to support arbitrary numbers of rackspaces.
If you want instant switching, then the automatic loading/unloading of rackspaces that are “near” is important. On the other hand, if you don’t care about instant switching, you can most certainly click on an arbitrary rackspace “far away” and that rackspace will be loaded, it just might take a few seconds (depending on what’s needed by the rackspace)

That’s not a workaround — it was specifically intended for to allow patches to be changed from variations with the understanding that GP has no control over how long it will take for a plugin to respond to a patch change.

ok, I’m sorry. I don’t know why we are seeing this from such different perspectives. I am not addressing the benefits of predictive loading. Is “benefits” really the word you mean there? You seem to be saying the two benefits are you can use it or not use it. Anyway my point was that the way predictive loading works is based upon the idea that the user will most likely be using an adjacent rackspace next. Sure you don’t have to use it.

And as I think I have made clear, I would not be able to use it. My workflow just seems to be very different from most, much less predetermined. So I have to see how long these rackspace changes will take for my situation. And how well using the variations to send PCs to vsts works for me. You may not consider it a workraround, but it feels like a workaround for me. But I am willing to give it a try. It does seem like I will lose the ability to scroll through the plugin presets, but perhaps that widget knob I have assigned the PC message to in the variation can also be controlled in real time, sending out PCs sequentially as the knob is turned up and down?

Again I am sorry we seem to be somewhat at loggerheads about this. I appreciate and respect the great support and help you seem to give here on the forums…and to me. I understand change can be hard… and maybe I’m just not getting it. I never thought much about Forte, it just did exactly what I needed (except I was unable to send PCs to FX). I think all of my vsts were preloaded, so when I changed “scenes” in Forte it was instantaneous. (I understand for people who used a real lot of vsts that could get cumbersome but no problem for me). So I easily and quickly changed to different configurations of my plugins… some on, some off/muted, etc.My bottom keyboard sent PCs to Forte to change those configurations in Forte…and my top keyboard sent PCs to the plugin presets (could also be done with MIDI channels and so on). That’s pretty much it… Of course there is also the real time controls…and I really like the widgets and visual representation in GP for that. I will try the trial as soon as I have some time free…and hopefully it will all work just fine. I think I know now at least how I have to proceed in GP for my needs in setting up the trial, so thank you very much for the help.

Yes and that is the case in GP as well if you’re not using Predictive Loading but when you switch from one rackspace to another, plugins are disabled so as not to use any CPU. That basically means you can have more plugins available for instant use than if you have everything in one rackspace.
There are two benefits to Predictive Loading. The first is that by reducing the number of plugins that are actually loaded, you reduce RAM requirements significantly. You can still go to any rackspace you want but you might have to wait for a plugin to load. The second benefit is taking advantage of “proximity” to preload (and unload) rackspaces so you can get the benefit of instant switching, which you correctly note is aimed at users following a setlist.

Don’t be sorry - these are useful conversations. You can absolutely use Gig Performer the way you used to use Forte. I was simply trying to point out that there are other ways to use it that might be beneficial.

Variations are normally used to switch multiple parameters of plugins in real time. You can absolutely have a widget in a variation, connected to a MidiIn Block which you then connect to your plugin and that widget can use parameter 155 (host automation again) to cause the MidiIn Block to send a Program Change to a connected plugin. If you create multiple variations and adjust that widget for a different PC in each variation, it will do exactly what you want as you switch variations. It’s not a workaround, it is the way one uses host automation to control plugins. It’s the exact same mechanism used to control the volume of the FM synth that I mentioned earlier. In this case we are just using host automation to control the PC message generator of a MIDI In Block. You could generate arbitrary CCs as well and send them to the plugin. It’s just generally better and faster to use host automation when you can.

screenshot_3060

I think you’ll find GP can accommodate your needs with ease.

ok great, thanks so much. But just to be clear, I can not use that same scenario… a widget connected to a MIDI block in, sending PC messages to connected plug in, in real time? And or sending a range of PC #s as the widget/knob is turned.

Why can you not use that scenario? Do you just want to send program changes directly from your keyboard? You can certainly do that as well.

ok, wow, I most definitely misunderstood . I guess you were just suggesting a possibly better way to handle send PCs… with the variations… I thought that was the only way. Very glad to hear this.

Any PCs thst you send into Gig Performer will be passed through to the plugin if there is no rackspace with the same PC.

I totally feel your discomfort with how GP manages plugin presets in racks vs variations. See my reply in a related thread: Duplicated rackspace that differs only in the preset loaded into a plugin