I find it a shame that GPscript still has no possibility for global scripts and that no function for recording racks- and song-lists has been implemented. For users who use OSC-Touch and not the scriptable Lemur app, there is no way to select songs using the OSC app.
Hi Tom,
here is an excerpt from the OSC-Messages Reference.
So it should be possible to use Touch-OSC and switch rackspaces and variations and songs and song parts.
/RackSpace/SetVariation <int>
/GigPerformer/SwitchToRack <int>|<string> [<int>]
/SwitchToProgramNumber <int>
/GigPerformer/SwitchToProgramNumber <int> <int>
/GigPerformer/SwitchToProgramNumber <int> <int>
/SelectSongByIndex <int> [<int>]
/GigPerformer/SwitchToSong <string> [<int> | <string>]
/Song/SwitchToSongPart <string>What do you mean be recording racks- and song-lists?
Thats right, pianopaul. But i want to have a list of all rackspaces or songs on my Tablet, so that i can chose a certain Song by this list. Using the existing OSC-instructions, I have to know the program-number for each rackspace/song…
I mean “showing” this lists on my tablet
With this OSC-Command
/GigPerformer/SwitchToSong <string> [<int> | <string>]
you should be able to use the Song Name
It is possible to get a list of all rackspaces from Gig Performer, but the client has to deal with such a list.
This cannot be done by Gig Performer.
Touch-OSC for example is super working with Ableton Live, but only because the developer of this Touch-OSC Template provided a perl script for Ableton Live.
With Lemur there are many more possibilities on the client side because of the scripting language.
Such a scripting does not exist in Touch-OSC
Gig Performer reacts on many OSC-Messages and gives all Information via OSC when asked or when rackspaces are switched or when Widgets are moved.
But Gig Performer cannot be responsible for building a GUI on an iPad or iPhone and Android or whatever you want to use.
“But Gig Performer cannot be responsible for building a GUI on an iPad or iPhone and Android or whatever you want to use”
May be. But with the implementation of global script functionality and a script-function like the OSC-message getsonglist it would be easy to do so. And I think the implementation of this functionality schould not be a impossible task
You know this OSC-Messages?
When the client sends such a message to Gig Performer, all required Information is sent back.
/GigPerformer/GetSetLists
/GigPerformer/SelectSetList <int>
/SetList/GetSongList
/SetList/GetSongParts
/Song/GetSongPartsHi pianopaul, I know this messages. But they don’t solve my problem: TouchOSC cannot handle the incomiming data of GetSetLists/GetSongList…, because it has no scripting ability.
Yes and that is the real problem Gig performer cannot solve.
When you have a fixed set list in Gig Performer you could build a fixed GUI on Touch OSC and send the correct messages to Gig Performer for example to switch to the corresponding Song Part.
But this is not dynamic.
Everytime you enhance your set List with songs you have to change your Touch-OSC Template.
And I really do not understand what you mean by “global script” in context of Touch-OSC
Yes, and thats exactly the point, that I would like to avoid. I am playing in different Bands and its tedious, to keep the lists up to date…
Yes sorry, my english is not very elaborated. With the current GPscript-Version, scripts are “living” in the rackspace-environment. If you change the rackspace or Song, you cant refer to any scriptmanipulated data. Within a global script in GP, i could get the Setlist/songlist/rackspacelist… and could send the individual items of the list to certain buttons in touchOSC. Thats all. By pushing this buttons I could switch to the targeted Song/Rackspaces.
I imagine an eventlistener on global intialisation of GP. This handler should “know” about all the global stuff like Song and rackspacelists. When i can hook on this handler, I could do all the mentiond things 
At any stage in the development or release of any product, it will always be the case that something will still not yet have been implemented.
If we waited to release Gig Performer until after every possible feature that anybody every wanted was implemented, Gig Performer would never have been released at all!
Sorry dhj, that shouldn’t be a reproach. Youre making a great job and I love GP.
1 Like
For now, I figure that this should not be too hard to implement standalone. Maybe look into OSC libs for high level languages, e.g. python-osc
You mean, i should develope my own OSC-client-app? May be and I’m thinking about that recently. But it will take time and thats what I don’t have for now. I’m just a beginner in programming android-apps.
sounds like a pretty big project… But the trick is that the libs can do almost all the work about being an OSC client/server, so the main thing for you to implement is your actual application logic - the very thing you would have to do anyway, even if all your feature wishes were already granted
that’s a problem indeed 