As seen in this topic, our colleague Markus (@LeeHarvey) was kind enough to create a script that allows me, from individual rackspaces, to control the Triton RExtreme plugin placed in Global Rackspace.
When using his scriptlet, however, I noticed a small issue that I’m not sure will be easy to overcome: if the TE plugin is in bypass/mute mode, the script doesn’t act.
I sometimes use scriplet “Pluginpersist 2.0” to mute some plugins when they’re not in use (auto-sleep function on MIDI unactivity) to save some processing power. If the TE is muted, it doesn’t react to the program change command. Perhaps the issue could be overcome if, along with the command to change the program, there was also a command to activate the plugin. I don’t know if that can be done that because I don’t know anything about programming.
Could someone check this?
Triton test_LeeHarvey_V5(2).gig (772.8 KB)
So the issue is, that the plugin when bypassed does not react in PC messages?
Yes, thats the issue. If I manually unbypass the plugin, it works again
That is exactly the function of bypassing a plugin, it should not react on any incoming MIDI messages
and it should bypass all work.
1 Like
Sure, but couldnt a comand be sent to both unmute the plugin and change program?
As I understand the scriptlet mutes a plugin when not used.
I cannot imagine how to solve that.
Maybe I didn’t make myself understood clearly.
The script created by Markus sends program change commands to the Triton Extreme plugin.
If it is bypassed (due to the action of another plugin) the command sent by the script does not work.
My question is: Wouldn’t it be possible for the command sent by the script to include an action to activate the plugin if it is in inactive mode? In other words, the scriptlet should first try to ensure that the plugin is in active mode (and activate it if it is not) and only then send the command to change the program. I have no idea if this is possible.
Maybe you can share an example gig where you use “Pluginpersist 2.0” from @David-san with my “TritonExteme-Script” at the same time.
The truth is that I found last night that I had an error in my configuration. I was using the “pluginpersist 2.0” widget placed in Global Rackspace with a different configuration from the corresponding widget used in local rackspaces and conflicting with another “pluginpersist” widget. That’s why there were conflicting instructions that led to an inadequate response from the plugin. My mistake, I apologise.
However, I need to check that the scriplet works when the plugin goes into auto-sleep mode. I’ll test it as soon as I can.
I can confirm that there is a problem using scriplet when the triton extreme plugin goes into auto bypass.
Although the number of the program/combination that was configured in the scriplet is shown, in the plugin this change does not occur. In order to activate the correct program, it is necessary to exit the rackspace/variation and enter it again. As the plugin has since become active, the program change is processed.
For now, I’ve solved the problem by removing the “auto-sleep on midi unactivity” option, which means that the plugin is always active. Of course, this solves the problem for me, but at the cost of continued processor usage (which, in the case of TE, is significant).
TE issue.gig (12.1 MB)
TE issue (temporary fix).gig (12.0 MB)
I have integrated the “Triton Controller” scriptlet into the “PluginPersist A” scriptlet of the Global Rackspace. This enabled me to deactivate the ByPass status before sending the COMBI change.
TE NEW.gig (12.1 MB)
3 Likes
You are awesome!
Thank you very much