Any tips on bidirectional MIDI?

Hello, everyone.

I’m hosting an instance of Vienna Ensemble Pro 7 (VEP) in Logic Pro X 10.7. I was hoping that I could get bidirectional MIDI so that when I switch presets or parameters in my VSTi (not AU), the parameters will update in the E1.

I’m able to control the VSTi from the E1, but not vice versa.

Another thing is that I can’t seem to get the “MIDI learn” function within the E1 editor to receive parameter changes from VST instruments in VEP. Not sure if that’s related to the issue.

I’ve read that some folks are using NRPN to get bidirectional MIDI, but I’m not really sure how to implement that.

Any tips? I really appreciate any advice, thx.

I’m putting Vienna Ensemble off to the side for now and I’m focusing on getting AU instruments in Logic’s tracks to feed their MIDI signal back to the E1 without using Logic’s “Smart Controls” or Logic’s “MIDI Environment”. It’s working fairly well so far by assigning the parameters in Logic’s “Control Surface Assignments” section.

Regular 7-bit E1 sliders get feedback just fine whether it be by changing AU parameters with the mouse, automation data or changing presets. However, it seems that 7-bit E1 “list faders” don’t get feedback correctly. Not a big deal. It just means I need to create 128 overlay names per each regular E1 slider that are controlling “list” type knobs in the instrument plugin, unless anyone has a better idea.

I’ll keep this thread updated as I continue my testing.

