New to XMidiCtrl - some Qs

[beebon]

Thanks for doing this plugin, it's very cool and nicely implemented (and the documentation is excellent too!) - I use MIDI controllers for a lot of reasons outside of music, so it's great to have this functionality for X-Plane.

Firstly, another vote for Apple silicon support, but I've seen the dev is working on this so that's good news.

Secondly, I'm starting to implement my controller strategy, so I'm wading through the docs and seeing what the options are. One things I can't see in the docs/FAQs etc is that I'd like to use my Behringer X-Touch One fader to control the throttle absolutely (like the throttle slider on a typical joystick etc).

I can't use the "slider" type for this, as that's just a three position function. I can't use an encoder, as that's basically designed for relative or absolute knobs, but seems to support CCs only unless I'm mistaken - so is there anyway I can map this fader to the throttle control?

The fader puts out a 14-bit pitch bend message on MIDI channel 1 (so that's from -8192 to +8192 total range), and you can't change the message this sends on device, it's fixed. Obviously, this would need to be scaled to a 0 to 1 range for X-Plane control, at whatever resolution X-Plane supports. Is there any way of doing this, or is it a feature request type thing?

Thanks!

Edit: Ah, just found it in the docs after I posted - seems like pitch bend *is* a supported control - will give this a try! I'm not sure offhand what pitch bend "number" represents ie "pitch = 0" in the control definition, as that's somewhat non-sensical for MIDI - it's a pitch bend event, on a MIDI channel, with a value that's mapped to the destination. Unlike a CC, it doesn't also have a value that identifies the pitchbend message.

Edited November 1, 2022 by beebon

[beebon]

No luck with pitch bend so far. Instead I've converted those to CC messages, but when I do:

{ ch = 1, cc = 1,  mode = "range", type = "enc", dataref = "sim/cockpit2/tcas/targets/position/throttle", value_min = 0, value_max = 1, modifier_up = 0.02, modifier_down = -0.02 }

I get "Invalid index '-1' for dataref 'sim/cockpit2/tcas/targets/position/throttle'

I know the dataref is good as I'm using it elsewhere. Does the "-1" error mean perhaps this dataref is not writable?

(In fact, any of the throttle datarefs I try, including the helicopter collective datarefs, give the invalid index message.)

If so, any tips on how to control the general throttle via a CC message?

Edited November 7, 2022 by beebon

[Pils]

6 hours ago, beebon said:

sim/cockpit2/tcas/targets/position/throttle

This is very much not the dataref you want.

[beebon]

On 11/7/2022 at 7:48 PM, Pils said:

This is very much not the dataref you want.

Thanks for the reply - that's completely possible, I'm relatively new to XP so am still finding my feet a little.

This one does display the throttle value correctly (I'm using it elsewhere for monitoring the throttle). I've tried a few others, including ones I used earlier in other scripts, eg I think this one was the first I was using:

sim/flightmodel/engine/ENGN_thro

and this one for helicopter collective:

sim/flightmodel/engine/POINT_pitch_deg

...all with the same result - invalid index -1

Any clues as to a general dataref that is the general throttle setting that you assign to your main stick controls that I can try? I've searched for throttle in the XP interface and the dataref docs and have tried any that seem like they could be the one I want.

Edit: Ok, it looks like the invalid index message is due to those datarefs being arrays... that should hopefully fix this...

Ok, I'm starting to get this to work now, both with CC and pitchbend messages to control throttle, which is great! Seems to be working well so far, and now I've got something initial going, I can customise it a bit. Having it work with PB messages is great as it avoids a clunky workaround to convert PB to CC on the way in... it's actually working out really great.

I would like a way to reference the MIDI device by it's *name*, not it's ID number in the list of devices, as this can change as various MIDI devices come and go and the list gets reordered accordingly.

Also I see the author is working on native Apple silicon binaries as well, which is also good news...

Edited November 8, 2022 by beebon

[VirtualCPT]

Hi,

I'm very glad that you get things working so far.

Just a quick note. Sliders support two modes, the command mode with three commands (up, middle, down) and a dataref mode for min/max values. There is actually an example in the documentation:

{ ch = 11, cc = 0, type = "sld", dataref = "tbm900/knobs/lights/panel_brt", value_min = 0, value_max = 0.90 }

 

What do you exactly mean with the following sentence?

Quote

I would like a way to reference the MIDI device by it's *name*, not it's ID number in the list of devices, as this can change as various MIDI devices come and go and the list gets reordered accordingly.

There is not really a ID for MIDI devices. Just same name and the two ports.

Thanks,
Marco

[CVH]

Is there a reference for the data refs and commands that are available for the aircrafts? 

[beebon]

On 11/17/2022 at 8:29 PM, VirtualCPT said:

Sliders support two modes, the command mode with three commands (up, middle, down) and a dataref mode for min/max values. There is actually an example in the documentation:

Thanks Marco - yes, I did find this and get things working - it's working great actually!

On 11/17/2022 at 8:29 PM, VirtualCPT said:

There is not really a ID for MIDI devices. Just same name and the two ports.

What I mean is - let's say I ennumerate a list of MIDI devices on the system (well, MIDI ports in terms of the system), and my controlling device is position/port/ID 4 in the list. In the current config, I say "Ok, this is the setup for midi device at #4" and follow it with the setup.

That will work all the time that device remains at position 4 in the list of connected MIDI devices.

But the next time I run things, I have a different selection of MIDI devices available (I'm a musician, I have *many* MIDI devices ). Maybe now my controller is at position/port/ID 6 in the connected MIDI devices list. My controller config will stop working, because the script is listening for events on port 4, but my controller is now transmitting on port 6. I have to either edit my script, or work out what combination of devices/ports to deactivate to try and get back my device to #4.

What I'd like (or perhaps there are other solutions to this) is in the script to say "This is the setup for the port named 'X-Touch'", and the script looks at the list of MIDI ports, matches "X-Touch" to the port list and says "Ok, we found this device on port 6". (Or port 4, or wherever that devices is connected etc.) Now the controls for this device will never break, regardless of what MIDI devices/ports are available and where in the list the desired device is listed (as long as the device is connected, of course).

Hope that makes sense - basically, I want to reference a MIDI device in the script by name only, not by position. The name doesn't change, but the position does.

On 11/23/2022 at 1:54 PM, CVH said:

Is there a reference for the data refs and commands that are available for the aircrafts? 

You can get at this in the datarefs section in X-Plane, and X-Plane developer docs, and external websites have lists.

Edited November 24, 2022 by beebon

[beebon]

There is something else which I need, and tried to setup, but I'm not sure can be achieved with XMidiCtrl.

I'd like to echo back the incoming MIDI I'm using to control, say, throttle (PB messages in this case) back to a MIDI output while it's changing.

I thought that if I set up an output dataref section on the throttle, that when it changed, it would output that data back to the output port, but this doesn't seem to happen for me (very possibly user error, of course).

The reason for this is probably too geeky to go deep into, but basically - using the Behringer X-Touch One, when you move it's fader to control something, the X-Touch requires the same message feedback coming back to store the current fader position, otherwise after a second or two it's released, it snaps back to zero. So what I need to happen is that the fader sends PB messages to control the throttle dataref, and the throttle when changed, also sends back out PB messages to the XT so it keeps the fader where it is.

I have a workaround for this using MIDIpipe to echo back it's generated PB messages to the XT, but it would be nice not to have to use this workaround as it's a little clunky.

Is this possible in XMidiCtrl?

Thanks!

[VirtualCPT]

Hi beebon,

It should be possible to send a midi message after a dataref has been changed. It doesn't matter if this dataref has been changed by X-Plane itself or an incoming midi message. Could you share your toml profile with me, please?

I'm also looking into your other request of having variable ports - but that's not so easy to implement. My worries are if you have the same midi device twice.

Thanks,
Marco

[beebon]

On 12/5/2022 at 7:58 AM, VirtualCPT said:

It should be possible to send a midi message after a dataref has been changed. It doesn't matter if this dataref has been changed by X-Plane itself or an incoming midi message. Could you share your toml profile with me, please?

Ok thanks for confirming it should work, I'll give it another try.

While testing this, I just have one line in both the mapping_in and mapping_out sections for the same device:

  { ch = 1, pitch = 1,  mode = "range",  type = "sld", dataref = "sim/flightmodel/engine/ENGN_thro[0]", value_min = 0, value_max = 1 }

...the hope being that as I send Pitchbend messages from the controller to change the throttle value, XMidiCtrl should essentially send the same PB messages back to the controller to update the fader position.

 

On 12/5/2022 at 7:58 AM, VirtualCPT said:

I'm also looking into your other request of having variable ports - but that's not so easy to implement. My worries are if you have the same midi device twice.

Yeah, I'd keep the current manual ID system as it works now (which would at least handle that), and have selecting a device by name as an alternative/optional addressing scheme.

I could think of ways of extending it - for example, when building a list of MIDI device names, if you have multiple devices with the same name, you can add an instance number, so for example, to reference the first "LaunchControl XL", you'd specify as a name for your device mapping in the config file like "LaunchControl XL #1". This doesn't help if the list gets reordered though, as you might be referring to the incorrect device if the order changes - but then the current ID scheme also fails if that happens anyway, as it again just uses the position in the current list of devices. And if there is only, say one "LaunchControl XL" device found, but the user has mappings for "LaunchControl XL #1" and "LaunchControl XL #2", say, you just use the first device, and ignore the mappings set up for additional devices which aren't available.

Given what the system reports for a MIDI Port (especially cross-platform), it's difficult to always reliably detect which of multiple devices you are referring to consistently. At least referring to devices in the toml files by name will handle a lot of scripts that would otherwise stop working when the list of devices changes and your controller is now in a different position and has a different ID.

Thanks!

Edited December 14, 2022 by beebon