IK Multimedia T-RackS - Strange Behavior Linked to Sustain and After-touch

[GTP]

Instances of VST3 T-RackS effects such as Classic EQ, Classic Compressor, EQ-73, etc. are somehow linked to input from my sustain pedal and after-touch continuous controller (CC) messages. For example, when I depress my sustain pedal, the Low Shelf Frequency Cutoff goes to its maximum value, and when I release the pedal, it goes to its minimum value. The only way I can prevent it is to not have a MIDI IN block associated with my controller that has the sustain pedal, or if I block sustain pedal messages within the MIDI IN block, but then I lose the ability to have sustain pedal input for any VST inside the rackspace. The same situation exists for after-touch messages and for most of the other VST3 T-RackS effects - the only thing that changes is the particular parameter within the plugin that is affected by the sustain and/or after-touch input. This is happening, no matter what else I have in the rack space or how I have everything connected. I do not have a virtual MIDI cable connected to the T-RackS VST3 (they don’t have a ‘MIDI In’ on the block, in any case). This behavior does not happen with the VST2 versions of the same T-RackS effects. As a test, I set up the simplest scenario to eliminate variables: I created a rackspace with nothing but the following blocks and made no virtual connections and the above behavior still happened:

1. Audio In Block.
2. Audio Out Block.
3. MIDI IN Block.
4. IK Multimedia T-RackS Classic EQ VST3.

(BTW, I tried it once with an ‘OMNI’ MIDI IN block and once with a block for the specific MIDI Controller that has the sustain pedal - both with the same results).

Here’s my set-up/hardware notes:
Windows Laptop = Lenovo ThinkPad W540, 2.7GHz i7-4800MQ (quad-core).
Audio & MIDI Interface = RME Multiface II connected to the laptop via ExpressCard.
Keyboard Controller = Yamaha Motif XS8.

The sustain pedal is standard Yamaha and connected to the Motif. The ‘CC’ assigned to sustain is the typical default of CC#64, and after-touch is also the default (I believe CC#3). I have the standard 5-pin MIDI out from the Motif connected to the MIDI in on the RME Multiface. I tried using different MIDI channels but that did not make a difference, except to note that if I blocked (in the MIDI IN Block) the channel that the Motif was sending on, then the behavior with the T-RackS VST3 didn’t happen, but, of course, I then had no MIDI coming in for any other purpose.

[dhj]

Sounds like your parameters have learned MIDI events associated with them.
What version of GP are you using?

[GTP]

