MIDI signal filter

[SloHand Solo]

I've got a four fader midi controller that sends constant midi messages regardless of whether the faders are moving or not.  Is there a filter or gate I can use to only record changes?

Edited October 7, 2023 by SloHand Solo

[David Baay]

So far as input filtering goes, CbB can only be set to completely ignore all controllers for purposes of recording; it's not selective and it will still echo everything in real time. MFX operate at the output of a track, which is effective to control what gets echoed, but won't limit recording; you'd have to Apply it after the fact. But even given those limitations, I don't know of an MFX offhand that's designed to only pass changing values. Most MIDI controllers are designed to only generate a new message when the position of the physical control has changed, so this isn't a very common scenario. You might have better luck finding a 3rd-party MIDI management app that can operate between the hardware ports and the DAW to do the necessary filtering. I recall looking into one of these apps a long time ago. It wasn't no-brainer cheap so I didn't pursue it, but I wouldn't be surprised if there are some pretty powerful freebies out there now.

Edited October 8, 2023 by David Baay

[User 905133]

2 hours ago, SloHand Solo said:

I've got a four fader midi controller that sends constant midi messages regardless of whether the faders are moving or not.  Is there a filter or gate I can use to only record changes?

What kind of data are they sending--CCs? Active Sensing? Sysex, Timing/MIDI Sync Bytes? Other? Is the unwanted data the result of dirty/defective pots or encoders? Is it really constant or just in a few problematic spots? 

I will defer to others who might know if there are midi data plug-ins that will suppress data changes outside of a certain range of values or other plug-ins that will detect intentional changes as opposed to unwanted changes.

It seems to me that a solution should be based on the cause of the unwanted data.

BTW, have you looked at the manual for possible intended causes?

[Promidi]

What is the exact model of your “four fader midi controller”?

[SloHand Solo]

2 hours ago, Promidi said:

What is the exact model of your “four fader midi controller”?

Its a MIDI Maker Sparrow 400

Sparrow 400

[Promidi]

I am not seeing anything on there that would be sending when the unit is not being touched.

Are the CC messages being sent to CbB the same as what any of the sliders are programmed to send when moved?

As mentioned, maybe the sliders need a bit of a clean.

[User 905133]

I looked around for a manual that that might help explain why it is constantly sending out data.  If I had purchased one of those products, I would write the maker to see what's going on and if they can fix it. 

Did you buy yours before 2022?  If so, did you update the software?

Finally, if I had the issue you described I would suggest to the maker to code the editor to have a per fader sensitivity adjustment for sending out data.

Oh yeah, I didn't see any mention of calibration.  Does the editor have a way to calibrate the sliders?  If not, I'd suggest that to the maker as well.  

[SloHand Solo]

4 hours ago, User 905133 said:

What kind of data are they sending--CCs? Active Sensing? Sysex, Timing/MIDI Sync Bytes? Other? Is the unwanted data the result of dirty/defective pots or encoders? Is it really constant or just in a few problematic spots? 

I will defer to others who might know if there are midi data plug-ins that will suppress data changes outside of a certain range of values or other plug-ins that will detect intentional changes as opposed to unwanted changes.

It seems to me that a solution should be based on the cause of the unwanted data.

BTW, have you looked at the manual for possible intended causes?

It's a new controller.  It's happening differently for each:

Fader1 - cc1:modulation - No messages before change, constant value after

 

Fader2 - cc7:volume - Variable values before and after change

 

Fader3 - cc11:expression - Constant message before change, variable values after

 

Fader3 - cc21:assigned to vibrato- no messages before change, constant value after

 

[SloHand Solo]

14 minutes ago, User 905133 said:

I looked around for a manual that that might help explain why it is constantly sending out data.  If I had purchased one of those products, I would write the maker to see what's going on and if they can fix it. 

Did you buy yours before 2022?  If so, did you update the software?

Finally, if I had the issue you described I would suggest to the maker to code the editor to have a per fader sensitivity adjustment for sending out data.

Oh yeah, I didn't see any mention of calibration.  Does the editor have a way to calibrate the sliders?  If not, I'd suggest that to the maker as well.  

They haven't responded yet, but I'll send them another email.  As you said, it could be a sensitivity issue.  There wasn't any kind of calibration, just the assignment.  If I use midi-ox I can see the constant and variable values being sent when the faders aren't moving.

I bought it about a month ago.

 

[Variorum]

Judging by pictures 2 (Fader2 - cc7:volume) and 3 (Fader3 - cc11:expression), the sliders are dirty or the Analog to Digital part of the circuit isn't very good... at least in the upper range (above 100, or so).

Seems to be some flutter. Reminds me of the the Pot controllers on the Commodore Vic-20 a few decades ago.

It appears to be a hardware issue... I don't think there's anything you can do about it in the DAW.

You may want to check all of the faders. The particular CC doesn't matter, just move them up near the top (above 100) while recording and see if they all exhibit that behavior. If so, contact the manufacturer. He may be able to fix it in the firmware by doing some averaging of the A/D samples.

[OutrageProductions]

Normally when writing CC7 and CC11, the data will continue to the end of the track at the last recorded level, as evident in your pix for CC1 & CC21. This is to be expected. The pix for CC11 & CC7 have jitter issues.

I would agree with @Variorum regarding the dirt. Use some good quality aerosol Electronic contact CLEANER (available in many hardware stores) and see if that gets rid of the jitter.

