Midi rescan utility or on midi device fail

[DamianAdams]

when the midi is lost saying no keeps the settings but the midi will no longer work until you close down the cakewalk and restart the app.

We need a way to rescan the midi and reinitialize it so it can work again without an app restart, its been like this for years, it's one of the things that put people of using the product, better to fix problems like this than add new features, even if it means a manual reinitialse on the preferences midi menu, it must be possible as it knows when they are lost.

[chuckebaby]

Is it possible BomeMidi is causing issues ? What OS are you using ?

[Robert Bone]

With USB-connected devices, Windows will 'turn off'  those devices, by default, after some period of inactivity.

That then makes the device non-functional.

The fix, is to alter the Windows behavior, so that it won't turn off those devices.  There are a couple ways to accomplish this.  One way is to change the Advanced Power Plan options, under USB Selective Suspend - set it to Disabled.  Another way, is to change the Power Management options for any such USB-connected device, and for any USB Hubs, which you can do in Device Manager.

To get to the Power Management options in the Properties dialog box, for either a USB-connected device, or a USB Hub, right-click on the Windows 10 Start button, and click on Device Manager.  Then, expand the Sound, Game, and Video Controllers tab, and double-click on your USB-connected device, to bring up the Properties dialog box for it.  You will see a tab for Power Management there, and once you click on that, you will see an option with a check box for allowing or not allowing Windows to turn off that device to conserve power.  Remove the check for that option, and click Apply.  Do the same for any other USB-connected device, and for your USB Hubs - (those are under the Device Manager category - Universal Serial Bus Controllers.  Please note that some USB Hub entries will have a Power Management tab, in their Properties dialog box, while others will not.  If no Power Management tab for a given hug, just move on to check the next one.....).

Bob Bone

 

[Starship Krupa]

Two swinging strikes. It's a feature request, not a tech support request.

The screen cap of the disconnection dialog is to demonstrate how Cakewalk is able to tell us that it's lost a MIDI device, not to solicit suggestions for how to stop the MIDI device from getting lost. He may need help with that, but he wasn't asking for it here.?

For the purposes of what he's saying, it doesn't matter why his MIDI devices get disconnected and reconnected, MIDI devices get disconnected and reconnected in the age of hot-plug capable interfaces like Firewire, Thunderbolt, and USB. All the time, at the worst possible time.

He's saying that if Cakewalk can notice "on the fly" that a MIDI device has become unavailable, it seems like Cakewalk should be able to rescan for newly-connected or reconnected devices without having to exit and restart. Even if the user has to go into Preferences and trigger the rescan manually, it would be better than having to stop everything, exit the program, start it again, and reload the project just because a USB cable got bumped out. Or in the case of a virtual MIDI device, the program supplying it crashed and had to be restarted.

[Robert Bone]

6 hours ago, Starship Krupa said:

Two swinging strikes. It's a feature request, not a tech support request.

The screen cap of the disconnection dialog is to demonstrate how Cakewalk is able to tell us that it's lost a MIDI device, not to solicit suggestions for how to stop the MIDI device from getting lost. He may need help with that, but he wasn't asking for it here.?

For the purposes of what he's saying, it doesn't matter why his MIDI devices get disconnected and reconnected, MIDI devices get disconnected and reconnected in the age of hot-plug capable interfaces like Firewire, Thunderbolt, and USB. All the time, at the worst possible time.

He's saying that if Cakewalk can notice "on the fly" that a MIDI device has become unavailable, it seems like Cakewalk should be able to rescan for newly-connected or reconnected devices without having to exit and restart. Even if the user has to go into Preferences and trigger the rescan manually, it would be better than having to stop everything, exit the program, start it again, and reload the project just because a USB cable got bumped out. Or in the case of a virtual MIDI device, the program supplying it crashed and had to be restarted.

I agree - as I understand it, Microsoft never built a means of retrieving some set of information needed to be properly able to do that - I have, on a couple of occasions, tried to look into any programmatic way to find out what devices are connected to which ports, and came up empty - I did so early this morning, and went into a whole bunch of the fields you can select on Device Details of the Properties dialog for my USB-connected audio interface, just as an example, because I do not currently have a midi controller connected, because I am moving stuff around.  