Thanks for the response to my post. I’m not in front of my computer with GP on it, so I can’t check the version number at the moment, but I purchased and downloaded it less than a year ago and I’ve regularly checked for updates (from within GP) so I believe I am using the most recent version. I’ll check the actual number as soon as I can. I did look through the list of learned CC assignments within the GP menu for that purpose. I did not see the Sustain Pedal (i.e. CC#64) listed. Also, I noticed that the GP assigned parameter number for the functions that are being affected are the same for the VST3 and VST2 instances of the same T-RackS effect, so I would think that, if it was a ‘learned’ assignment, it would show up for both the VST2 and VST3. But the behavior is unique to the VST3 instances. Also, if I open multiple instances of the same VST3 and/or instances of entire set of affected VST3 effects, the behavior happens on all of them simultaneously. It really seems like a ‘behind-the-scenes’ code bug in either T-RackS, GP, or both, because I can’t find any settings or options available to ‘the user’ that make any difference in the behavior, but I’m not a programmer so that’s just a tentative suggestion, offered respectfully, from my perspective. With that said, I’m doing my best to apply sound deductive logic, collect useful information by experimenting to eliminate variables, and then make cautious observations. At the very least, it’s an interesting problem!

BTW, I believe you are one of the developers (based on scanning through your posts on other threads), so I wanted to take an opportunity to thank you for investing your time, effort and intellect into this product. As far as I know, and I imagine you are well aware of, there is (amazingly) nothing else like it available. I say ‘amazingly’ because there is such an obvious need for what GP provides that I am shocked to find no other options on the market. Some would say MainStage covers the same territory, but I believe that it is still ‘Apple-only’, leaving us PC users out, and, from what I’ve seen of it in demos, tutorials, etc., it is too cumbersome and restrictive to be attractive for professional, live use. I play in a live worship band, every Sunday, and our only rehearsal is the 30 minutes before the service starts - the flexibility and intuitive set up with in GP is fantastic and makes it possible to set up and deliver a professional-sounding, polished performance, with almost no reaction time. I love using Gig Performer! So, thank you for developing it!!!

[GTP]

The version of GP is 3.5.0. on the start up screen. Any insights?

[dhj]

The latest version is in fact 3.61 – please download it directly from our website

https://gigperformer.com/downloads.html

[GTP]

Done. Downloaded the latest and ran set up. Need to restart the system and test the behaviors, now. Knocking on wood.

[GTP]

I tested it with the version 3.6.1 and all the same behaviors still occurred. I also picked up on some more data. The behavior is always associated with what ever is assigned as “parameter 0” by Gig Performer. Also, in each case, the parameter is affected by sustain pedal (cc 64), volume pedal (cc 3) and aftertouch (not sure what cc… when I look at MIDI Monitor, it just says Channel Pressure and a value, whereas the Volume and Sustain Pedals should cc # in addition to value). Volume pedal and aftertouch (i.e. channel pressure) are continuously variable and the sustain pedal is a switch (all on or all off) even though it is a pedal capable of ‘half-pedaling’ and actually sends intermediate values between 0 and 127 - so when I press sustain at all, the value of the parameter goes to max and when I let off the pedal it returns to zero or min value. On the volume pedal and aftertouch the value of the parameter corresponds to the MIDI value in real time. Finally, I noted that when I connected my MIDI Input GP workspace device to the MIDI Monitor or a VST Instrument (via orange virtual MIDI cable), then the behavior stopped. If I disconnected the virtual MIDI cable, so that nothing was connected to the MIDI Input device, then the behavior resumed. I am not sure, but I think that is a different aspect than what I observed prior to the update to 3.6.1. I think the behavior was happening, even if I had the MIDI Input device connected to VST Instruments. Again, I am not completely sure about that last observation.

[djogon]

@GTP

but then I lose the ability to have sustain pedal input for any VST inside the Rackspace

You do not have to have a single MIDI Input block per device. You could have as many as you want. In fact - this is how you create splits, etc. So you can create another MIDI In block with the same hardware device, but not block certain messages and use that for your other plugins.

Another option is to insert a MIDI Filter plugin just before your T-RackS and block/redirect any events you want but directly connect from MIDI In to your other plugins.

The reason this is most likely happening is that T-RackS seems to be pre-programmed to do something when those events arrive into it. I am not sure if you can stop that, but it is much easier to use one of the options above.

Hope this helps.

[GTP]

I think I already thought through all the options above, such as multiple MIDI Input blocks and MIDI filters, etc. I read the entire manual and searched blogs/forums for each product involved (i.e. IK Multimedia, T-RackS, individual T-RackS effects, Gig Performer, etc.), before reaching out on the forum.

I do use multiple MIDI Input blocks per device and have tried every different combination that I can think of to test the possibilities.

As far as the comment you quoted of mine “but then I lose the ability to have sustain pedal input for any VST inside the Rackspace”, my point was that the only way I can stop the behavior (as far as I knew at the time), was to eliminate any MIDI sustain, volume control or aftertouch CC messages, and to do that I had to either eliminate the MIDI Input block from the controller that was sending those messages, or to filter those messages out using the filter within the MIDI Input block or another MIDI Filter block… but, doing that (i.e. filtering out those items) I lose that function. If I filter it out in one block and then create a new MIDI block that doesn’t filter it, the behavior still happens.

In fact this is the scenario I most commonly use - I like my one sustain pedal to work across multiple Controller keyboard, so I have a ‘Sustain Pedal Only’ MIDI block that I connect to all of the VST instruments that I want to sustain, regardless of which keyboard controller I am triggering the VST from. It works very well for me in live performance where I use up to three separate keyboard controllers at a time but only need one sustain pedal. It’s one of the reasons (among many reasons) I love Gig Performer.

But, I cannot use my entire suite of T-RackS VST3 plugins with this or any other configuration that I wish to employ sustain, volume pedal expression control, or aftertouch.

Key facts to focus on are:

1. I don’t have any virtual MIDI cable connected to the T-RackS VST3; that VST block does not have any MIDI input connection to be able to connect to;

2. It only happens with VST3 (not with the identical VST2 version of the effect);

3. It currently stops happening if I connect the MIDI Input block to a VST instrument or the MIDI Monitor block; (note, I don’t think that was the case on earlier versions of Gig Performer, where the connection to other devices didn’t seem to cut off the unwanted behavior).

Regarding your suggestion about inserting a MIDI filter to block the sustain pedal (and other) problematic cc input before the T-RackS effect… there is no input into the T-RackS effect, so there is no way to employ a MIDI filter that way… the T-RackS block isn’t connected to anything via MIDI or Audio and the behavior is still happening.

It seems like a bug for Gig Performer (GP) to address - i.e. a device in GP, shouldn’t receive MIDI commands unless it has a virtual MIDI cable or it has an assignment thru widgets on the front panel or in the General Options assignments… Also, that’s the philosophy and design basis of GP, as I see constantly reinforced in these support forums and FAQ’s and tutorials - i.e. use widgets, not direct MIDI assignments, which I’ve tried to adopt and fully incorporate, as a GP user.

But, if I’ve caused it by mistaken settings or otherwise, I would like to figure out where I went wrong, so I appreciate the input.

[djogon]

Hmmm. If a plugin is receiving MIDI events directly without any MIDI connected into it and is not somehow talking directly to MIDI devices outside the GP stuff - that should definitely be investigated.

Could you create a small gig file with one simplest possible rackspace that process this problem and send it to us? (you can either post it here or send it in a PM).
Thanks.

[dhj]

I just looked in the IK Multimedia store and there are about 50 products there all of which have T-RACKS in the name.
Could you please give me a specific product that is giving you this problem so we can try to reproduce it.

Thanks

[pianopaul]

I found a “workaround” - not really, but the Sustain does not trigger IK Multimedia plugins anymore.
Just connect the MIDI Monitor Plugin

[djogon]

We’ve just got word from the IK Multimedia. They got our report and think they will be able to fix this in one of the upcoming releases.

[Angelo]

Hi djogon,
I also encountered the same problem, using the latest version:
T-Raks TR5 Black 76 Vers. 5.2.2
GP 3.7.1

the same problem is also present in another IK audio plugin.

The problem is reproducible, and I think in this case the bug is attributable to GP.

The problem occurs when loading a VST3 intruments plugin and then replacing the instruments plugin with a VST3 audio plugin such as TR5 Black.
At this point, a sustain on / off or aftertouch message triggers a change in the values ​​of some parameters on the audio plugin, in the case of TR5 Black 76 the “INPUT” parameter is modified.
I also add that any variation of a knob of my Korg TR76 keyboard connected directly via USB to the PC, has the same effect, that is, by lowering the value of the knob to the minimum, the INPUT value of the IK plugin is also proportionally lowered.

This test was performed starting from an empty rackspace.

This problem is not present if you use the same IK plugin in the VST2 version, even by making a subsequent replace of the same plugin from the VST3 version (where the problem exists) to the VST2 version.

I am attaching an image of the RS configuration in which the problem occurs.

[pianopaul]

I can confirm, I tested with the newest version 5.4

Created a new gig
included Black 76 VST3 => issue exists.

But as soon as I connect the inputs of Black 76 with an audio source the issue disappears!

[Angelo]

Correct pianopaul,
however, if you connect 2 instruments to IK’s VST3 plugin the problem recurs

[djogon]

It could very well be that the IK Multimedia testing didn’t include Gig Performer so the situation where a plugin is inserted with no connections or multiple connections are not as easy to reproduce in DAWs so they may have missed the problem.

Please repot this directly to IK Multimedia.

Thank you.