These units are using a mid-grade Bourns sliding potentiometer driving the analog inputs of an ARM Teeny 4.x uProc board converting analog voltage to a digital USB signal. You can learn to program the CC assignments yourself, but it's deeply engaging for neophytes, which is why they have the programming ability built into a Chrome Browser window. Your device connects to the server, you enter your requested data into the script, then reloads the script back into your unit.

In short... there are very few ways that the uProc A/D conversion can send out unstable or jittery data unless the input is sketchy. Clean 'em. Maybe some electronic switch lubrication fluid will extend the life as well.

Failing that, you may need a couple of the faders replaced (under warranty?!) as they are not really well quality controlled in manufacture.

Edited October 8, 2023 by OutrageProductions

[Keni]

10 hours ago, SloHand Solo said:

I've got a four fader midi controller that sends constant midi messages regardless of whether the faders are moving or not.  Is there a filter or gate I can use to only record changes?

I briefed through the thread a moment ago. I don’t know if this (or something like it) might help.

Way back in the days where all instruments were a piece of gear separate from the pc.

I still have a couple of these with all my stored hardware.

JLCooper MIDI patchbay. If I remember correctly, they had 16 discrete MIDI inputs and 12(?) discrete outputs with a fully configurable combination of connections. It also had an extremely deep MIDI filtering system capable of very specific, complex combinations of what, & how was (might) to be filtered. And of course, something like 128 patches of different setups of all this. All 5pin DIN connectors as that was all that existed at that time.

I don’t know if these are still available or not, but I’m betting there’s one or more companies out there making variations on this theme. Likely even some less comprehensive, but more focused on your needs?

 

Hmmm. Just came to mind that someone probably has a MIDIdriver loop that offers complex MIDI filtering?

Sorry for not having more specifics...

Edited October 8, 2023 by Keni

[msmcleod]

FYI,  continuous controllers such as Modulation send out MIDI messages continuously - the only exception being when their value is zero.

I had exactly the same issue with the modulation wheel on an keyboard of mine. The issue turned out to be dust in the potentiometer, which was causing it to read some resistance and was continuously sending out messages when it was set at zero.  Cleaning it with WD-40 fixed it.

Just as a side note... avoid using contact cleaner/switch cleaner for cleaning sliders or pots, as it can strip away the carbon strip.  Either use a cleaner specifically for sliders, or use standard WD-40.

[User 905133]

Thanks for the images.  Not much to add to what Variorum said and to what others added.

I have a little experience with a DIY project using a whole bunch of sliders and an Arduino Mega 2560.  It was about 10-12 years ago, but I do remember having some "jitter" under some conditions when the sliders were not moving and trying different ways to minimize it as well as speculating about other options with the help of more experienced DIYers.

I have no experience with the Teensy 4.0, but based on the information at this site my guess is that the midi controllers using the Teensy 4.0 could minimize the impact of small voltage fluctuations in any of a number of ways. 

[User 905133]

On 10/7/2023 at 7:28 PM, User 905133 said:

I looked around for a manual that that might help explain why it [a midi controller using sliders to send out CC data] is constantly sending out data.  If I had purchased one of those products, I would write the maker to see what's going on and if they can fix it. 

On 10/8/2023 at 6:03 AM, msmcleod said:

FYI,  continuous controllers such as Modulation send out MIDI messages continuously - the only exception being when their value is zero.

It almost looks as though @msmcleod is saying that the sliders are supposed to result in MIDI messages being sent out continually except when set to zero. 

I don't think this ^^^ is what he is saying, but in re-reading this thread and a newer thread that references this one, I see why there might be some confusion.

Edited October 21, 2023 by User 905133
removed a short word that was accidentally left in after editing

[msmcleod]

3 hours ago, User 905133 said:

It almost looks as though @msmcleod is saying that the sliders are supposed to result in MIDI messages being sent out continually except when set to zero. 

I don't think this ^^^ is what he is saying, but in re-reading this thread and a newer thread that references this one, I see why there might be some confusion.

Just re-read my original reply, and yes, I did make this claim, as the issue with my keyboard was that the dust inside it was confusing the device into thinking it was constantly changing, causing it to send messages continually.

This isn't the case in normal operation - you should only get a MIDI CC message sent if its CC value is different from the last one sent.  

Of course, this is all down to the firmware implementation inside the device.  There would be nothing to stop the developer of the device getting it to send out messages continually.  It should be clever enough not to if it's not changed since the last message tho.

[OutrageProductions]

1 hour ago, msmcleod said:

Of course, this is all down to the firmware implementation inside the device.  There would be nothing to stop the developer of the device getting it to send out messages continually.  It should be clever enough not to if it's not changed since the last message tho.

The Teensyduino ADC board inside these things have very stable buffers (from V3.4 onwards) and when programmed for MIDI output Continuous Controller values will only 'sit' on the last input; ie: if the linear signal changes from step 64 (+/-<0.5) to 65 (+/-<0.5), it will put out a change in the digital data stream; if the input device (analog voltage) stays between the interpretation of 63.5 and 64.5, the output will stay at 64(for example). But it does not continuously 'stream' data 64 after that. They can also be programmed for an analog (ie: audio taper) response, but that requires a different script than what is installed in the Sparrow series (afaik). I've only reverse engineered one of the units so far.

[sjoens]

Just a thought... normal WD40 is petroleum (oil) based and can attract dust, dirt and other debris which can make things worse after they're better.

DeoxIT??

Edited October 22, 2023 by sjoens

[rfssongs]

Is the device being vibrated by nearby speakers ?