2 Instances of Bomes MT cause confusion for Live because of the identical naming of the virtual Midi ports

Hello,
longtime happy Bomes MT Pro user here

But I have run into the following problem.
I split my Midi translation into two Bomes MT projects run in two instances of Bomes MT Pro.
(This would not be strictly necessary, but it tremendously helps with the stability of Bomes MT which before crashed mid-set quite often)

So now I have the problem that since the virtual Midi ports are named identically in both instances and Bomes pretty randomly assigns the "2" moniker to resolve this that my Midi routing to Ableton Live often stops working (sometimes mid-set!).

To clarify a bit more: The port i.e would be named "Bomes MIDI Translator 1 Virtual Out" So that's what I used in my translators as my outgoing port in one project. And I would not reuse this port in the other project used in the other instance. In Ableton Live I then use this port as the Midi Input. (Where it is named: "Bomes MIDI Translator 1")

When I started using the second instance new ports started to show up, named thusly "Bomes MIDI Translator 1 (Bomes Software GmbH & Co. KG) (2)" which in Live shows up as "Bomes MIDI Translator 1 (Port 2)"

This leads to the above mentioned situation since Bomes MT doesn't seem to be able to decide which project (or instance) gets to send which. Or alternatively Live can't decide which is which.

After lots of fiddling I usually get it resolved, but this is really stressful in live situations, especially since it has happened that the ports switched around mid set!!! (making all my controls all the sudden inoperably )

Is there a way to resolve this? I tried renaming the ports via aliases, but these aliases don't show up in Live, so I'm not sure I understand the point of this option.

Btw. I'm still on 1.7.2, since I don't like to change things around when they are working. If this is something that got resolved in later versions I would of course up-date right away.

Anyways, thanks for any help you can give me.

Cheers Tom


Edit to add:
A bit more info for why I'm splitting the project into two instances.
I have one instance that constantly gets A LOT if MIDI information from Live (via clip MIDI envelopes) and translates them to trigger LED lights.
And then I have one that does all the important stuff of controlling Live via 6 different controllers.
This is a much larger project but it does not need to process nearly as much Midi input (my hands can only move so fast )

Previously it happened on occasion that Bomes would freeze mid-set. And though a restart is very quick, the current state of all my controls via all the global variables is lost. Which leads to lots of confusion trying to rescue my set while resetting all the controls.

Now after the split that freezing doesn't happen any more and even if it would, it would probably be the first instance that chocked on all the MIDI input that froze. Restarting that is no problem at all, since no important variables are lost.

Ok, I think I found a straight forward work around.

Since the project/instance that controls the LEDs only needs one virtual port I just changed all the ports it uses to virtual port 1 and only opened 1 virtual port in total in that instance. (while I had it use virtual port 4 before, with the other three unused (since they are used in the other project).

The other project still opens 4 virtual ports of which it only uses ports 2 through 4.
This still doubles virtual port 1 (and thus still causes the confusion mentioned in the op), but it is much easier for me to remedy (one click in Live) and it doesn't make my controllers unusable when the confusion occurs (it just stalls the LED lights for a while until it's fixed on my side with a click).

So easy peasy

I'll report back if it still causes problems. Otherwise please consider this issue solved