Anyways, I also went into the Registry, looking at the Device Parameters, and other places, trying to figure out any way to get enough information to be able to write some sort of utility program to ferret out the info - and still, I have not yet found anywhere I can get that information.  I am just not good enough at Microsoft Windows 10 internals to figure it out, though I WILL keep trying.

IF I can figure out a way to programmatically get the info, I will create a litle utility to display everything, and I will, of course, pass that along to the Bakers.

VERY frustrating - ALWAYS has been like that, and I KNOW that the Bakers have approached Microsoft with the issue, on more than one occasion, and never were able to get Microsoft to do anything whatsoever about any of it.  The Bakers have been frustrated with this issue for many, many, years.

I will continue my quest, because SOMEWHERE, buried in Windows, that information must exist, so perhaps there is a way to do the digging to find it, and that is what I will continue to pursue.

Apologies for my Windows internal skills not being better - am workingh on it.  I have built some little utility programs for myself, going all the way back to 32-bit XP Pro, but most of my programming languages and experience (38 years) was on mainframe systems, (COBOL, Assembler, DB2, CICS, was a DBA, etc..).  Most of my PC-level coding has been in C#, which is fine, but I do not yet know all the routines and API calls to easily know where to go look for the info - I am working to correct that, because it will help me when I want to write utilities or whatever.  I WILL get there, because I am also stubborn. 

Bob Bone

[Robert Bone]

By the way - even though I have the USB Selective Suspend parameter disable, in my custom power plan, sometimes, regardless, specially after those big cumulative updates to Windows, I sometimes go back in and check, and find that, somehow, the Power Management tabs for some of the USB hubs are checked back on - to allow Windows to turn off USB devices connected to that hub.  Pisses me off, that this occasionally happens, but sometimes it does - so I suggest folks take a look at the propeties dialogs for the various USB hubs, after those major updates, just to make sure Windows hasn't sneaked those paramaters under Power Management, back on.

Bob Bone

[Starship Krupa]

16 hours ago, Robert Bone said:

I have, on a couple of occasions, tried to look into any programmatic way to find out what devices are connected to which ports, and came up empty

Forgive my own ignorance of Windows programming and so forth, but why is it necessary to know "what devices are connected to which ports?" Acoustica Mixcraft runs on Windows and if I plug in my Midisport UNO while it's running, a couple of seconds later it throws up a dialog telling me that another MIDI device has been added to my system. Then I go into Preferences and the Midisport is listed along with my Korg and PreSonus.

Cakewalk itself seems quite capable of enumerating my system's MIDI ports after it's been closed and relaunched. Is there something that occurs to make it lose that capacity after it runs for a while? If so, can it be reversed?

[Robert Bone]

2 hours ago, Starship Krupa said:

Forgive my own ignorance of Windows programming and so forth, but why is it necessary to know "what devices are connected to which ports?" Acoustica Mixcraft runs on Windows and if I plug in my Midisport UNO while it's running, a couple of seconds later it throws up a dialog telling me that another MIDI device has been added to my system. Then I go into Preferences and the Midisport is listed along with my Korg and PreSonus.

Cakewalk itself seems quite capable of enumerating my system's MIDI ports after it's been closed and relaunched. Is there something that occurs to make it lose that capacity after it runs for a while? If so, can it be reversed?

I am not sure what info is needed to keep things connected or to be reconnect.  I think it is because of the internal way Windows keeps track of which device is plugged into what port, some kind of numbered identifier, I think,  because Cakewalk does not know which port a device is plugged into, all it knows is a device is present, so if the port changes, Cakewalk doesn't know if the connecting USB port is the same or not.  I dunno.

I will shoot an email to Noel or someone else, and ask what info the have available about USB-connected devices and about the ports, and I will ask for details on what they have been trying to get from Microsoft - I will post back when I get a reply, and try to dig up whatever info it is that Cakewalk needs.  Maybe if I dig into whatever it is they say they need and don't have, I can help find something out.

Bob Bone

[User 905133]

On 5/26/2020 at 6:15 AM, DamianAdams said:

when the midi is lost saying no keeps the settings but the midi will no longer work until you close down the cakewalk and restart the app.

