Hi I desperately want to use Zenology Pro in my setup.
I need to write a script that changes sounds presets because it doesn’t accept program changes.
I’m totally new to scripting in GP but I think I can learn.
The question is: Is it possible to do it with scripting? or should I quit trying to do it
I was thinking about a script that can manage GP user presets.
Is it possible?
Ohhh, I would love to use it too, but Roland stops me with the need of their licencing system to call home each month. 
Regarding your question, may I ask you to first have a look here:
Thanks for the great reading but it was no help.
Zenology doesn’t recognize Program changes and I need some workaround if possible
I think the key takeaway is you can select one rackspace variation, adjust the VST parameters to one sound, then create another rackspace variation, adjust the VST to the new sound. Then you can move between rackspace variations to select the desired sound. No PC required to the actual VST.
1 Like
I really need to remain in the same rackspace variation bacuse creating a new rackspace (a very complicated one in my case) would increase cpu stress. I don’t really want that
I don’t think so and you could easily verify it by duplicating your rackspace. Why do you think it should be the case?
3 Likes
I made five duplicates of my rackspaces for the patches I want in Zenology.
I got 10% CPU usage increase. Not best solution.
Is it that difficult to write a script that make a know select GP presets in zenology?
Reading some documentation I figured out it may be possible
Then the plugins are not programmed very well.
1 Like
Yes it is possible to recall GP Presets via scripting.
The idea is to store the plugin state as a GP preset which can be recalled by scripting.
BUT: Some plugins do not like that mechanism, which is not the fault of Gig Performer.
Do you have an issue when the CPU (what display do you mean?) raises up 10%?
Why not? Did you need cycles available to read your emails or surf the internet or play games while you’re performing?
Is it the Audio CPU usage or just usage shown by your task manager?
I know the question seems a bit facetious but it’s a serious question. If your CPU has to do a bit more work, what’s the problem with that?
Also, @pianopaul is correct….when you switch rackspaces, the audio processing of plugins in the old rackspace should stop. If the CPU usage still goes up, then the plugins are poorly implemented. You should inform the developers.
Right.
@spee: You could try if the plugin format (VST/VST3/AU) probably makes a diffrence in this behaviour… it’s quite often the case that there are diffrences between them.
Not really. I used it in a live set with just two apps. Winlive Pro (my fave player, need it to run audio in sync with chords and lyrics) and GP. GP handles all my mic and keyboards setup (3 mics with different fx chains each and 3 zenology vst3). CPU performarce is cricual for me because I want to avoid spikes that makes my audio card produce cracks and pops.
I don’t understand why there is all this ‘avoid scripts’ policy here 
I did an example here:
There is nothing like this, we do like scripts quite a lot - it’s just that we don’t encourage using scripts where users already encountered issues and when it is likely to happen again.
Actually the issue is avoiding premature optimization. GP Script is intended for uses where available features in Gig Performer aren’t sufficient to address a specific problem. Indeed, features initially implemented with GPScript often find their way into the product directly.
The suggestion was made that you could just use multiple rackspaces.
Of course - we all agree on that - but until you actually have to deal with spikes then you’re trying to solve a problem that, so far, doesn’t actually exist. Unless an increase in CPU usage actually causes spikes then I don’t an issue. Even then, if it’s a poorly implemented plugin, then switching to another plugin may make more sense than trying to hack a workaround.
1 Like