Complete Playback and Midi Switching With Or Without Multiple Instances

GP for Guitar and Bass Players
1

HI, so at the moment I’m using GP to run both my Guitars and Bass using multiple instances so we can independently switch MIDI between rackspaces when playing live. Right now we are running backing tracks with my drummers small mixer to provide clicks for him and tracks for FOH. I’m looking to use GP to its fullest potential to remove the mixer and our MIDI pedals and just run everything from the laptop. Right now I’m using an interface with 4 outs, and with this new setup I’m planning to use my 8in 8out rack interface to provide the necessary line outs (guitar, bass with and without cab sim, click and tracks).

So, right now I’m having a problem figuring out how to go about doing this. Would I have three different instances of GP, one for Bass, Guitar, Tracks/MIDI? I couldn’t figure out how to use MIDI to switch rackspaces from different instances, unless I’m missing something.
Or, would I use one GP session with everything routed and use the global rack space to house the Track and MIDI player and switching between rackspaces.

Thanks in advance!

2

You can use OSC messages to switch songs in different instances.
Use one instance a s main instance with the midi or Audioplayer in the global rackspace and send OSC messages to the other instances when switching songs.
You also can use an extra instance with a midi or Audioplayer for each rackspace and use that as master instance

3

I don’t whether you’re on Windows or not, but when you are:

The standard USB drivers for MIDI are single client, so you can’t open the same MIDI controller in more than 1 instance of Gigperformer, although you can use a software MIDI router combined with loopMidi or something like that to overcome this problem. After this you could have the different instances of GP react to different MIDI messages of the same controller

Another possibility is making 1 GP instance the master and have it forwarding MIDI messages using OSC (as suggested by @pianopaul) or using virtual MIDI cables (like loopMidi).

4

Better OSC messages which Gig Performer recognizes to switch rackspaces.
No midi needed at all.

1 Like
5

I’m thinking using one instance to keep everything separated would be the way to go. I’m not familiar with OSC until Paul just mentioned it. Seem like the most effective way to do this. Would different OSC messages be able to switch automatically in time with a track, and send different messages to different instances? For example, Bass and Guitar instances are on rackspace 1, but Guitar needs to move to rackspace 2 for a solo. I apologize for my ignorance.

6

You’re right. I was merely trying to bring up what’s possible. Some people are more comfortable with this technique, while others rather use something different. :grinning:

7

Best would be build the Same songs in all instances with the same structure.
This way you can automate all sound changes very easy.
Now switch song parts in the main instance so all other instances switch to the same song part.
I would use a separate instance for each instruments.
You decide what is referenced in the song parts of the other instances.
Quite easy.

8

Try this
OSC_CLIENT.gig (14.9 KB)
OSC_MASTER.gig (15.2 KB)

The name says all.

There is a script in the Master Instance which sends some OSC Messages when you select a song part.
The Port used is 9300

var mSONGOSC : OSCMessage
    mPARTOSC : OSCMessage
   
initialization
 OSC_SetAddress(mSONGOSC, "/SONG")
 OSC_SetAddress(mPARTOSC, "/SONGPART")
end

// Called when you switch to another song
On Song(oldSongIndex : integer, newSongIndex : integer)
 OSC_ClearArgs(mSONGOSC)
 OSC_AppendIntArg(mSONGOSC, newSongIndex)
 OSC_SendSpecific(mSONGOSC, "127.0.0.1", 9300)
End


// Called when you switch to another songpart
On Songpart(oldSongpartIndex : integer, newSongpartIndex : integer)
 OSC_ClearArgs(mPARTOSC)
 OSC_AppendIntArg(mPARTOSC, newSongpartIndex)
 OSC_SendSpecific(mPARTOSC, "127.0.0.1", 9300)
End

So in your 2nd instance you have to set the OSC listening port to 9300
And in the Client Gig this script is used to react on incoming OSC messages

var v_song     : Integer
    v_songpart : Integer
    v_success  : boolean
    
// Called when a specific osc message is received
On OSCMessageReceived(m : OSCMessage) Matching "/SONG"
 v_song = OSC_GetArgAsInteger(m, 0)
 v_success = SwitchToSongByIndex(v_song, 0)
End

// Called when a specific osc message is received
On OSCMessageReceived(m : OSCMessage) Matching "/SONGPART"
 v_songpart = OSC_GetArgAsInteger(m, 0)
 SetSongPart(v_songpart)
End

When you have more than 1 additional Instance of GP Running, each of then gets a separate listening port and you just send to all of them by adding
OSC_SendSpecific(mPARTOSC, “127.0.0.1”, 9301)
OSC_SendSpecific(mPARTOSC, “127.0.0.1”, 9302)

OSC_SendSpecific(mPARTOSC, “127.0.0.1”, 9301)
OSC_SendSpecific(mPARTOSC, “127.0.0.1”, 9301)

3 Likes
9

With this script in the Master Instance (Gig Script)
no scripting is needed in the Client Instances because this are Standard OSC Messages recognized by Gig Performer.

var mSONG    : OSCMessage
    mPART    : OSCMessage
    
   
initialization
 OSC_SetAddress(mSONG , "/SelectSongByIndex")
 OSC_SetAddress(mPART , "/Song/SwitchToPart")
end

// Called when you switch to another song
On Song(oldSongIndex : integer, newSongIndex : integer)
 OSC_ClearArgs(mSONG)
 OSC_AppendIntArg(mSONG, newSongIndex)
 OSC_SendSpecific(mSONG, "127.0.0.1", 9300) 
End


// Called when you switch to another songpart
On Songpart(oldSongpartIndex : integer, newSongpartIndex : integer)
 OSC_ClearArgs(mPART)
 OSC_AppendIntArg(mPART, newSongpartIndex)
 OSC_SendSpecific(mPART, "127.0.0.1", 9300) 
End