I saw your post about smoothing midi automation sending to the users X-Touch.
Can your attached MIDI SMOOTH.BMTP be modified to work in the opposite way? For example, I have an SSL Nucleus which is sending low resolution MIDI data. I’d like Bome MIDI translator to interpolate automation points between the SSL and my DAW.
Hi Steve,
First let me see if I understand correctly. The project file you posted and the one I discussed before takes MIDI data from the DAW to move a motorized fader of the X-touch. For input the DAW is quite “jerky” in the values it uses to control the fader. The project basically smooths out the motions of the faders by putting out delays before sending to the motorized faders. For instance if a value from the DAW jumps from 1 to 20, the project will send out small increments between 1 and 20 to make the fader less jerky. It does not change the “scale” of the incoming value to a different scale of the final output value.
In this case we use pitch bend because that is what the X-touch understands (part of the Mackie MCU protocol).
A pitch bend MIDI message has 14 bits of resolution or a range of 0-16383.
A standard CC value has a 7 bit resolution or a range of only 0-127
From what I’m reading, are you asking me to modify a resolution of 128 steps coming from your SSL Nucleus to a resolution of 16384 for your DAW? If so, it would be a bit difficult unless we used two separate controls on you controller. The first to handle the LSB 7 bit value and the other to handle the MSB value. Even at that, what is the MIDI message the DAW would expect? What DAW are you using?
In initial reading, it looks like your controller may support Mackie MCU protocol so it might be better to stick with using pitch bend values if your DAW supports this. You would have to set up your controller in Mackie MCU mode or find a control on it that can send pitch bend messages.
If any of your controls can send 14 bit CC messages we could do that as well as long as your DAW supports it for input.
Do I understand your question correctly or are you also trying to control motorized faders on your controller from you DAW? If the latter, it would be pretty easy to convert incoming 14 bit high resolution pitch bend message from your DAW to low resolution 7 bit resolution on your controller.
Thanks so much for giving this a look. I’d rather not covert to 14bit just yet. The amount of CC data that my Nucleus controller sends out is much less information than most midi controllers. It skips several CC’s before sending the next bit if moving the fader quickly. On a good day the Nucleus sends about 10 nodes of midi CC data per quarter note at 120BPM. In contrast my other controllers can send more like 75 nodes of midi CC data per quarter note. Because of the low resolution of the nucleus, audible stepping happens when sending that CC data to some of my hardware synths. Please see the attached screen shot to see what I mean. The top MIDI CC lane is my Moog Sub 37 sending CC 1. The bottom CC lane is my nucleus. As you can see there is visible stepping happening in the midi.
What I’d like to do is have bome translator insert steps of 7bit MIDI CC data in-between the low resolution data points sent by the SSL Nucleus.
I was thinking that the project you built to smooth out the midi sending to the X-Controller could be modified to smooth out my SSL Nucleus output into my DAW.
Low Res SSL compared to Moog Sub 37 controller
So is the CC Just sending 0-128 values in both the top case and the bottom case but the bottom case, the controller is skipping sending some steps?
If this is the case, I think I can help. Granted you will not see any more values than 0-127 however we could use a timer like in the previous file to send out more smaller steps other than less bigger ones. Is that what you are looking for?
Hi, try this. In this case I’m using Input CC32. To test it, I’m using a button. Pushed is 127 and released is 0.
The output is also CC31 but it will make 1 step increments at 10ms intervals until it gets to the end point. This is a bit extreme but you should get the point.
To change the step value, set the global variable ia in the Init Preset “Set Global Variablse” and then hit ESC to reset all global variable. To change the delay, change the outgoing repeat delay in the “Fader 1” preset “Turn on Fader 1” translator.
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz
Your new project file is working really great. I did need to adjust the delay timing from down from 10ms to 3ms.
I do have one more problem I’m trying to solve. My nucleus is sending out in consistent midi timing and data. If you look at the above screenshot the SLL Nucleus send two nodes close together and then pauses and sends two more. The nodes are then written a bit inconsistent. So when we draw linear lines between the points with your bome project file they are still a bit jagged. Please see the attached new screen shot where the bome project drew in new points. In the screen shot the lighter nodes are the original date nodes that came from the Nucleus. The darker nodes are the ones that bome wrote in.
I think the solution is some sort of cc node compressor using an if then statement before we trigger the smooth midi rules.
I don’t know how to make the math work yet but maybe you can help me with that.
Basically I would need Bome translator to look at the difference between the last sent midi node and the newly written node. If the midi node value difference is greater or less than 10 CC values then reduce the CC value by 20%
I know this is probably possible, just don’t know how to create the rule.
What are the MIDI messages? Are they quarter tone messages, timing clock? Do you need them or can they be filtered out entirely. Maybe in MIDI Translator, you can turn on logging so I can look at which MIDI messages they are in more detail. If they are CC messages and needed, then we would have to figure out the math to adjust the amount and frequency. If they are just timing messages and not needed, we could just filter them out completely.
The midi messages are CC values. I basically just want to smooth out the difference between each value by about 20% so that there isn’t jagged lines drawn in between the values.
See how the values jumps inconsistently in this screen shot. I’m move the fader at a fast but consistant rate and the values that come back from the CC fader are inconsistent. For example the first value sent is 125 the second is 119. That’s only a 6 value difference but the next value from 119 is 99 which is a 20 value difference. So basically I want to set up a rule that if the next value is a value either + or – 10 CC values, I want Bome to reduce the difference of the value by 20%
So in this example the value jump from 119 to 99 would be converted to 119 to something like 105. This way I don’t get such drastic value jumps.
I hope I’m making sense.
OK, so now the translator will ALWAYS look at the incoming MIDI message and capture the target new CC value and then at every 3ms (per your adjustment) step to the new value by 1 (unless you again move the knob/slider). Are you saying that you only want the translator to work when the CC value is changed by 10 or more otherwise, just pass through the MIDI message unchanged? If 10 or more you want to step at 20% of the original rate so that if you went from 0-100 for instance, you would then invoke the translator and with a step of 80 (20% of 100) instead of 1?
If this is the case, you would have to compare the incoming value with the last stored value, capture the value (for next time) and then skip the rest of the rules. You would have to turn on default route so the the original message would still pass. Then for the rules, instead a step value of 1 for the timer you would have to calculate the step value based on the CC changed in rules (chaning the global variable ia before triggering the outgoing timer action). Is this what you are looking for?
This version does the following
The timer will only kick in if the change of value is greater than or equal to 10 in which case it will change the step value to 20% of the change in value and then let the timer handle all of the interim steps.
If during the time it is processing another value comes in, it will do the calculations again, however will wait until the existing timer has finished before it invokes it again. I documented the rules in the translator.
// Original rules Put value in queue always for later
h1=g1
// New rules added – only invoke if greater than 10
pp=h1-ga
if pp<0 then pp=pp*-1
if pp<10 then exit rules, skip Outgoing Action
// -New Rules Adjust precision
ia=pp*20
ia=ia/100
// Original rules Wait for existing timer to finish first
if ha==1 then exit rules, skip Outgoing Action
//timer running flag
ha=1
I still have the timer duration sent to 10ms for testing.
I’m not entirely sure if our reduce difference by 20% thing worked. It seeming like it is reducing the difference by 20% but since the next difference is way more than a 10 CC difference it essentially spits out pretty much the same staggered data just globally shifted by 20% instead of compressing the difference by 20%. I can send some screen shots so you see what I mean. Basically I want some sort of CC difference compressor. Hope that makes sense.
I’ve reverted back to our original Smooth MIDI Math file (see attached)
On to the second thing I’d like to fix is that I’d like BOME to convert CC data to a different number. For example, I’d like the incoming CC16 to be converted to CC7. I tried adjusting the attached script to listen to CC16 and spit out CC7. The problem is that all new data that BOME is writing sends out the correct new CC7. It also passes through all the CC16 data to CC16. I want to convert everything on CC16 to CC7. To work around this, I’m currently using Bidule (attached file) to convert the CC’s before they get to BOME. I’d like to get Bidule out of the equation. Can someone edit my attached SRD MIDI Smooth Math v1 file to convert CC16 to CC7 then to the extra math? You can edit the first rule that is currently looking at CC7. Change it to look for CC16 and spit out only CC7 without the passing through the original CC16 data to my DAW if that’s possible.
Last thing I’d like to work on is the CC math. Attached is three screenshots. The ‘Full View view show the top CC data with the additional smoothing math and the bottom is no math added to to the data. As you can see BOME spits out nodes very quickly once it detached that it needs to then stops as soon as it get to the next received CC value. This is great except I’d like BOME to send those CC values out at a slower rate. I think I’ve figured out how to stagger the output of each new node by introducing some ms delay into the repeat of the script. The first screenshot shows 1ms Delay. The data spits out very fast and doesn’t really get rid of the large stair step, zipper affect between the large jumps in midi data. 5ms seems to smoothing things out a little more as seen in 5ms screenshot. However, anything more than 5ms creates errors because it’s not fast enough to catch up with new data that’s coming in from the SSL controller. Check out the attached 10ms file to see the errors. As you can see the BOME translator is spreading out the data over longer intervals but it does not accurately keep up with new data coming in. Also adding this 5ms delay seems to make the fader feel less responsive.
I’d like to stagger the MIDI data out over longer spurts between the nodes coming from my SSL without adding additional lag in the way the fader feels and also without causing errors in the data. Is there a different kind of delay that can be add to stagger the new data a little wider without errors?
Hi,
On issue # 1 (20% reduction), I never saw your project file so you may have input something wrong.
I’ve modified the below project file however since I use the value of 20, it is actually reducing it by 80%.
If you want to make it 20% change the value to 80.
I’ve tested this an in both cases it work as the percentage of the “target” value which is the last value sent before the timer started. Once the timer stops the target value gets reset to a new value in case it has changed while the timer was running and the process of tracking the new target repeats.
// -New Rules Adjust precision make the below 80 in order to make it a 20% change or 20 to make it an 80% change etc
ia=pp*20
ia=ia/100
The attached project file also has a conversion from CC 31 to CC 7 and works correctly.
There are a few things to look out for if the original CC message is still getting through.
1) If there are any default routes and “swallow” is not set, the MIDI message will still get through using the default route.
2) If the rules say to skip outgoing action (even if swallow is set) the message will still go through.
For situation # 2, you can solve this by putting a “catch all” translator at the bottom. of your rules
Input:CC any CC any value
Output: None
For issue number 3, you just increase the repeate delay and yes, the fader will be less responsive with a larger repeat delay. You will have to balance delay with responsiveness.
Any MIDI messages that are missed will stay missed but the latest value will always be retained so that the timer eventually can catch up.
I disabled all but the one translator I was working on in the attached project
What tool are you using to graph the output?
I hope this helps!
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz
](https://www.bome.com/wp-content/uploads/cma_attachments/1529700683524_Low-Resolution.jpg){kind=link}
](https://www.bome.com/wp-content/uploads/cma_attachments/1529768184315_Jagged-Lines.JPG){kind=link}
](https://www.bome.com/wp-content/uploads/cma_attachments/1529770585293_CC-values.JPG){kind=link}
](https://www.bome.com/wp-content/uploads/cma_attachments/1530991547101_full-view.JPG){kind=link}
](https://www.bome.com/wp-content/uploads/cma_attachments/1530991551488_1ms.JPG){kind=link}
](https://www.bome.com/wp-content/uploads/cma_attachments/1530991554506_5ms.JPG){kind=link}
](https://www.bome.com/wp-content/uploads/cma_attachments/1530992906956_10ms.JPG){kind=link}