Source input filter


HI folks,

Is there anyway to filter a midi source from an OMNI input block? I am using the Fishman Triple Play guitar Midi pick up which shows up as two devices - one label FTP Guitar and one labeled FTP Control. I have recently realized that the FTP Control device is sending duplicate MIDI notes on the same channel as the FTP Guitar (rather than on channel 8 where it sends other control data).

To try to address this, I thought I would swap out the input block to just recognize the FTP Guitar channel. But to so so would mean that the data from my other controllers (expression pedals, switches, etc) would also be blocked. Those are being fed via USB into a hub. Now I know many folks here are using USB hubs, so there must be a way to use multiple hardware controllers while excluding others. What I need is a way to define which USB sources should be recognized and which should not. Rig manager does not seem to have a way to EXCLUDE or block device inputs. What am I missing? Need some help here. Filtering that input on that channel would be the simplest solution.

I saw a post where @pianopaul described creating a virtual device in the Audio MIDI app under OS X, but I was unable to get GP to recognize that "virtual"device.


Why are you using a MIDI OMNI block…use a MidiIn block specifically associated with the input device you care about to receive the notes and then use a separate MidiIn block to allow only CC events through.


have you tried MIDI Guitar 2, just curious


If you have bunch of devices connected to your system I’d agree that you really should have separate MIDI input blocks for separate FTP’s at least. Then you would connect both to the same instruments or use a MIDI filter as a “summing” block or you can connect multiple MIDI blocks to the instrument(s) directly. Something like this:


Now you can use widgets in front to bypass (filter) some inputs at will.

btw… I’m primarily playing guitars, occasionally I use MIDI Guitar 2 when I need some funky stuff that probably just touches on what you do, but I wouldn’t dismiss the keyboard players’ configurations.
They typically have a much more complicated and elaborate setups with several control surfaces, OSC devices etc. They can make use of their hands easier that we can and therefore can use a lot of cool devices we simply can’t :slight_smile:

1 Like

@djogon, I understand what you are saying and I appreciate you taking the time to respond. And I have arrived at my own (similar) solution that seems to work. But I would like to improve my comprehension so as to determine if your solution is a better one.

In your example, how are the controllers connected to a USB hub feeding the data stream? I only see two instrument sources, no controller sources.

When I tried the setup you illustrate above, my foot controllers were no longer acting upon my plugins even though they were defined in my rig manager. This would suggest that the controllers in rig manager only transmit data to the widgets, not to the plugins themselves. Is that correct?


If a MIDI event is connected to a widget - it is “consumed” by the widget so if you want to still propagate that event further you’ll have to connect it to one more widget which sends certain message through the MIDI In block.

As far as controls go - you would have to create double controls for widgets - one for each controller and put them in the same group. Then moving either physical controller would move the other one as well. You need to connect only one widget to the actual parameter that you are controlling in this case.
You can also make the second widget very small so that it looks like there’s only one widget there.


If you have multiple controllers plugged into separate ports on a hub, then each of those controllers should show up as separate MIDI devices in Gig Performer. It doesn’t matter whether it’s a controller or a keyboard…the only difference is the kind of MIDI events that get sent.


I appreciate your responses. @djogon I understand everything that you wrote. It prescribes an approach whereby I want every cc controller action to be active only at the widget level and not at the plugin level. If I want multiple parameters to be controlled by a single cc# then I should assign the widgets to groups. Is that correct?

@dhj I likewise appreciate your response, and understand what you said. You are saying that I should have a MIDI input block for every physical controller that I have connected to my USB hub defined within every single rack space I create. Is that correct?

My position is that that’s a lot of additional work for marginal benefit. What I have done is filter the note on and note off in the OMNI midi input block and then created an FTP-Guitar MIDI input block along side it to allow the data from the FTP-Guitar to feed the plugin chains. This effectively blocks the note on and note off from the FTP-Control portion of the dongle from the data stream. It works, but it seems like a round about way to filter that input. In a DAW, all I would have to do is de-select the input from that device (FTP-Control) and it would be gone. One step as opposed to several repetitive steps. See my point?

All I wanted to do was eliminate the input that was transmitting duplicate notes. Otherwise, I like the way my rig is working.


Not entirely accurate . You can assign the same CC message to any number of widgets to control any number of parameters. No need for grouping.

If you want to control the same parameter from different cc messages then you’d drop one widget per cc message and put them in a group so any of the cc messages will have the same effect.

I still don’t understand why are you resisting to create device specific midi input blocks. It is much easier to figure things and debug them when you can clearly see which device is sending what.

As a side note - if you are trying to control plugin parameters using cc messages - that’s ok, but using widgets is much more flexible.