I was curious about this, so I started testing what happens with Cakewalk on my PC when I turn off the power switch on my usb midi keyboard.  So far I have only tested this 2-3 times with a single project, but the issue seems consistent and problematic.

I will probably retest a few more times, but it seems that: 

• answering "No" at the "keep the setting" disconnected device detected dialog does not require rebooting Cakewalk once the device was turned back on--though it had to be unselected in Preferences > MIDI Devices (and applied) and then reselected (and applied).
• answering "Yes" at the "keep the setting" disconnected device detected setting did require rebooting Cakewalk once the device was turned back on because it was removed from Preferences > MIDI Devices.

Note: I am not disagreeing that there is a problem that needs to be resolved. At least on my PC, in the first condition (above) I found it problematic that when I switched the power to the usb midi keyboard back on and then said "Yes" to add it now, I had to go into Preferences > MIDI Devices and then disable and re-enable the device before the keyboard saw the incoming MIDI data. 

UPDATE: After testing condition 1 several more times, I found the results were inconsistent.  Sometimes I had to unselect and then reselect the controller before it would register keypresses; sometimes I didn't have to do that. Also, a few times I played notes after switching they keyboard back on but before the "Do you want to add . . . " dialog and the keyboard notes played the softsynth.

In all cases I did not have to restart Cakewalk after I had said "No" when I had switched off the keyboard controller. 

Edited June 4, 2020 by User 905133
(2) to add the results of additional testing; (1) deleted redundant "so far"

[Starship Krupa]

42 minutes ago, Robert Bone said:

because Cakewalk does not know which port a device is plugged into, all it knows is a device is present, so if the port changes, Cakewalk doesn't know if the connecting USB port is the same or not

Again: why does this matter? All it needs to know is whether a device is present.

Two questions:

First, why can Cakewalk (presumably) only enumerate MIDI devices when you first start it while other Windows programs can do it whenever they wish?

Second, Cakewalk will keep track of which MIDI port(s) you had mapped in your project in the event that one of them becomes disconnected if you answer "no" to the remapping dialog. If you then exit the program, reconnect the device, and restart the program, and open your project, the mapping will persist and you will be able to use the device as before. Why does that process require exiting the program (I believe it has to do with the answer to the first question)?

I emboldened "Cakewalk will keep track" because you seem to be convinced that for this to be possible requires the OS to hold Cakewalk's kite string for it. What's so important about maintaining a record of USB port travels? I know that some cases plugging a USB device back into a different port than the one where it was originally recognized could mean loss of contact between the device and its driver, but there's nothing Cakewalk can do about that and I haven't had that happen since I've been on Windows 10.

I'm not a programmer, but I once held the certification of Microsoft Certified Systems Engineer, and as far as I know it works like this: I'll restrict myself to talking about USB. The user plugs a MIDI I/O device into their system, and it communicates with the OS via the device's driver. Thanks to the driver, the OS will know that it's a MIDI I/O port and it will have a "friendly" name, usually including the manufacturer and model. The OS reports this to programs that are interested in such things. 'Gotta "Whizzo MIDI In" "Whizzo MIDI Out" for whoever who grabs 'em first.' So Cakewalk comes along and claims Whizzo MIDI In and Out and then all Cakewalk needs to do is tell the OS "I have a note on 33 for Whizzo MIDI Out's Channel One" and the OS and driver take care of the rest. Do I have this right?

Cakewalk keeps track of what MIDI ports it's been talking to using friendly names in at least one way I know of, TTSSEQ.ini, probably other ways that aren't as exposed to the user. It doesn't need the OS' help with this (except of course discovering them and supplying them in the first place) because as far as I know, Cakewalk doesn't dirty its hands with talking to USB ports. It talks to MIDI ports, which have friendly names that it can keep track of in a simple plaintext file. I mean, I could sit here with a scrap of paper and keep track of the MIDI ports Cakewalk is being shown by Windows, I don't need to know about the underpinnings.

