Two different physical connected devices impact each other status when opened or closed independntl

thx538

2020-04-21 05:51:22

Good Morning,

This a summary of a bug report submitted a few days ago, please advise/delete this post if it is not appropriate to double post here.

Problem description

I have a push2 (User mode) and an AKAI MPK225 (2nd device i.e. Channels Bxx) connected to my PC with Ableton Live 10 (Build 10.1.9 2020-02-05).

Both of them have dedicated translators to produce the same cc# (on channel # 1) on their corresponding virtual ports, which are mapped to buttons through Ableton live standard midi mapping functionality.

If I use any of the devices with the other unplugged everything is working fine, and the translators are behaving as expected.

Now if the Push 2 is plugged 1st, then when I plug the MPK 225, the status of the push 2 (user) port changes, making it unusable.
Message are flagged with [port closed] in the Log Window, while/despite reported as Open on the project.

The same happens in reverse order. if I plug MPK 225 1st, then when I plug the Push 2, the status of the MPK 225 (user) port changes, making it unusable.

My setup

Both devices are flowing through Translator Pro with the following routes in the project MIDI Router section :

Virtual ports BMT1 and BMT2 (I use short names) are activated in Ableton Live MIDI settings with "Track" and "Remote" buttons set to ON for both virtual ports Inputs and Outputs (which is necessary to capture CC and Notes MIDI messages).

Problem reproduction

This is what happens in the "Errors" Window, starting with both devices unplugged :

1/ Plug the push2

2/ Plug the MPK 225

Please note that the port status is reflected accordingly in the Project MIDI IN & OUT ports windows

3/ Press a CC key on the Push 2
I have translators implemented to track button status in Push and implement a toggle function, as well as custom colors through the CC Value.
This is what happens in the Log Window when a CC button is is pressed on my Push 2 :

The following event is the response from Ableton, since CC are mapped to some track on/off control in Live (Track activators, actually). Please note that event # has changed.

I see two probably correlated issues here :

  1. plugging or unplugging the MPK should not impact the Push 2 INPUT status (and vice versa), although it is supposedly restored after some delay
  2. even after reopening the push 2 (15 seconds later), the outgoing message should be delivered and not reported as [port closed], see event # 1689868

Please note :

Below are links to my project files :
Project: https://drive.google.com/open?id=1b-juQyDNIVFzRYN2ThQ6OBCP_9_qHTN_
Project, exported as text: https://drive.google.com/open?id=1ZG5_hWKuUfYb-jxL6nbvFfQAKiEqHtRE
Settings: https://drive.google.com/open?id=1FDvpSab4C6FHFaQbtT17vwHU93vd7_HO

Thank you for your support.
I am at your disposal for further information and hope that your isolation is going well.
Best Regards

 

 

Steve-Bome Forum Moderator

2020-04-21 14:12:58

Hi, I assume you are on Windows and not Mac, correct?

Try starting in the following order

  1. Makes sure neither MT Pro or Ableton Live 10  (or any other application that may automatically try to open your devices) are running
  2. Plug in Push 2
  3. Plug it MPK 225
  4. Open your MT Pro project file (both devices should show as open)
  5. Open Ableton Live (both devices should still as open in MT Pro

Make sure that in Ableton Live (Top section) neither of your device ports that you are using are selected since yu are not using MIDI remote scripts to control these devices (manual mapping).

Do the devices now work correctly?

 

What I suspect is happing if you do not follow this starting order.

When Ableton Live 10 starts up it looks for device names and if found, will try to assign a MIDI Remote script and use its ports (directly). Ableton Live 9 only did this on startup but Ableton Live 10 continually check the status of these ports. The second any other application closes the port Ableton Live 10 will open it and keep it open forever (until you close and reopen live).  Consequently, any other application (ie MT Pro) will never have access the device ports that Ableton Live claimed again.

So it is important that you always open MT Pro first, always keep the ports open in MT Pro so that Ableton Live never takes over (you can do this by selecting the ports at the project level in MT Pro which you have already done).

Or if you don't want Ableton Live to try and take over the ports, you can remove their MIDI remote scripts (move them outside of the Ableton Live MIDI Remote Script folder structure). However if you are using the other port on each controller still for MIDI remote script, removing the script may not be possible.

 

If after following the above procedure (starting in the orders specified), let me know as this would mean there is some other type of issue.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

thx538

2020-04-21 19:30:19

Thank you for your time

After following your suggested start order devices are working correctly,
... BUT if I unplug / replug the MPK the problem arises again.

I had already checked that none of the physical (device) ports BMT is using is referenced in live midi Ports I/O assignements, although these physical ports are "secondary" (eg. "User Port" on Push and channel B on the MPK)

Both devices have "primary ports" used directly in Live and are referenced as control surfaces, which is mandatory for PUSH.

Having read your explanation, I would tend to challenge it because once opened by BMT these ports cannot be assigned in Live MIDI settings (they turn red) .... but that is beyound my knowledge.

However, I found a workaround.

Indeed, after unplugging replugging the device, if I close and reopen (not restart) the project in BMT everything works as expected again.

 

Let me know your comment ... many thanks for your support and dedication.

Steve-Bome Forum Moderator

2020-04-21 19:37:21

comment

That make sense because Live only polls ports that have MIDI Remote Scripts attached. Since the user ports are not tied to MIDI remote scripts, they are not attempting to takeover or capture those ports. There will be a new version of MT Pro coming out that will automatically re-poll project port connections that are lost that should fix the problem. I'm not sure when it will come out but hopefully shortly. This should alleviate the need for you to close and then re-open MT Pro. Thanks for your patience!

thx538

2020-04-22 06:03:24

comment

ok, many thanks.