Sure, change the MakeControlChangeMessage entries to MakeControlChangeMessageEx entries, and then put the channel number at the end. For channel 10, they’d end up looking like this:
a = MakeControlChangeMessageEx(11,127,10)
b = MakeControlChangeMessageEx(12,127,10)
c = MakeControlChangeMessageEx(13,127,10)
d = MakeControlChangeMessageEx(14,127,10)
MakeControlChangeMessage only uses channel 1, so if you want to send messages on any other channel, you need to use MakeControlChangeMessageEx instead and define the channel at the end.
Yes, thanks for looking out! The event blocking is on purpose, not that anything was going to be sending those events in this particular instance, I was just being overly cautious I guess. This midi input is going to a guitar VST so not using any of those events.
Did I wrongly assume about the channel routing not working? So even though its in red, which universally communicates “don’t do it, wrong way, you’re going to die” that would work? I’ll test it later…
@edm11 Everything is working with scene selection, thank you! Do you ever get any preset loading issues in Bias? I haven’t done a lot of playing since I just re-did the scene selection from widgets to scripts, but I am suspicious that whether through widgets or script, if the scene selection command comes through before the preset is loaded, it might lead to the present not loading properly. Even though I’m sure script is more solid than widget for scenes, its still immediate and when you switch to a new rack, if that rack hasn’t already been loaded yet, loading that preset is going to take longer than script. So the scene selection script command will likely go through before the preset is fully loaded. I’m speculating that’s why rarely and randomly some Bias sounds in some racks load “weird”. By weird I mean sometimes totally silent, sometimes the amp/effects settings are wrong, or resemble the settings of another scene, but since I’m in variation 1, scene one is loaded etc… Are you using predictive loading?
@ztones I tested this scripted rackspace in a gig of 10 other rackspaces, with no predictive loading. Starting in other rackspaces, I then switched to this Bias rackspace. I had no issues with the sound from Bias–it immediately went to the appropriately called scene without issue.
I suggest giving it a thorough run thru in a larger gig file with other rackspaces to either verify or dismiss your suspicions. I suspect that it will be ok, because in using this script, each scene IS the variation itself, not something that gets switched to during the variation.
Right. I am not having this issue with predictive loading turned off either,I suspect for the very reason that it preloads all the racks. It is with predictive loading ON that not all racks are loaded in advance and perhaps that’s why it’s doing it then occasionally. But it’s rare. Hard to catch. But when it does, no quick fix live and it’s very frustrating so I turned off predictive loading also.
@edm11 I noticed something very interesting that proves there is a relationship between loading the preset and executing’s the script. I am entering the new script, for my existing racks. So the rack has already been loaded. After I successfully compile the script, I open Bias FX2 to verify that switching the scenes is working. At first it is not always. However, if I step down to another preset and back (in other words reload the preset), it suddenly starts to work as expected. What do you think?
I haven’t dug too deeply into it, since the scripted rackspace has worked for me without fail. Also, Bias is it’s own case as far as plugins go. The behavior of scenes are unlike what I’ve found in other plugins. What you’ve found seems to make sense–but I wouldn’t worry about that particular case since you’d never be doing that live.
I think the key with BIAS is to not try and operate it inside the plugin itself, but rather to use the GP framework and scripting to change the various sounds and parameters—and to keep predictive loading off.
I don’t see a midi assignment option in BIAS FX 2 to edit the “scale” parameter in the harmonizer modeler. This also means no widget can be assign to it. Its a bummer since obviously having one key available to the user is extremely limiting and opening the plugin during live performance out of the question. I was hoping that saving different key settings in different songs and capturing/saving that variation with different keys in different songs would solve this problem, but it doesn’t save the key/scale parameter settings unfortunately. Is there a way around that through scripting? I am pretty sure if manual editing in BIAS itself is the only way than the answer is NO, but I am hoping I am missing something…
You’re right, it looks like Positive Grid left the Scale parameter out of it’s list of assignable MIDI and Automation parameters. That’s a big oversight on their part.
One way around this is to create rackspaces for each scale you’d want to use. That could be a tedious solution, depending on how many rackspaces you want to use the Harmonizer Modeler in.
Yeah, crazy right? I want to have it available sponteniously, so mltiply the amount of scales with the amount of presets one might want it in and it becomes a no solution at all… Buy yeah, I guess for a particular song if really needed can be done. I’m hoping in a future update this will be addressed. Thanks!
BTW, just confirming you are using GP with predictive loading OFF right? Mine works great now, but ONLY with predictive loading OFF. As soon as I turned it back on, I randomly lose sounds on certain racks with BIAS.