Now even if I'm completely wrong about this and there's some reason that Cakewalk must play pin the USB on the MIDI every time someone disconnects and reconnects their interface, I think it's still fine for Cakewalk to keep track of MIDI ports using friendly names. That's because the likelihood and the consequences of Cakewalk getting something mixed up after a multiple hot swap are both low. It's not of the utmost importance to be able to cover every different scenario, CbB only needs to cover the scenario of a fixed set of interfaces that a user has and is likely to disconnect and reconnect during a session, also the possible connection of a new interface, all with friendly names supplied by the OS.

Why Cakewalk should care any more than I do which specific USB port that MIDI interface is plugged into escapes me, so please tell me.

Even if it didn't work perfectly, the user would be no worse off than they are now (with needing to exit the program anyway), and how often would someone have the sort of setup required for Cakewalk to get confused? Maybe the user has two MIDI interfaces, both with the same friendly name, which is right away, a less likely scenario. So what? They see it's not working properly and switch the plugs or just restart Cakewalk like they do now.

Reality check me: are there hardware and use cases I'm not considering where it would be more likely and the consequences more dire?

@User 905133, that's interesting, I did a test and it worked pretty much like @DamianAdams says, Cakewalk maintained the mapping, but couldn't recognized the fact that the port had reappeared until it an exit/restart.

[User 905133]

8 hours ago, Starship Krupa said:

@User 905133, that's interesting, I did a test and it worked pretty much like @DamianAdams says, Cakewalk maintained the mapping, but couldn't recognized the fact that the port had reappeared until it an exit/restart.

I don't doubt that we are getting different results.  I like consistency, so I share in the frustrations. Unfortunately, there are too many variables for mere users like me to factor out the variables that make a difference. I just tested with two different projects I had. I did not reset any Cakewalk configuration files (which I did do when I was trying to get two PCI audio cards to reside in my PCI at the same time).

Not sure if this accounts for my results, but (1) I have two usb midi controllers that are always connected and always on (that is, when I boot Windows 10 Pro  and when I shut down my PC every night) and (2) presently I have an older evolution keyboard (MK-249C), a nanoKontrol, and several 2x2 midi interfaces connected.

I believe I do not have any virtual midi port software set to boot with Windows at startup.  For years I had Tobias Erichsen's rtpMIDI set to start, but IIRC I turned off the startup service for that about a month ago.

I still have ChucK software on my PC. though it doesn't run unless I specifically call it.  I haven't run it in ages, except to check my system using the chuck --probe command.  (For a stretch of time I used ChucK as an on-the-fly quick change midi I/O router.) For what its worth, here are the midi devices Windows 10 reports via ChucK's --probe command (a) when the keyboard is powered on and (b) after I turn the power switch off.

(a)      (b)  

After turning the MK_249C back on,  --probe reported the devices with the same indexes as in (a).  I know from working on ChucK scripts under XP with a parallel port MIDI interface (among other devices), booting MIDI devices after XP had started changed the indexes as compared with powering up the PC with all MIDI devices power up.

Again, not negating anyone else's experiences.  I have spelled this out on the admittedly slim chance that something here might account for why I don't have to reboot Cakewalk to get it to see my MK-249C after I switch it back on. 

 

Edited June 4, 2020 by User 905133
to fix a couple of typos

[Starship Krupa]

Dang, Use, that is quite a collection of MIDI interfaces! I'm imagining that you have some cool old hardware to plug into them. The only ones I can claim around here is that my main controller is a Kawai K1 and the other a Yamaha CS6x.

With only the information that the ChucK probe reports, I really believe that CbB can do better than it currently does.

Even in your case, I looked closely and your many E-MU interfaces each have slightly different friendly names as (I presume) reported by Windows 10. How did you do that? If you were somehow able to alter the friendly names at the OS level, it might account for why your system is different.

But as far as why you actually don't need to exit and restart to see the MK-249C, well, maybe the feature request can be that it improve from being able to do it some of the time to being able to do it all of the time, or even most of the time.

[User 905133]

8 hours ago, Starship Krupa said:

Dang, Use, that is quite a collection of MIDI interfaces! I'm imagining that you have some cool old hardware to plug into them.

Yeah--none of my parallel port MOTU midi interfaces (8 x 8s and 4 x 6s) work under Windows 10 Pro** no matter how much I try to trick them into working.  Even MOTU tech support couldn't help and I have no experience in writing device drivers (nor do I have enough of a hacker mind left to try to teach myself how).  **They do work on a bona fide XP SP3.

