Title says it all.
I recently bought a second Kenton USB Midi to CV box (USB Solo).
Cubase can not differentiate the two. They are named the same and cannot be renamed. That is, only during a session. After closing and reopening Cubase they are named the same again.
In FL-Studio:
In Reason:
In Ableton Live:
I have the same issue with two Doepfer Dark Link boxes but I can connect one of them by Midi instead of USB.
Karel.
I am curious: Is Kenton #2 always the same hardware unit in the other DAWs? Or does it flip sometimes so that you have to find out which one of the two is #1 and which one is #2?
In all the other DAWs number 2 is always the latest installed.
If you change the name in column âShow Asâ in the Studio Setup â MIDI Setup Cubase will change it back when being started again?
I donât have two identical controllers at my place but any changes in âShow Asâ are remembered.
As I wrote in my initial post thatâs the case. If I rename one in say âKenton newâ they both are shown as âKenton newâ after a restart.
I do have four ESI M8UXL but they are shown correct btw. And I can rename every channel of them as well.
Have you tried the Use Device âWinRT MIDIâ option ?
Activates the Windows Runtime MIDI API, WinRT MIDI, that allows for native support of bluetooth MIDI in Windows, better plug and play, and better handling of multiple identical devices.
I have not to be honest. I donât know the consequences in doing so. Can anything be messed up? I mean, after renaming all midi channels could that be lost?
I donât know, for me it just adds a number next to the port, so if all the ports are different it is [0], and if you have multiple the same they will be [1], [2], etc.
Just try it, if youâre afraid to lose your custom names then take a screenshot so you can set it again it it fails.
Actually, in my case, using WinRT MIDI causes major CPU spikes / audio dropouts if I launch Cubase when it was previously enabled. If I turn it on after launching Cubase, and turn it off before closing it, the issue wonât happen. Really strange.
I donât know if the issue is from Cubase or Windows, but this is very concerning as it causes Cubaseâs audio engine to randomly reset/dropout when opening/closing/switching windows.
It isnât just related to the buffer size as, unlike regular crackling that occurs when the Peak/Real-time maxes out, the audio engine here literally resets (it creates a single dropout) and the Performance Meter also resets (goes back to zero for a few seconds) when it does that.
Would be very cool if other people could share their experience. Personally Iâm using a iConnectivity mioXM, so perhaps it will not happen with every device. 
As a workaround you can go into Device Manager and rename the devices here I believe.
I decided to give it a try. Indeed the ports are renamed and differentiated. One is called â2 Kenton Solo [1]â and the other âKenton Solo [1]â. Also, of course, all the other ports are renamed and after restarting Cubase none of them mapped correctly. But before mapping them I looked at the Performance Meter. Before using WinRT peaks were about 25%, after 75% and CPU spikes. Iâm using a Motu LP32 and Motu 828ES so these devices too donât work well with WinRT.
Thanks for your suggestions! But I wonât use WinRT. Iâll just have to remember to select the right Kenton Solo. (Iâll also have to remember to temporarily disable midi sync for some effect pedals before sending saved patches with SysEx otherwise they crash, but alas.)
Maybe Steinberg can find a solution. Ableton, FL Studio and other DAWs donât have this issue.
Renaming devices in Windows Device Manager is not possible. I tried that before. I also searched the Registry without succes.
Thatâs really interesting, because I have two M8U XLs and they have the same issue as your Kenton boxes i.e. identical MIDI port entries when using them as class-compliant. This can be avoided by using ESIâs driver, but that one tends to crash Cubase 12 (and 11 too when I troubleshooted).
Using the ESI driver causes no issues here. Indeed the driver is needed to avoid identical names. Only older versions of Cubase wonât differentiate them. Version 5 and 6 as far as I can remenber. But in those days I only had one of them.
Very interesting! If I have the driver installed, Cubase freezes at some point between startup and project loading. With the driver uninstalled it works correctly. Really odd.
Just for info in case somebody else is fighting with this - I activated WinRT MIDI in Cubase since this is supposed to be able to tell identical hardware apart, and it worked but had plenty of other issues some users described (instability, performance). However once I disabled it again, the MIDI ports remained renamed (âESI M8UâŚâ and â2-ESI M8UâŚâ). Iâm confused but for now it seems to work. Wonât experiment around now as it currently seems to work. So maybe itâs worth a try to switch it on and then off againâŚ?
As I wrote before I tried WinRT MIDI but after switching off again the Kenton boxes are named identical.
This stuff is really puzzling. I donât dare to change anything right now since it seems to be working, but no clue how to get back there if I had to do it again.
Maybe because ESI has itâs own driver? Kenton hasnât.
Itâs weird. I uninstalled the ESI driver since it tended to crash/hang Cubase on startup. Tested this several times. So I had to live with these double port entries. I know Cubase should work with ESIâs drivers, but for some reason it does not. All pretty puzzling 
I noticed this morning ESI has released a new version of the Universal MIDI drivers (v1.5) on 17-01-2023. I havenât installed them yet.
Good catch, thanks! The log lists generic improvements only, but it might worth a try next time. For now, never touch a running system