Reading from an external file from a script

Scripting with Gig Performer
#1

I am still using Forte on Windows 7 while trying to ‘rebuild’ my entire rig in Gig Performer (a large undertaking). A feature I use in Forte regularly is associating multiple key ranges and transpositions on a single rack instrument from one or more midi controller sources. Forte makes this VERY easy compared to how I’ve seen I would have to accomplish the same thing in Gig Performer. At first, this might have been a deal breaker for me, however I then learned about GpScript and I’m thinking there should be a way for me to quickly ‘script’ this functionality.

My thought was I could interrupt the appropriate midi events from the controllers and remap as I go, however writing individual full scripts embedded into the scripts would be fairly time consuming as well and also time consuming to modify while working on a specific rackspace for a given song. My thought was what if I could create a ‘configuration’ file on a rackspace by rackspace basis that are stored in a folder relative to the rackspace file itself that I could easily modify external from Gig Performer itself. I would reload the configuration file into a given rackspace or variation as I ‘entered’ it loaded so that changes would be more straightforward and would not require me jumping into the script files directly to make these modifications.

I have significant programming experience in a number of languages with a variety of IDEs and while I appreciate the fact that GpScript exists and is a great ‘first blush’ at a feature in a virtual rack, the overall development environment is still extremely basic. I think this would help me get around the limitations of the editor.

I seriously want to thank the creators of Gig Performer for building scripting capabilities in. I actually asked for scripting (either internal or external) in Forte multiple times but the developer had his reasons to not expose this.

thoughts?

xpansion

#2

I am using GigPerformer since version 1.
I used MainStage and switched to GigPerformer.
I have many keysplits in my rackspaces and I think the implementation with multiple Midi In Plugins is very clear and flexible when you use the rig manager.
What do you think makes this a deal breaker for you?

#3

If you had ever used Forte and set this up, you would understand the difference in effort to accomplish the same task given the general layout and functionality of Forte in this regard. With Forte, you get four independent zones with their own transposition settings per ‘racked’ instrument/controller/scene by default. You don’t have to ‘add’ them individually, they simply exist and are ready for very easy configuration. It takes significant more effort to add four individual controllers with their own range and transposition per input you’ve pulled in with GP. It also makes for a very cluttered looking rackspace on the back panel. This would be an easy way around that additional effort and screen real estate.

if you understood how much I use this function VS how much more time-consuming it is to configure in GP, you would understand better why I’m looking for another option to quickly build this kind of configuration.

Jim

#4

Ok I understand, sorry I cannot help you.

#5

If (pick some other product) could do what we needed to be able to do for our own performance needs, we wouldn’t have bothered to invent Gig Performer :slight_smile:

Create a basic rackspace with four Midi In Blocks (same as zones), export the rackspace and then just import it to use it as a starting point

For example, here’s a rackspace with just a single MidiIn Block but its min/max note and transpose amount are controlled from widgets and so as you switch from one variation to another you can get instant split changes, etc.

Is V3 sort working ok?
#6

Sigh - Gig Performer is a musician’s tool, not a software developer’s tool. We’re not going to build the next Xcode/Eclipse/VisualStudio/IDEA/Name your favorite IDE here.

GP Script (it’s actually a compiler) was really just created to allow us (the dev team) to experiment with certain ideas that could then be turned into built-in features. Most of our users are not technical and don’t want to be technical. Most people never use it and we never really expected GP Script to be an important part of Gig Performer. I was quite surprised to discover that some users have developed very substantial programs with it. Personally, I only use it in a few places and I rarely have more than 30 lines of code.

There will be some enhancements to GP Script over the next year (hopefully - I’m not guaranteeing any product features!) to handle some centralized control as well as dealing with songs/setlists - the rackspace-centric model is clearly no longer sufficient. There needs to be a way to “import” functions so that the entire script doesn’t have to be duplicated for every rackspace, etc. It may make sense to support function overloading so that we can simplify function names, and so forth.
We might need to do some file handling and/or support shared variables and persistent variables but at this point it’s unclear how important are such things to the majority of our customers. There are some other options as well, such as exposing an API so that technical users could write their own code in shared libraries using whatever language they want but again, that gets extremely sophisticated and may only be of use to a tiny number of users.
An alternative approach of course is to use something like MaxMSP to create some of the functionality you want and then have Max communicate with Gig Performer over OSC to actually play audio. GP has explicit support for receiving MIDI over OSC for just this reason.

1 Like
#7

So the short answer is ‘no’.

I totally get the reasoning behind why GP is the way it is, and I can respect that as well. I am a software engineering manager in banking software and we also have to weigh any feature we develop against the value it will provide to a larger percentage of users. I’ve had these same conversations with people asking for features that may take a significant amount of effort to both develop and maintain over the long haul that will only be used by a small percentage of users.

I’m glad I now understand that GP script was not really intended (at least not yet) for the kind of power use I was going to use it for. That just means that the time to switch over from my old Forte rack is going to take longer than I’d hoped. I think you still didn’t quite understand my use case in terms of keyboard zone/range/transposition, but without providing a number of screenshots, it probably won’t be clear. Either that, or it simply isn’t an easy fit in GP.

Despite the zone/range/transposition issue, I can say that I haven’t found a better replacement for Forte than GP and trust me, I’ve looked. I understand why there seem to be more former Forte users using GP VS other competitive options. While there are other features I’d like to see, there are also some features in GP that were NEVER in Forte that are very cool. Heck, just being able to route the audio signal the way you can in GP is extremely flexible and there are some new things I’ll be able to do here that I couldn’t do in Forte.

Thanks for the response. Hopefully I’ll find a workflow to speed up the process.

X

#8

Do I understand correctly that this is not yet the case?
I found another post where you explained the use of autotype, taking the Print() function as an example, which is capable of printing Integers as well, even though the input argument is strictly a String.

#9

Supporting function overloading properly requires an overhaul of symbol table management. It’s on my list (along with 500 other suggestions :slight_smile: ) but not high priority.

AutoType was a simple solution to allow such things as allowing different kinds of MIDI Messages (which are strongly typed in GPScript) to be passed into a function that just uses the “base” MidiMessage type.

1 Like
#10

OK, clear. No need to hurry :wink:

1 Like