You should avoid sending CC messages to plugins directly. Always use widgets and host automation. That indirection is a key design philosophy behind Gig Performer with many important benefits

Also, why are FTP-Guitar device and FTP-Control device duplicating events?


I forgot, I wrote a blog article on this topic a long time ago that explains the reasons for using host automation.


Please see my initial post in this thread.


Your original post said both devices were sending duplicate notes but you didn’t say why. Can you not disable the Control device from sending notes?


I use Omnisphere’s Stack feature for Multi’s and use the cc mode to create splits and/or cross fade between parts/patches in the Multi. This allows me to affect complex changes to my sound using my feet. I don’t want to add the unnecessary complexity of trying to duplicate Omnisphere’s feature set in GP. I use widgets with my other plugins that don’t have that kind of control and have designed complex rack spaces to control them. This combination works for me. Logistically speaking, I have to prepare (program) over 400 songs a year (8 songs a week). I have been doing it for 7 years. Whatever steps I can take to streamline my work flow is a blessing.

From 25 years as an engineer and record producer, I well know that Artists do not all work alike nor do they use their tools the same way. That process is part of their art. We should never try to get them to conform to a methodology. That’s how fabulous new tools (like GP) are born :slightly_smiling_face:


It is 1 USB dongle that shows up as 2 devices FTP-Guitar and FTP-Control. I am not aware of any available software available to alter it’s functionality. The FTP uses MIDI channel 8 for it’s control functions and the manual suggests ignoring this channel when recording. But for some (undocumented) reason both FTP-Guitar and FTP-Control are transmitting duplicate data. This is occurring with BOTH of my FTB dongles so it can’t be due to a faulty dongle. It’s also occurring on both my laptop and desktop computers. In a DAW, it’s easy to turn off one or the other. In my experience, most software provides a way to enable/disable input devices. GP don’t seem to have such an option.

OSX’s Audio MIDI app does not allow me to disable the port either.


@djogon & @dhj

I must admit that part of the reason I was resisting your suggestion was that I was conflating the Rig manager with the MIDI input blocks, imagining that I was going to have to create an input block for every controller. After considering the matter and tinkering, I see now that it would mean adding 3 MIDI input blocks as opposed to just 2 and that is a relatively minor affair. So I apologize for my confusion. That said, I still do not want to try to try to duplicate Omnisphere’s cc Stack feature set with GP widgets. That WOULD be a lot of work and I am not even sure it’s completely possible. Also, When I have enabled host automation in Omnisphere I have not had consistent results. In my past experiences, the host automation settings sometimes didn’t reload with the gig despite having saved the OS Multi, the rack space and the gig. Maybe that has changed in recent GP releases.

Having said all of that, I ran through a number of scenarios in my mind trying to postulate what benefits there would be to having the 3 MIDI input blocks vs just an FTP-Guitar block and an OMNI block. For my current purposes, I only came up with a few such circumstances, all of which could be solved by other means. Perhaps I am just using a simpler approach than my keyboard playing compatriots. I be interested to hear from you djogon some ways that it helps with your guitar rig.

In any case, I have all of my controllers defined in Rig manager and whenever I need to assign one to widgets, they function just fine. It’s really only Omnisphere that I don’t tend to use widget’s with. Here and there maybe mute a part or change a part level. I accomplish everything else with that plugin using cc1. And I’m able to move between my two physical rigs and two computers just fine thanks to being able to load my settings for each through the advanced settings tab.

Is there something I am still missing?

Thank you for your patience and assistance.


I don’t think you’re missing anything and it seems that you have a very good handle on things :slight_smile: Also - you are absolutely right about allowing different artists to use the tools they have in a way that makes sense to them, not to someone making the tool. We are trying to make GP as flexible as possible in this regard, but want to make sure that people don’t miss some features that may improve their workflow.

For many users GP’s way of making things work in still new and the tendency is to shove everything into one rackspace and send MIDI commands directly to plugins.

I understand your comment about sending CC messages to Omnisphere - perfectly reasonable approach - especially if it works for you.

Note On/Off messages can also be blocked in a MIDI Filter plugin if that helps as well as any other CC message so maybe that could help you a bit.

I routinely add a MIDI in block for every MIDI device capable of creating note events - if nothing else - it’s to be able to attach a MIDI monitor to each one separately when figuring out where things are going. I think there’s a benefit in having this separation.
This now allows you to select the devices you want by bypassing the ones you do not want, but also it allows you to specify that you don’t want any CC events from one device or Note events from another.

I hope this helps a bit.

1 Like

@ djogon Thank you for your thoughtful reply! The FTP is my only MIDI note creating device and only one is active at any given time.