Hi folks,
I am currently demoing GP and I’m having a good time with it so far. Good job! I enjoy how much it is like PD and Max. I have a few questions/issues/feature requests-perhaps some of these I have missed how to do what I want to do:
Please give us a way to sort our plug-ins in a way other than just by vendor. I have come to truly appreciate being able to create my own folders for VSTs based on function in Cubase (Compressors, Filters, Synths, etc). It makes life so much easier and faster than trying to remember the name of some company that made the plugin you are searching for…
…or another solution would be to put in a search bar for your plugins. Then I can just search for “serum” instead of trying to remember that it is built by Xfer for example.
For my case I will never need the audio input block in my patches. Please give us a way to delete that (I’m guessing I have missed how to do this?)
Are you guys considering making a VST plugin that will connect with GP? Similar to what Vienna Ensemble Pro does. In my case, I am using Ableton and so at this point I will be using GP along side Ableton so think I am going to have to create an aggregate audio device or use Loopback and I despise Loopback. From Ableton I am going in to an Allen and Heath 32 channel i/o via USB, so it concerns me that creating an aggregate device may introduce some instability into the situation. If the audio stead coming from GP could live inside a VST within Ableton then we wouldn’t have to jump through those hoops. I have no idea about how complex this request is.
It would be nice if we could highlight several blocks at once and do the typical copy, paste, duplicate, etc.
It would be nice if we could highlight several blocks in one rackspace and copy just that part to a new rackspace. This would make rackspaces with several components from various other rackspaces faster to create. (something like this may already exist and I haven’t figured out how to do it?)
I think those are all my comments/requests right now. Thanks again for making this software! So far it seems to be working well for us although I am just at the beginning of porting over our sounds into racks.
Thanks so much for your comments — I’ll reply to them indvidually
If you use the shortcut CMD-P to bring up the quick plugin finder, you can start typing and it will restrict the view to items matching what you type.
1) Please give us a way to sort our plug-ins in a way other than just by vendor. I have come to truly appreciate being able to create my own folders for VSTs based on function in Cubase (Compressors, Filters, Synths, etc). It makes life so much easier and faster than trying to remember the name of some company that made the plugin you are searching for….
2) …or another solution would be to put in a search bar for your plugins. Then I can just search for “serum” instead of trying to remember that it is built by Xfer for example.
I’ll add that to our tracking system — first time anyone has commented on it — usually one just moves it out of the way (if it’s in the way!)
3) For my case I will never need the audio input block in my patches. Please give us a way to delete that (I’m guessing I have missed how to do this?)
Not in the foreseeable future. GP is intended to be a standalone host, not a plugin for other hosts. However, I’m wondering why you dislike Loopback? I have been using an aggregate device that includes Lookback together with my RME interface for the last year with zero problems. I use it to pass audio between MaxMSP and Gig Performer and have never had a single problem with it. Loopback is phenomenal, in my opinion.
4) Are you guys considering making a VST plugin that will connect with GP? Similar to what Vienna Ensemble Pro does. In my case, I am using Ableton and so at this point I will be using GP along side Ableton so think I am going to have to create an aggregate audio device or use Loopback and I despise Loopback. From Ableton I am going in to an Allen and Heath 32 channel i/o via USB, so it concerns me that creating an aggregate device may introduce some instability into the situation. If the audio stead coming from GP could live inside a VST within Ableton then we wouldn’t have to jump through those hoops. I have no idea about how complex this request is.
Agreed - these are on our tracking system for a future release.
5) It would be nice if we could highlight several blocks at once and do the typical copy, paste, duplicate, etc.
6) It would be nice if we could highlight several blocks in one rackspace and copy just that part to a new rackspace. This would make rackspaces with several components from various other rackspaces faster to create. (something like this may already exist and I haven’t figured out how to do it?)
Glad you like it.
I think those are all my comments/requests right now. Thanks again for making this software! So far it seems to be working well for us although I am just at the beginning of porting over our sounds into racks.
Hi David. Great to hear about the search option for the plugin. As far as why I don’t like loopback-the main reason is because I had an experience with some of their other software where they install extra software without asking you and it ended up messing with some of my audio drivers. Like you, I use my computer for live gigs and I am a professional musician so I am very protective about extra stuff ending up on my stage computer.
In general I am working on simplifying the many layers of software and hardware in our live show, so I do not want to have to add aggregate devices and more IEC connections if possible. I finally managed to drop my old DIY audio to midi converter, midi pipe, rewired Reason in to ableton, a software Serial to MIDI converter to control an Arduino, etc, etc…you get the idea.
Good to hear that people just move that audio input out of the way. My feeling was that it is probably using computer resources being there if it is unneeded.
I hope that eventually you guys will consider the VST bridge idea. Vienna Ensemble Pro does it in a cool way where the program is essentially still standalone but there is a VST plugin that you can put in Ableton that just handles the MIDI and audio connection. That way it simplifies a lot of aspects-like recording your midi stream and not needing an aggregate audio device-all while keeping the actual program as it’s own separate program. There are many other examples that I can think of that are both stand alone and able to be integrated-like Kontakt, Omnisphere, Maschine, etc.
As someone who is trying to find a way to be able to produce the music in the studio and then find the most efficient way to then take it on the stage, it would be great if GP was integrated in that way then I could continue to do my production in Cubase, use GP to host the plugins, and then just open that same GP file in ableton for when we are performing live. By having the programs being separate, then I need to do my production all in Cubase and then recreate the synth tracks again in GP for live, so it will add a lot of work. I hope this better explains my reasoning for wanting an integrated system. In any case, thanks for all your hard work, and I look forward to continuing to put GP through it’s paces over this next week to see if it will work out!
All I can say is that I have had zero problems with an aggregate device consisting of Loopback and my RME interface. I’ve done three tours this year already in a professional band (http://securityproject.band), two in the US and one in Japan. In all cases I have used exactly the same setup, Macbook Pro with Loopback/RME interface, four MIDI controllers, MIDI pedal board and Gig Performer with zero problems. Candidly I suspect your concern here is overblown. From my own perspective, these days my only worry is that the computer itself will fail (hard drive failure, RAM failure or something) and to address that I carry a spare laptop! But I don’t worry at all about GP with Loopback etc., it’s all rock solid on stage.
I’ll put the suggestion for a VST bridge into our tracking system but it’s unlikely that it will happen soon. Philosophically we try not to invest time/money in creating features that can be easily supported in other ways. What you describe doing in Cubase is essentially what I’m doing on stage. I drive Gig Performer from Max/MSP using IAC ports and OSC. I agree it would be “slightly” more convenient
Regarding your description of what you’re trying to do, I would just create MIDI tracks in Cubase and then send them to GP over IAC and if you want to record the audio back into Cubase, then use Loopback to take the output of Gig Performer right back into Cubase audio tracks. When you go live, you would just send MIDI from Ableton Live into Gig Performer (using the same IAC ports) and now your Loopback configuration would pass your audio directly to your audio interface. These days this stuff works really reliably on Macs, Loopback configuration is pretty much set and forget so you would just select a different “audio device” from Audio/MIDI Setup when you’re switching from studio to stage.
I am really glad that you have had no problems with loopback in your live setup. Here is my band’s link with a list of our last 900+ shows: http://rattletree.com/tour/
Our current setup consists of four giant marimbas that I built with piezo triggers in each key. Those triggers go to a 256 input Audio to midi converter that I built that then trigger soft synths, modular synths, and scene changes within Ableton. The Ableton computer is a macbook pro that is networked to a Mac Pro. Ableton is sending out (via several IAC networked MIDI outs) to the mac pro which is controlling video projection mapping software (VDMX) that is sent via Syphon into Madmapper and communicating with OSC. Ableton is also sending DMX info to a DMXIS over the network. We then have several DIY midi controllers that are feeding in to ableton via the same network that are used to trigger scenes and then a serial to midi converter that can give us LED feedback info on those midi controllers to see that everything is triggering correctly. The marimbas have 21 mics that are all submixed in to our A&H board and sending out to our in-ears and to FOH. So the A&H board is receiving regular mic inluts plus several USB inputs from the macbook pro. It is also sending audio back to the macbook pro on the USB for a vocal effect channel. My concern with the aggregate device is in creating instability in the A&H audio input driver. It has been finicky.
We recently invested in Malletkat instruments which will enable us to eliminate the acoustic marimbas for overseas gigs. The malletkat will also let us eliminate the audio to midi converters completely and eliminate several hundred pounds from our touring setup. The idea of Gig Performer will be to control the synth sounds of the malletkats and just use the midi controllers to cycle through the synth sounds.
I am sadly finding the VEP demo to be buggy as hell and constantly crashing, so that won’t work for live use, so GP seems to be the best choice right now. Your solution for using GP within Cubase during production is interesting, but it won’t work if like in my case I am working on projects with several hundred tracks and dozens of synth instances and effects chains. It would be essential to be able to have several instances of GP running at once for production with the ability to disable/enable instances as needed. That’s ok though, because so far GP seems to be doing what it’s designed for-rock solid live loading and unloading of synths and effects-quite well! I would just like to have my cake and eat it as well to try and save a lot of time in moving our production tracks over from the studio to live.
Why not? but it won’t work if like in my case I am working on projects with several hundred tracks and dozens of synth instances and effects chains.
Not sure I understand. You can have multiple instances of GP running at once. What do you mean by disabling them? It would be essential to be able to have several instances of GP running at once for production with the ability to disable/enable instances as needed.
Hi David,
First of all-as you know, I am brand new to GP, so I very well be missing important functionality. Thanks for taking the time with me here.
What I mean about disabling is that I build my productions from a Cubase template in which I have close to 300 tracks. At the beginning of the production, most of the tracks are disabled. An example of one track would be a loaded synth and all the audio VSTs and eq curve all ready to go. The next track could be a Kontakt library with specific drum loops, etc, etc, repeat 300 times.
From what I can tell-if I was to use GPs “Multi Instance support” then I would need to then sit there and open up 300 instances of GP. The only other option would be to have a rackspace with 300 racks in it. Am I incorrect?
The difference between this method and the method of having GP linked through a VST on Cubase is that (in my dream scenario), I would have an instance of the VST bridge in each of those 300 tracks and I would only need a single GP with 300 racks in it. The racks could be unloaded (disabled) on startup and the individual racks could load only when the track on Cubase is enabled. That would enable the VST plugin and then enable the rack in GP.
This would also allow the user to access track level automation, bussing, track EQ, etc, without having to only have all that within a single rackspace. You would also not need to now create another 300 tracks to feed the audio from each track back into Cubase.
Once again, this is all discussion around something that I understand is not the intended scope of the software you created.
Understood, never the less, it’s useful to understand different scenarios to see if it makes sense for Gig Performer to address. I’d rather talk to you by phone about this as I still don’t really understand your desired workflow. Please send an email through our support system with your phone number (and availability) so I can give you a call. Once again, this is all discussion around something that I understand is not the intended scope of the software you created.
Hi David,
Sounds good. I am porting over a couple of our songs now to GP so I’m going to hit it hard for the next few daysin rehearsals to be sure it will work for our needs in the live setup (in the way that you intended to build GP). Once I’m sure it’ll do what we need with that, then I’ll reach out to discuss this other aspect with you. Cheers!
PS: Basically, what I’m talking about would be to have the server capability of VEP 6 married to the awesome ability in GP to have the patch persist for live situations.
Hi David,
A small update. We did a small rehearsal last night testing GP with the full setup and it worked flawlessly. I didn’t even need to use an aggregate device or loopback. The QU-PAC mixer i/o was seen on both Ableton and GP, so I didn’t even need to route anything into Ableton for things to work well. It blows my mind that I was able to play Omnisphere going through several effects in real time with all the other tracks going.
I do have one additional (hopefully small) request. It would be great to be able to put the racks into folders along that left column. We use up to 8 rackspaces per song so far, so it would really help clean thing up to be able to have a folder for each song and just have those rackspaces in there…
EDIT: Oops-one more feature request…It would be cool to be able to set the patch persist to a certain number before and a certain number after the current patch. For example-in our case, we are playing through rackspaces one at a time in order. It would be nice to just set the following patch to pre-load and to be able to unload previous patches.
Managing multiple racks per song is something that will be addressed (not with folders) in a future update of Gig Performer but we’re not in a position to say when.
It would be great to be able to put the racks into folders along that left column. We use up to 8 rackspaces per song so far, so it would really help clean thing up to be able to have a folder for each song and just have those rackspaces in there
On our list already but again, cannot say when it might get implemented. patch persist to a certain number before and a certain number after the current patch