In that context I guess I could drop the feature request that would solve this, without being to complicated to program (I assume, I really don't know much about the challenges involved though )

The suggestion would be to change the panel where one turns on the virtual MIDI ports such that instead of just saying what number of ports you need, to say which of the ports you want.

So if I want 2 virtual MIDI Ports instead of:

Number of Virtual MIDI Ports:
1 O
2 x
3 O
4 O

etc

You make it:

Activate the following Virtual MIDI ports:

1 O
2 x
3 O
4 x


So I would activate 2 ports, but they are not necessarily ports 1 and 2 but can also be ports 2 and 4.

This would be a very straight forward way to never double ports and not open more ports in a project than you really need.

Hi,
interesting problem. I assume you're on OS X? On Windows, you'd get the desired behavior, but on OS X the virtual ports of a second instance are just added, causing naming conflicts. We have improved the behavior on MIDI port name conflicts a lot in version 1.8.1. The goal is to always use the same order for adding port indexes if ports with the same name exist. This is particularly important when attaching multiple devices of the same type. Here, it might help, too.

My main headache with your setup, however, is that you had MT Pro crashing! Most important, above all, is: MT Pro never crashes...

Could you please try with MT 1.8.1? It does have a number of improvements for performance and stability. You can keep 1.7.2 installed in parallel.

Thanks,
Florian

florian wrote:Hi,
interesting problem. I assume you're on OS X? On Windows, you'd get the desired behavior, but on OS X the virtual ports of a second instance are just added, causing naming conflicts. We have improved the behavior on MIDI port name conflicts a lot in version 1.8.1. The goal is to always use the same order for adding port indexes if ports with the same name exist. This is particularly important when attaching multiple devices of the same type. Here, it might help, too.

My main headache with your setup, however, is that you had MT Pro crashing! Most important, above all, is: MT Pro never crashes...

Could you please try with MT 1.8.1? It does have a number of improvements for performance and stability. You can keep 1.7.2 installed in parallel.

Thanks,
Florian

Yes, I'm on OSX (Mavericks)
I will update then this week mostly for the Midi port problem to see if it helps.

The crashes usually happened after a long while of using it under the full load of constantly being bombarded with MIDI (an hour or two normally). (It crashed in the form of freezing and the only way to get it responsive again was to force its shut down) And it definitely does not happen all the time (only when it is really inconvenient ). So it might be a while to suss out if it got solved for me.

Hi Tom, thanks. Would be great if you could test 1.8.1 with the "all in one" project, i.e. without running two instances. And see if it crashes. I'll look into a way for getting a core dump (so that I can see what's happening) of a frozen program and report here.
Thanks,
Florian

Well combining separate projects is not that simple. (hence the request for being able to save presets too.)
And after the previous separation, the further development of the separate projects has not stood still, so the combined project from before is quite outdated by now.
I will see if it merits the work just to test it.

So far I have done the update to 1.8.1, and tried to set everything up without flaws (I gave one instance long names and one the short ones, thus no doubling if MIDI port names ), but it seems new (strange) issues have arisen. I hope to solve these first, before I try to set up the combined project with 1.8.1.

I'll get back to you

thanks. I hope the new issues resolve, otherwise we'll take care of them
And you know that you can copy and paste entire presets?
Have you set up 2 different copies of MT Pro with different filenames?
Thanks,
Florian

florian wrote:thanks. I hope the new issues resolve, otherwise we'll take care of them
And you know that you can copy and paste entire presets?
Have you set up 2 different copies of MT Pro with different filenames?
Thanks,
Florian

Very busy atm, so things take time here. But thanks for taking an interest.

No, I don't know how to copy entire presets. I found on page 73 of the manual the following:
Open Merge: Merge Project - Opens an existing Midi Translator project file and merges presets with open project

This seems to be what I'm looking for, but I don't find the "Open Merge" option in the "File" menu or the the "Open" submenu.

So the only thing I see is "Open" which just replaces the current project with the selected one.

What am I missing?!

An yes I do have two different installs with different file names.

PS: I now had several crashes when saving.
Luckily it still saved, before crashing, so no work was lost.
But I thought you might want to know.

Bump

I'd still like some more info on how to transfer/copy presets between projects, so that I can merge them without choosing the "save to text" option which involves a lot of copy and pasting and setting up all the translators over again.

Have you tried this?
- open project A, select the presets, hit Copy (Ctrl-C or Cmd-C, or menu Edit|Copy)
- open project B, select a preset as insertion point, and hit Paste (Ctrl-V / Cmd-V or menu Edit|Paste)

Should work!

Regarding crashes: can you please send us the crash log/dump? Thanks!

Regards,
Florian

Maybe it should work but it doesn't. I can copy/paste text from inside the translators via this method between projects, but for whole translators and presets nothing happens when you hit "ctrl V" in the other project. (and in the menu "paste" remains greyed out in the other project)

In any case the waiting for a response was so long that I now did all this copy and pasting and setting up all the translators again by hand (took me a few hours) and I am trying out this newly combined project extensively to test if it is stable. (so far so good - but the crashes always happened somewhat randomly.)

Regarding the crash logs: where can I find those?