Looking at going this route and came across an issue for me that maybe others have solved.
My 1 rackspace per song approach enabled me to have an audio player in there that had an mp3 of the song. Great for practice purposes.
If I go the song route (where one rackspace is used by many songs) is it possible to have the audio player loaded with the correct song? (Again for practice purposes)
Thanks
(I put this in a response to a prior thread though thought the topic may be more broadly applicable)
Hmmm. what if the band has a large repertoire.(Say over 100 songs)? I thought the audio player was limited? Just trying to understand how best to accomplish. Thanks for your help!
For now the best solution is to create a separate instance for this and enable predictive loading. Place one song per rakspace and predictive loading will be loading songs on demand not using much ram, You can have 1000s of songs this way
When you say separate instance, I assume you mean running another instance of Gig Performer just to do the audio player?
I guess I then would have to tell my midi triggering that when it loads song F in the instance that has my guitar tones, to also load song F in the instance that just has the audio player files?
As I’m new to here and to GP (own the PA-Full Edition for about a month now) first of all I like to say hello to everybody at this fantastic community!
My intention for buying GigPerformer was exactly the same as WHITELITE.
I need a global stereo audio player for about 100 songs and want to combine this with my bassamp rack and a vocal-fx rack.
At the moment I “solved” this problem by building a global rackspace setup with 14 Audio-Players (as you know each one has 8 stereo-lanes) which sum up to 112 possible stereo songs!
I created a global player rackspace with controlbuttons to switch between every player and with buttons for lane1-8.
This is more elegant to use as you might think, as GP is efficient and will only playback from an audio-player when it is not muted!
You just have to make sure that only the desired player is unmuted.
For this purpose I adopted the “radio-button” script from the community to make selection more comfortable.
This was a little “megalomaniac” (isn’t it always?) as I have absolutely NO IDEA what I’m doing there in scripting. Just used the try and error method and for now - it works!
Then I used “global parameter assignment” for every button on the global rackspace player and copied this player layout to every “normal” rackspace.
Now I’m able to switch to every available song (by selecting the right player and lane) from the normal rackspace or from a song (using the capture variation function)
That’s a 112 lane audio-file-player!!
Keep in mind, that all loaded audio files consume memory
When you would build a gig in a 2nd instance you could use the same amount of rackspaces in the 2nd instance with an audioplayer and the needed audio files and with predictive load set in the 2nd instance you do not need that much memory.
Pretty intense work from @DerBecker. Impressive for a guy new to this.
@pianopaul Maybe I’m overcomplicating but I’m not crazy about keeping the two instances in sync. (Adding New Songs, creating new setlist for gigs etc).
For now, I think best for me is the one rackspace person and for those songs that are generating the stuck notes, I’ll create 2 or 3 rackspaces.
I do think an audio player feature for songs would be cool (not tied to rackspaces but to songs) as I would think a lot of audio player functionality is song based.
That of course is correct!
I had some “hanging” issues with predictive loading. (Maybe there is one or two plugins which are a little bitchy )
Memory consumption is to consider. In my case there are 9,4GB of memory used. I’m using 87 lanes of the player at the moment, 13 rackspaces for bass and 6 rackspaces for vocal-fx (this ones in a second instance) estimating about 40 loaded vst-plugins.
I’m using a 7 years old Intel i5 with 16GB of ram with a motu 828es running at 48Khz and 64 samples latency.
There is still headroom left on this system so it is working for me. But of course you have to think about the aim of your individual setup. Maybe softsynths/sampleplayers will use a lot more ram than my setup does.
At least I think that upgrading your memory is nowadays one of the easiest parts…
I have to admit I spend some hours on this to figure out, but its way less impressive than it seems -simply adding up things these wonderful guys here already mentioned.
As pianopaul mentioned earlier
If you want to keep it way more simple I suggest to build up your rackspace with one (or two) audioplayers - bringing up 8 buttons for the different lanes and save this as your “gig”-file.
Then build a new “gig”-file and after your 8 (or 16) songs are through just take the short time to load the new gigfile and went on.
If “predictive loading” works flawless with your machine than consider that. But it could be a little “busy” to have 40-50 rackspaces in one gig-file.
“Only” 79 Songs at the moment.
The setup can play up to 112 Songs, but not every player is fully stacked with 8 lanes.
I wanted to leave some room for the future…
And I used flac-format. I’m not sure if GP is able to load only the smaller filesize and play them or if it will convert them to “wavs” on the fly when they’re loaded into the player, but it seems that it can handle the smaller size.
A gig file built for this purpose (backing tracks) would have a well designed rackspace with one audio player (or more) and good widget control. Loading these with predictive loading set to some value will be almost constant regardless of the number of songs. 10 or 1000. Because this will use built in plugins - it will be super stable.
Each of these rackspaces will have a PC number assigned.
In your main instance just make sure that each song sends the correct PC message to the second instance (make sure your second instance only responds to PC messages from a specific, second instance) and switch to the appropriate song automatically.
You can also use Link or a global widget that sends play/rewind/stop midi commands to the playback instance from the main one. So you can have all the controls in the main instance. Use the second one as a simple storage and playback device.
This kind of setup will really allow you to run any number - thousands of songs - without using much more resources and easy management.
Having said all this - if the setup you have now works for you - that’s all that matters.
First of all (as a total beginner using GP) I wanted to get “my needed system” running. I never thought about using multiple instances as I was unsure if I can handle this.
So I build this setup - and as you said - it works!
But now after I tried to use a second instance for vocal-fx and learning howto connect between this units I think it will be a good idea to build a second instance just for the player as you mentioned.
This way you will be way more flexible in the future in what you will use parallel to this backing track player.
Maybe I will switch from a bass-fx-rack to guitar-fx-rack or the drooling keyboarder (let me use your GP for VST-Synth ) extends the setup…the backing track player will always stay untouched.
And you can use it standalone when you need to!
So now I have a working system - lets do another try and build one with instances!!
Thanks to djogon and pianopaul, definitly it helps!
)
) extends the setup…the backing track player will always stay untouched.