8 hours ago, Starship Krupa said:

Even in your case, I looked closely and your many E-MU interfaces each have slightly different friendly names as (I presume) reported by Windows 10. How did you do that? If you were somehow able to alter the friendly names at the OS level, it might account for why your system is different.

Based on my experience, having multiple devices from the same manufacturer can be problematic (e.g., triggering BSODs). So far as I can tell the E-Mu device drivers identify each of the two pairs of I/Os on a single 2 x 2.  I am not sure if its the E-Mu driver or Windows (or something else) which differentiates one 2 x 2 from others.

To try to re-stablize them one time after a Windows 10 update which I believe was responsible for some BSODs, I disconnected them, removed the drivers (including hidden instances of the drivers), reconnected them one by one, and power cycled my PC to try to ensure that Windows 10 set up them up properly in whatever tables it makes.  Unfortunately, as you can see, somehow the ports on one 2 x 2 now have the same names as a different 2 x 2.  I don't dare hook up the 4th one!!!!  ?

You raise an interesting point--by implication: if I disconnect all the 2 x 2s (i.e., just have the nanoKontrol and the MK-249C, will I then need to exit and reboot Cakewalk when I power-cycle the MK-249C (or any other usb keyboard).  I'll put that on my to-do list to test the next time I start getting a rash of BSODs and do another clean installation of the 2 x 2 drivers.

Edited June 5, 2020 by User 905133
"it" changed to "them"

[Robert Bone]

31 minutes ago, User 905133 said:

Yeah--none of my parallel port MOTU midi interfaces (8 x 8s and 4 x 6s) work under Windows 10 Pro** no matter how much I try to trick them into working.  Even MOTU tech support couldn't help and I have no experience in writing device drivers (nor do I have enough of a hacker mind left to try to teach myself how).  **They do work on a bona fide XP SP3.

Based on my experience, having multiple devices from the same manufacturer can be problematic (e.g., triggering BSODs). So far as I can tell the E-Mu device drivers identify each of the two pairs of I/Os on a single 2 x 2.  I am not sure if its the E-Mu driver or Windows (or something else) which differentiates one 2 x 2 from others.

To try to re-stablize them one time after a Windows 10 update which I believe was responsible for some BSODs, I disconnected them, removed the drivers (including hidden instances of the drivers), reconnected them one by one, and power cycled my PC to try to ensure that Windows 10 set up them up properly in whatever tables it makes.  Unfortunately, as you can see, somehow the ports on one 2 x 2 now have the same names as a different 2 x 2.  I don't dare hook up the 4th one!!!!  ?

You raise an interesting point--by implication: if I disconnect all the 2 x 2s (i.e., just have the nanoKontrol and the MK-249C, will I then need to exit and reboot Cakewalk when I power-cycle the MK-249C (or any other usb keyboard).  I'll put that on my to-do list to test the next time I start getting a rash of BSODs and do another clean installation of the 2 x 2 drivers.

I ran into the duplicate ID situation 3 years back, when I bought two identical midi controllers, and couldn't properly control the 2nd one.  Called Sweetwater and they then additionally involved the maker of the midi controllers, and none of them had ever considered that someone might try to use 2 identical controllers - turns out that that broadcast ID info the midi controllers send out, cannot be manupilated, so Sweetwater swapped out 1 of the controllers for one from a different company.

Worked out fine - AND I got an extra bag of candy out of the deal, as Sweetwater includes a little bag of candy in every box of music gear they ship.

Bob Bone

[Jim Fogle]

The original post is to suggest Cakewalk by BandLab changes how it reacts to USB connections.  I support the suggestion.

For those of you like @Robert Bone that likes to play around with programming or your computer, read on.

You may find +++ THIS +++ Tech Republic article useful for USB troubleshooting.  The article has a link to a Microsoft Windows 10 tool (USB Device Viewer) available (for free) from Microsoft.

An In use USB connection can sometimes conflict with a USB connection that is not in use, particularly if you have plugged one USB device into  multiple USB ports.  +++ HERE +++ is an article about how to identify and remove connections that are no longer in use.  This +++ article +++ includes a download link to the small utility program, Temple.