Let's share those Custom Lemur edits and tips to the current GP3 Lemur Template please!

Hello folks!

I’m wondering if we could start building a thread with your own custom modifications to the current GP3 Lemur Template:


I’m just about to start to make my first custom Lemur Template from the one above but I have already managed to break the whole scripting apart by changing only a few things…

So I thought, what about asking for help so we can build a list of useful resources and basic script tips for everybody trying to customise it’s own lemur template?

What I would specially like to understand is how the OSC messages from GP3 work in combination with the current Lemur script…

What attributes and arguments we should change, and which ones we shouldn’t change…

For instance, how could we add more song parts?

The template has 5 song parts but I would like to have 15 parts like this:

For some reason, I can’t figure out how can I add more song parts to the GP3 lemur template and retrieve the info from GP successfully…

I have actually the same problem when deleting the number of setlist boxes or song boxes on Lemur… :cold_face:

Things start to break with the script and tittles don’t update properly…

Basically, I’m looking to create just one single container on Lemur including one Column of Setlists, two columns of Songs, and one row with 8x Song Parts…

So what about you guys?

Have you managed to edit the custom Lemur template and make your own?

I would love to hear all your recommendations even the little ones, and see what kind of stuff you’ve been customising with Lemur on this thread soon!




Even with programming skills, Lemur seems to be a little bit tricky. Last year I had a quick look at a few templates, and there are things that keeps unclear to me. At a time I will probably have a look again.

1 Like

One thing worth doing is using an OSC Monitoring tool like OSC Shark so you can see exactly what Gig Performer is sending out. Also, do make sure you have the Lemur option enabled in the OSC preferences if you’re using Lemur.

Like @David-san, I was quite confused when I first saw Lemur scripting and it wasn’t until about a year after I did the original template that I realized HOW they were doing what they were doing so that I could do a better job and the new version for GP3 is quite different from the older version.


Yes of course, this is a key point. Here are the links regarding OSC monitoring:

1 Like

So what important things you learned by looking at those messages that made you change the original template to the current new one?

Do you know how could we add more song parts to the current template then?
what about changing the number of setlist and song boxes too?
What would we need to change on the current script so things get updated and we don’t break the communication between GP and Lemur?


Not sure what you mean? Which messages?

OSC messages between GP and Lemur
Lemur script arguments and attributes…

Oh I see — well I don’t need to monitor the messages since I know exactly what GP is sending out (I implemented that stuff)

However, I just took a look at the documentation and realized that while I wrote down all the messages that you can send to GP, I did not document the responses that GP sends back. I’ll have to update that documentation. But in the meantime, if you just send messages into GP to request the setlist or the song list for the current setlist, you will be able to see the output format of the messages that GP sends out using OSCShark, for example.

By the way, it can be useful to use the broadcast IP address for output, that way, multiple devices can receive the messages

1 Like

So is it the same procedure to request song parts as well?

Could you show us a simple bidirectional messaging between Lemur and GP already implemented on the Lemur template as an example that we could follow?

Thank you!

So for example, if you send the message


to Gig Performer, you get back something like this

/RackspaceName Rackspace : Default
/CurrentGlobalTranspose 0
/CurrentBPM 120.

If you send the message


you will get back something like this

/SongListStart All Songs   
/SongName 0 My first song
/SongName 1 Another song

If you send


you will get back something like this

 /SongPart0Name Intro
 /SongPart1Name Verse
 /SongPart2Name Chorus
1 Like

Much appreciated!

Alright, there’s quite a lot of info right there already

So let’s try to simplify, break down things, and be more specific so everybody can follow…

According to your info,

when I hit the Refresh Pad on the Lemur template,


Lemur then sends the message /Refresh to it’s OSC Target, which in our case it’s Gig Performer



then GP returns the following message to Lemur:

Received by the Global Script ClearALL(OSC_ARGS) located at the Parental Folder


Followed by

Received by the Rackspace name Object located inside the Mixer’s Container


Followed by

Received by what??
The Tuner??

Followed by

Received by TheCurrentBPM Object located inside the Mixer’s Container


Can you confirm this is all correct?


Not everything sent out is necessarily required to be used by Lemur. For example, that global transpose value might not be implemented in that particular template although you’re free to add it if you want. I actually use that particular message with a MaxMSP patcher. As GP grows, more stuff will show up in that Refresh response. For example, the current song and song part should probably be sent out as well

If I remember correctly, that /Refresh request might be on a timer to poll GP periodically. That was intended to deal with the problem where OSC messages are not guaranteed to be delivered.


So how are the song part objects inside the Mixer Container in Lemur receiving their names from GP?

I can see their boxes are unchecked.

So I assume by this that they are not sending the output value to GP?


They just switch colour when selected?


How actually update their names inside of the song part boxes on Lemur?