Hi!
So i have an x-touch and an extender. Im using them in tandem with LOGIC PRO on my Mac Studio.
the Behringer Controllers are working, but my FADERS are ‘STICKY’… Random Resistance… I have done tons of research on this. And I think it may have to do with the grounding in my Home Studio… If i grip the Metal CHASSIS with one hand, and slide the faders , everything works beautifully… but NOT when I just a finger to slide the faders.
Behringer of course tells me to hire an electrician to fix my Grounding issues in my Home Studio. I simply just done think this is going to solve it.
Problem occurs in different rooms, whether the connection is via USB or via NETWORK, or whether or not Im plugged into a Laptop / Mac Studio, Battery Bank etc…
Anyone else experience this ?
So one way I am thinking of dealing with this is with some filtering using BOME Translator pro.
I have experimented and have gotten some promising results, but am stuck .
As of now I have a translator that is filtering out PITCH BEND midi data coming from logic into a Virtual Port. It works to smooth the physical fader on the controller, and indeed is moving the fader in LOGIC, but once I let go of the physical fader, the fader jumps back to its original position. Im thinking I will need to Capture the fader position and script some way to get the fader to stick.
(1) I would really love to solve the random ON/OFF Note issues with the devices .
but (2) … If i could use BMT to help assist the situation, I would be slightly happy.
Thanks,
Signed RandomPlanet #FADERs_are_SCRATCHY#FADERS_Fight_Back#FADERS_have_Random_Resistance
I’ve found that if I touch the indented area (top) of the fader, it recognizes my touch but if I touch other areas of it, it does not and fights me.
One way to see if it it working correct is to use Bome MIDI Translator Pro to view what your X-touch is sending using the log window. If it is sending the correct thing, then perhaps the issue is with either Logic Pro not recognizing fader touch or perhaps not providing the correct MIDI feedback. If the correct feedback is not provided, they will indeed jump back when you release the fader.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Hi Steve! … Thc for the Prompt reply!
So I m indeed aware of having to ‘TOUCH’ the fader as these are capacitive faders…
What I am observing is that if you place your finger on a fader knob, and you watch the MIDI Log… You will see a NOTE OFF ; then immediately a NOTE ON for ch1… As if I LITERALLY had lifted my finger… But I did not LIFT the finger.
This occurs slightly random at about every 2 or 4 seconds… I think this is causing the Jiterry ‘Resistance’ response as I move the fader up and down (On ANY Fader BTW). So Again, Ive seen people talk about this, but I have yet to see a real way to FIX the issue… But as a BandAid / Workable solution , I thought I might use BMT to filter the pitch bend information (Fader Movement) while I am physically moving the fader and have the fader STAY in place when I let got.
Translator 1.0 will block any touch and release note-on and note-off.
Translator 1.1 will pre-pend a touch-on note message, then pass through the fader message and then post-pend a touch-off note message.
This is similar to how cheap Mackie Emulation controllers work.
I put MIDI thru paths in the router to handle all other messages.
Aliases are set up as follows:
You can learn more about aliases from this tutorial.
Preset 1 is set to route from your controller to that application.
For more information about device selection, see this tutorial.
Preset 0 handles housekeeping stuff which I use in most of my projects and won’t be discussed here.
I was trying using the workaround and it seems that there is a bit more help required to make it work.
Just a bit of background:
I’m working with Cubase and there are two ways how you can connect your control surface to it:
Legacy Mackie Control
Remote MIDI Script (new way)
Depending on the way it is connected the actual Behringer fader problem is exhibiting in 2 different ways. In Mackie Control it resets the faulty fader to unity and the reaction to touch is sluggish, the fader is fighting you.
In Remote Midi the touch doesn’t go through and the fader is fighting you, making it impossible to write automation.
I tested both variants, but i prefer midi remote as it provides more functionality for the surface.
The current workaround you provided solves the problem of determining touch, but it doesn’t solve the problem of the fader fighting. So i tested by sending fader touch then the note, then fader touch again and the jerkiness went away and the touch is now determined and keeps working as desired, but the fader snaps back into unity, after you’re done as there is no touch release message. So, my thinking is that there should be some better logic of when to send touch release.
For example, is there a possibility to introduce 5 sec of delay by sending touch ON for 5 seconds after the last pitch bend and then Touch OFF? Or maybe there are better ways of figuring out that I’m not touching this faulty fader anymore? Maybe by sending Touch On After pitch bend until another fader is touched?
Please advise. I’ll definitely purchase the software if we will find a good enough workaround and there are a lot of people complaining about this behavior on internet, so it might be very useful for a lot of folks.
BTW i extended the rules a bit to catch only the faulty faders, it looks like the syntax doesn’t allow for ‘if or if then else’, so i did this for now (only fixing the behaviour of fader 107 and 111 - this is for X-touch Extender that has 8 faders, not 9 as main module):
// check for notes
rr=oo&224
if rr!=128 then exit rules, skip Outgoing Action
// Look for fader touch notes
if pp<107 then exit rules, skip Outgoing Action
if pp>111 then exit rules, skip Outgoing Action
if pp==108 then exit rules, skip Outgoing Action
if pp==109 then exit rules, skip Outgoing Action
if pp==110 then exit rules, skip Outgoing Action
You could monitor the fader and when you see a pitch bend message, then send touch and release.
IE
Incoming Fader 0
E0 pp qq
Outgoing
90 68 7F E0 pp qq 90 68 00
This would work for Mackie MCU mode but no telling what Cubase will do in custom mode.
For custom mode you would need to ignore incoming MIDI message when sending pitch bend and then use a timer to start listening again. In both cases automation may not work correctly.
Tldr: Long story short- here i the logic i think I’m trying to get:
Exclusively for faders 107 and 111 (e3 and e7 respectively) from x-touch catch a pitch bend (fader move) and prepend this message with fader touch on.
Using timer ignore pitch bend from Application to avoid fader reset for some period of time, then send a touch note off
All other communication in both directions should be a passthrough.
Something like that…
Thanks again for your advice and support in this!
Long version:
here is the resulting script that seems to be working very close to ideal. there are 3 problems:
the rule in the translator 1.0 as i understand is supposed to filter out all but messages from Faders 107 and 111. My assumption that after this the only messages left are going to the second step 1.1. where tey are further filtered so that it is only pitch bend that is detected and reacted upon, while everything else is supposed to be a passthrough. But i probably misunderstand the directive to exit rules. i tried to put this filtering rule into every step - didn’t help. looks like it just disregards the rule.
What I’m trying to do is to make sure that only faders 4 and 8 on the extender are being considered by BOME, but it still starts the watchdog for all of them anyway.
When i try to limit it to channel e3, like in your example - the channel select stops working and it doesn’t seem like right thing to do as there are a lot of other messages coming through
some of the faders - specifically 1 and 2 (midi 104, 105) are misbehaving losing their standard functionality - they still work but they are not reacting to touch but rather to pitch bend as well as the one that I’m trying to fix (107 and 111) Also 104, 105 are losing ability to receive feedback from Cubase
the faulty faders are not receiving feedback at all - i.e. moving fader in the software doesn’t get reflected on the fader on x-touch. Not sure if this is fixable.
Overall, this looks better than 2 non-working faders - getting somewhere
Project: Faulty-X-touch-Fader-Touch-Workaround
Project MIDI IN ports: X-Touch Ext right, Cubase
Project MIDI OUT ports: Cubase, X-Touch Ext Right
Route #1: IN 'X-Touch Ext right' -> OUT 'Cubase'
Route #2: IN 'Cubase' -> OUT 'X-Touch Ext Right'
_____________________________________________________________
[x] Preset 0: Init
[x] Translator 0.0: Open Project - Init
Incoming: Project Opened
Outgoing: Perform "Init" with 1 parameters
[x] Translator 0.1: KeyStroke - Init
Incoming: Keystrokes: Ctrl(Right)
Outgoing: Perform "Init" with 0 parameters
[x] Translator 0.2: Init - Init Global Variables
Incoming: On Perform "Init" with 1 parameters
Rules:
// Initialize and document global variables used here
// Toggles bit map
// bit 0 X Air Mute
ga=0
Outgoing: (none)
_____________________________________________________________
[x] Preset 1: Process Faders
Default MIDI IN ports: X-Touch Ext right
Default MIDI OUT ports: Cubase
[x] Translator 1.0: Fader Touch and Release
Options: swallow
Incoming: MIDI oo pp qq
Rules:
// check for notes
rr=oo&224
//??? I DON'T understand this rule
if rr!=128 then exit rules, skip Outgoing Action
// Look for fader touch notes - only 107 and 111 should be of interest
if pp<106 then exit rules, skip Outgoing Action
if pp>111 then exit rules, skip Outgoing Action
if pp==108 then exit rules, skip Outgoing Action
if pp==109 then exit rules, skip Outgoing Action
if pp==110 then exit rules, skip Outgoing Action
Outgoing: (none)
[x] Translator 1.1: Faders
Options: swallow
Incoming: MIDI oo pp qq
Rules:
// Look for pitch bend
rr=oo&240
if rr!=224 then exit rules, skip Outgoing Action
// determine touch and release note
rr=oo&15
tt=rr+104
//Sending touch ON before and after makes the fader move without jerking and fighting
Outgoing: MIDI 90 tt 7f oo pp qq 90 tt 7f
[x] Translator 1.2: set timer
Options: swallow
Incoming: MIDI oo pp qq
Rules:
//set busy
g0=1
Outgoing: One-shot timer "Watchdog": 500 ms delay
[x] Translator 1.3: Clear timer
Incoming: On timer "Watchdog"
Rules:
// clear busy
g0=0
//When timer is released i send the TOUCH OFF for the current fader
Outgoing: MIDI 90 tt 00
[x] Translator 1.4: Fader 4 Ignore pitch bend
Options: swallow
Incoming: MIDI oo pp qq, on port X-Touch Ext right
Outgoing: (none)
[x] Translator 1.5: Fader feedback
Options: swallow
Incoming: MIDI oo pp qq
Outgoing: MIDI oo pp qq, to ports X-Touch Ext Right, Cubase
If you post the actual project file, I will take a look, however if the faders do not respond to remote fader commands, then your X-touch is probably broken.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Also, I’ve found with the X-touch, if you touch the top or bottom of the fader, it doesn’t recognize the touch. You need to but your finger in the concave area of the fader for it to be seen. I guess that is the only area that capacitive touch works. Seems a bit silly but over time I’ve gotten used to it.
If the faders are fighting with you, then you are likely seeing MIDI from some other external source otherwise, it wouldn’t fight.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Here is the project file. Cannot thank you enough for your help!
And yes to a degree the extender i have is broken - if it wouldn’t be broken this way i wouldn’t need to introduce BOME into the chain. This main problem there is that the unit doesn’t process touch properly on just these two faders.
Initially i thought it is a fader problem, but even after physically replacing the faders the behaviour didn’t change. So there is something in the board i guess.
But with the help of BOME i think I’m pretty close to overcoming this issue. I just want to make sure that only those two faders are processed by BOME and so no other faders are affected at all. If it is just for these two that i won’t be able to adjust the fader in the app and see it reflected on the surface it is a good enough outcome, as long as other stuff works.
It looks like you are blocking touch for faders 4-6. Was that your intent?
I changed the rules so that it will block these touch messages. Also, it will stop processing so other translators further down the list will not execute.
I added rules in your other translators to only look for specific messages.
I also added Log messages so that you can see what is happening better if you open the log window.
I didn’t test it but it looks closer to what you want.
the left most fader is 104, the right one is 111. the faulty ones are 107 and 111. It was not my intent to block 108, 109, 110 but rather i was trying to create a rule that would allow them to pass through without being affected at all.
here is the latest version based on your changes. I clarified the names of the translators and their purpose and added some clarification in comments. Faulty-X-touch-Fader-Touch-Workaround-sjc.bmtp (3.7 KB)
As of right now the behavior is overall inconsistent, i will need some time to test it more and to formulate what is going on by comparing what i see with BOM and without it.
I really appreciate all your help here - thank you!
Here is the video of the problem i have with this particular unit - https://youtu.be/KkEESedIG6U
So, i’m trying to simulate the touch (which seems to be working with BOME) for 4 and 8
Your initial solution in this thread was sending note on for touch, then the actual pitch bend message, then note off right away. But cubase is sending some pitch bend feedback message right after that, causing the fader to jump back. Hence i introduced the idea of sending the note off not right away but after a timeout, allowing to swallow the ‘unwanted feedback message’. This also seems to work, somewhat (there are some weird jerky stops on the fader way up, but i guess this is hardware BS)
Is this with the latest project file? Maybe you can turn on input and output in the log window and then copy and pasted the results so that we can see what MIDI messages are happening.
Is anything going through Bome Network Pro or is everything on the local computer?
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
No, i didn’t have a chance to test with your latest stuff - this video is about the original problem i was trying to fix - before BOME was in the picture.
BOME did help to make it work almost like it was supposed to.
I think it will work. You might get a bit of resistance when you first move the problem faders but as soon as the move MIDI message is received, the resistance should go away.
Since it is only on fader 4 and 8, I suspect it is not a grounding issue. It is either some insulation where you have the fader touch knob attached or a few broken traces on the board itself. Did you pull the touch knobs and look underneath to make sure there is no insulation? Maybe at some point someone put a shim in to hold the handle in place but resulted in insulating the capacitive touch.
I actually disassembled this unit and replaced the faders in those positions. The problem stayed. But then after some time faders 1 and 2 stopped working in the same way.
If you’re curious here is the extended video as the whole thing is kind of ridiculuous at this point. I received 3 units (all in attempt to fix the first problem). All of them are exhibiting the same behaviour on different faders. As soon as fader goes bad there is no way back, tried different scripts, even different daw, different ways of connecting and so on. This looks like elecrical issues in the units. I suspect bad batch of some mciro components.