Still no luck with getting “list faders” to work in Logic correctly. However, I want to give thanks to @L56 and his excellent solution to simplify adding large numbers of overlays (Longs lists of names: how do you do it? - #8 by L56).

This definitely makes things faster adding 128 overlays on a fader!

Hi @Ricker ,
be aware I’ve no experience with VEP nor with Logic, so my answers are generic.

For your first issue (E1 not responding to MIDI learn and not responding to the VSTi), it looks like the same cause, which is the VSTi is currently not transmitting any MIDI CC out signal. If that is the case, then it won’t send out any RPN or NRPN for that matter.
So this issue is not with the E1 in itself but with VEP or Logic or its combination.


As for feeding back data from a synth into a list fader , that is a very recognizable issue. If you are not giving a ‘meaning’ to each of the 128 values in the overlay, the E1 is assuming every undocumented value to represent the first entry in the overlay, isn’t it?

There are currently two solutions possible. The easy (but tedious) one is to add an entry for each of the 128 values as you are doing currently. That is doable and workable and perfectly acceptable.

The slightly compex (but lazier) way is to create the overlay list as you would have done originally and then ensure that the controller, when receiving a MIDI CC change, is converting any undesired intermediate value to one on the list.

This requires some lua scripting. Have a look at the following script:


deviceId = 1
device= devices.get(deviceId)

function midi.onControlChange (midiInput, channel, controllerNumber, value)
   if channel == device:getChannel () and controllerNumber == 102 then 
     if value >105 then value = 110
        elseif value > 84 then value = 88
        elseif value > 63 then value = 66
        elseif value > 42 then value = 44
        elseif value > 21 then value = 22
        else value = 0
     end
   parameterMap.set (deviceId, PT_CC7, controllerNumber, value)
   end
end

=> It assumes your device is device 1, and henceforth can determine the channel it is in.
The callback function “onControlChange” is triggered whenever a MIDI CC is received by the E1.
This script only checks for CC 102 on the device’s channel. In that case it will convert any received value to 0, 22, 44, 66, 88 or 110 according to the given conditional formula. Of course other formulas are more elegant but this example serves the purpose well. Lastly it will put the final value in the parametermap of CC 102.

Here’s how the list fader itself is looking like

This list fader is behaving correctly in both directions

1 Like

Greetings @NewIgnis and thank you VERY MUCH for your time and advice!

I suspected that a solution could be had via either JSON or LUA script editing, although I had no idea where to begin.

Indeed when an undocumented value is selected, the E1 goes to the first entry, as you predicted.

I tweaked your code example to test one of my E1 “list” faders. Works like a charm with automation data, parameter changes via mouse, and the E1 all in sync. For “list” parameter appropriate control, this is a MUCH better solution than ham-fisting 128 overlays into a normal fader. Can’t thank you enough!

deviceId = 1
device= devices.get(deviceId)

function midi.onControlChange (midiInput, channel, controllerNumber, value)
   if channel == device:getChannel () and controllerNumber == 2 then 
     if value >=100 then value = 127
        elseif value >= 75 then value = 95
        elseif value >= 50 then value = 63
        elseif value >= 25 then value = 31
        else value = 0
     end
   parameterMap.set (deviceId, PT_CC7, controllerNumber, value)
   end
end

Upon further testing, it seems that I may need to go back to using normal faders and just enter overlays for all 128 values.

The issue is that with parameter automation within Logic, or parameter changes via mouse within the AU instrument itself (U-he Diva in this case), although the E1 jumps to the correct parameter as expected, either Logic and/or Diva won’t accept further E1 parameter change input on that particular CC until I physically dial the E1 fader knob away from the currently selected parameter, and then back to it. At which point, Logic/Diva will again accept E1 value change input.

This is a non-issue with normal faders.

Thanks for the feedback @Ricker

1 Like

I wonder if some “MIDI echo” scripting is possible so that after a parameter change in the DAW and/or softsynth, the E1 would then echo back this new CC value.

If it’s possible, then perhaps this will eliminate the “list fader” issue currently with Logic/Diva.

AFAIK all vst and vsti (and probably all au as well) do not have an api to send values on request. It is simply not part of the vst specification. The only way to get bidirectional support is over the daw automation, which means using a midi remote script in ableton etc.

1 Like

Good to know @markus.schloesser, although I was hoping to find a way for the E1 to echo back its CC value upon external change. So, Logic would transmit the change value to the E1 and the E1 would echo back its current CC to Logic.

It seems there’s an issue when using the LUA script since the E1 in this case is transforming certain value ranges into a specific fixed value and I guess the E1 needs to transmit this new CC value back to Logic.

I may be totally wrong (total novice here), but it appears that Logic doesn’t realize that the E1’s value has been changed from what it last sent to it and Logic and/or Diva won’t accept further value changes on that particular CC from the E1 until I dial the fader away from and then back to the transformed value.

There must be an equivalent to a midi remote script in Logic which mirrors value changes to the outside world, have you tried that?
Edit: there is an article in last months sound on sound about using the environment to achieve that.
Also found an older entry here (Motorised Faders For Midi CC - Why No Options? - Logic Pro - Logic Pro Help) which states that while possible in general, it might be a hassle.

2 Likes

Try the following: after the parameterMap.set statement, add a parameterMap.send statement. This will force the E1 to transmit the new control value.
The arguments to use are in the documentation section.

However a word of caution: if every time you try to change the value of a control in a continuous manner on a vst, that in turn is locked by the E1 using the script above in certain slots, you might find you can never escape anymore out of one preset, which I think will be the undesired effect of using this midi CC echo. Are there any other solutions? Probably , but for this I’d need to dive into these specific vst’s, which unfortunately I do not yet intend to.

I’ll keep an eye on this thread though, in case some creative mind comes along.

2 Likes

Thank you @markus.schloesser and @NewIgnis for the brainstorming and ideas. I will be doing some testing this week and see how Logic responds with the “parameterMap.send” and check out that motorized fader article.

In the end, I can always use normal faders instead of the preferred “list” type, so we already have that as a solution. Although cumbersome to set up, works without issue.

Thanks again for the advice you two. I’ll report back with my results and findings.

1 Like

I took a look at Logic directories and I found Lua scripts there that implement the remote scripts for various MIDI controllers. I did not find any documentation, but inspiration can be taken out of the existing stuff. I will take a look at that.

3 Likes

Thanks for the tip on the Lua scripts @martin ! As I progress through my testing and findings, I’ll report back with anything of value. At worst case, I can just use normal faders which seem robust and widely accepted, but ideally, list-type faders for list-type controls would be best if I can get them to work.

Thanks again everyone for all the great tips and advice. While I continue mulling over the possible solutions, I’ll be doing some testing on getting one of my hardware synths set up with a preset and I’ll revisit the “list” fader situation with Logic/Diva afterwards.

I’m really enjoying learning everything I have so far. I’m pretty much a beginner with all this stuff and the more I learn about the E1 and all the capabilities it has, the more I fall in love with it! BIG THANKS to the E1 community here for helping me along the way!

2 Likes