SDRC MIDI causes crash

[pklein]

Hi, Simon. I believe I've found a bug in SDRC's MIDI interface. Windows only allows one application to listen to a Midi controller. Which means that apps need to take into account that a controller might already be used by another app, and if so, not try to grab control of it. Apparently SDRC assumes that any existing MIDI controller belongs to it. If another app already is using a Midi controller, SDRC crashes the first time I try to edit a Midi function within SDRC's MIDI window.

It happens with the app I'm trying to use. I have also confirmed the same behavior using only a simple MIDI message viewer. So the problem is not unique to my specific setup. Basically, if any other app is using the Midi controller, SDRC crashes the moment it tries to access MIDI.

What I'm trying to do is use SDRC's MIDI functions natively, but also add some discrete buttons for mode and filter width. CoyoteMIDI can do this by translating MIDI messages into keyboard key presses and mouse clicks with specific screen coordinates. The trick is to use a loop app, which takes input and simulates another MIDI controller that the next app in the chain can listen to.

Behringer CMD PL-1 --> CoyoteMIDI --> loopMIDI --> SDRC (should be reading loopMIDI's port, not the PL-1)

I have CoyoteMIDI taking input from the PL-1 and outputting to loopMIDI, which sends everything it receives out its virtual MIDI port. SDRC can see the loopMIDI port if I turn off input from the PL-1 in MIDICoyote. But then, of course, nothing gets through. If I set the PL-1 to be CoyoteMIDI's input, SDRC crashes when I try to edit a MIDI function.

This could be fixed either by checking whether "somebody else" is using a MIDI controller port, and if so, ignoring the port. Or by allowing the user to tell SDRC, "only use the ports I've checked off, and ignore the others."

Ergonomics is very important to me, as I had a carpal-tunnel type of injury some years back. So I want to have buttons and knobs and only move the mouse as little as possible. Which is why I'm putting so much effort into this.

See here for further explanation of what I'm trying to accomplish:
https://coyotemidi.com/docs/using-coyot ... back-midi/

Screen clips attached. I also saved an SDRC error report, but it's too big to attach here. If you want that, let me know hos to send that to you.

--Peter

[pklein]

The errorlog.xml is attached to this message.

[jdow]

For grins and giggles visit "https://www.midiox.com". See if midi-ox or mdi-yoke will do your task for you.
{^_^}

[pklein]

Thanks. I actually had MIDI-Ox already. I fooled with it and MIDI-Yoke a bit. I got the same result. I don’t think the problem is the intermediate software. It seems that when SDRC sees a MIDI controller, it says “you’re mine.” And if something else is already using that controller, they get into a fight that nobody wins. It would be nice if there was a workaround. But, bottom line, anything that causes SDRC to crash is not a good thing. Most software that deals with MIDI will tell you if you try to access a midi device that’s already in use, and will refuse to use it.

[jdow]

The idea is to have a tool that opens the controller and echos its output to several MIDI ports it creates. So SDRC would connect to one such port. Your other program would connect to another. SDRC would never touch the controller itself, only the echo.

A little waste of time later, if I get this right CoyoteMIDI connects to a pair of MIDI Ports and translates the MIDI signals on one to the other. LoopMIDI presents a pair of MIDI ports sending input from one to the other.

(Grumble, CoyoteMIDI should connect to one MIDI port and create its own MIDI port within the OS. But, I bet 11 makes that just about impossible. It's hard in 10 and has to be setup ahead of time. Whatever, Microsoft's MIDI is gawdawful to work with. Evil Grin, and I discovered that a MIDI tool COULD prevent many older versions of NT from booting. I never tried 10 for that bug. I just worked around it. My tools translated MIDI to PLCs and the like.)

Close SDRC for starters. Load CoyoteMIDI. (I suspect LoopMIDI is always present once setup.) Connect CoyoteMIDI to Behringer's port. Connect CoyoteMIDI to LoopMIDI's input port. THEN start SDRC and connect to LoopMIDI's output port. Does that work? Does SDRC see LoopMIDI once the rest of it is all hooked up?

{^_^} Joanne (Knows the original MIDI inventors. Been fiddling with it myself since NT4 on Windows. Wants to commit unspeakable harm on the person who ported Microsoft's MIDI into NT so sloppily.)

[Max]

Ergonomics is very important to me, as I had a carpal-tunnel type of injury some years back. So I want to have buttons and knobs and only move the mouse as little as possible. Which is why I'm putting so much effort into this.

Peter, I too had quite severe carpal tunnel symptoms after working for many years as an editor for the UK national broadcaster. This actually came up after only a relatively few years of moving over to computer-based editing systems after decades tape-based technology (which did not involve computer mouse use at all).

I know everyone is different but I (and several of my similarly affected colleagues) managed to totally eradicate our issues by moving over to pen and tablet instead of mouse, and from that day, getting on for 30 years ago, I have never used a mouse at all for daily use, including for all my ham radio software, and including (of course) SDRC. Ditto audio and video editing software that I still use today.

I would urge you to try and move away from mouse use and try pen and tablet. It does take a little while to get used to, maybe 2-3 weeks, and you need to persevere with it, but now it's second nature to me and using a mouse feels very tedious "clunky" now. I only use it when I absolutely have to, like initial installtion of Windows, or hardware BIOS issues. Of course with a pen there is no "scrubbing" repeatedly across a mouse mat to get across several monitors. Literally just point and click (or right click with button on side of pen). Totally effortless and, most important of all for RSI style injuries, no differential use of the two forefingers and also extremely important, the wrist is no bent backwards as it is with mouse use, hence no repetitive tendon movement through the carpal tunnel which causes all the issues with a mouse.

So regarding SDRC, I use pen and tablet to point to what I need on the waterfall display and on-screen buttons. Quite a lot of folk seem to still be unaware that frequency tuning can be accomplished (with the pointer hovering over the waterfall/spectrum) by use of the keyboard cursor keys left/right (single steps) and up/down (step x10) and after quickly getting to location with a pen point and click on the waterfall I then do all of my "in-band" tuning using the cursor keys only. If you set the mode step sizes carefully it works perfectly, small for CW (say 10Hz) and you can nearly always get away with 100Hz or 250Hz steps for SSB as 99% of ops use round increments of exactly 500Hz these days except maybe on contest weekends.

Just also to say the pen/tablet is not expensive. I use a variety of Wacom devices and most recently the Wacom One (A5) tablet which can be had right now on Amazon UK for an astonishing £20. USA $40.

https://www.amazon.co.uk/dp/B07N525974

If you tried it and made sure not to give up too quickly I don't think you (or anyone with carpal tunnel symptoms) would ever want to go back to a mouse. Anyway, there to take or leave as you wish.

Max

[pklein]

Thanks, Joanne and Max. Joanne, you jogged my brain into finding a workaround. The trick was to start CoyoteMidi and uncheck the box that made the PL-1 controller the input device. Then I started SDRC, and went to the MIDI options. I clicked "Erase all," and then edited one of the MIDI functions. Now I could get into the edit screen without SDRC crashing, and choose what controller to use. I chose the loopMIDI output. When I cancelled out of this edit, SDRC still remembered loopMIDI output as the last "controller" used, and apparently no longer tried to access the PL-1. Now I could check the box in CoyoteMidi to enable the PL-1 as its input device. From then on, I could get into the Midi function editor and map the PL-1 buttons to my desired functions.

I still think that SDRC should handle a Midi port conflict more gracefully, rather than crashing. Just say, "I'm sorry, Dave. I'm afraid I can't do that." Port in use.

That's the good news. The bad news is that all this turned out not to be useful for SDRC. I wanted to map buttons on the PL-1 to my favorite modes and filter widths. But that won't work, because the position of the onscreen buttons change depending on what mode is selected. So even if I always run full-screen and never change which functions are or aren't hidden in the left-hand column, it's still a moving target. So the mouse click coordinates that work for one situation won't work for another.

Which is why it would be very nice to have MIDI functions for modes and filter widths. Or keyboard shortcuts. Or both.

Further good news, though: I successfully used CoyoteMidi to create a nice set of PL-1 mappings for SDR#. So now, if I use "Sharp," I've got a PL-1 user interface similar to my SDRC setup.

[jdow]

I'm glad my blathering helped prod you to a useful direction. I've pointed Simon at this thread to deal with the crash and perhaps your other issue.
{^_^}

[Simon G4ELI]

Hi, Simon. I believe I've found a bug in SDRC's MIDI interface. Windows only allows one application to listen to a Midi controller. Which means that apps need to take into account that a controller might already be used by another app, and if so, not try to grab control of it. Apparently SDRC assumes that any existing MIDI controller belongs to it. If another app already is using a Midi controller, SDRC crashes the first time I try to edit a Midi function within SDRC's MIDI window.

It happens with the app I'm trying to use. I have also confirmed the same behavior using only a simple MIDI message viewer. So the problem is not unique to my specific setup. Basically, if any other app is using the Midi controller, SDRC crashes the moment it tries to access MIDI.

What I'm trying to do is use SDRC's MIDI functions natively, but also add some discrete buttons for mode and filter width. CoyoteMIDI can do this by translating MIDI messages into keyboard key presses and mouse clicks with specific screen coordinates. The trick is to use a loop app, which takes input and simulates another MIDI controller that the next app in the chain can listen to.

Behringer CMD PL-1 --> CoyoteMIDI --> loopMIDI --> SDRC (should be reading loopMIDI's port, not the PL-1)

I have CoyoteMIDI taking input from the PL-1 and outputting to loopMIDI, which sends everything it receives out its virtual MIDI port. SDRC can see the loopMIDI port if I turn off input from the PL-1 in MIDICoyote. But then, of course, nothing gets through. If I set the PL-1 to be CoyoteMIDI's input, SDRC crashes when I try to edit a MIDI function.

This could be fixed either by checking whether "somebody else" is using a MIDI controller port, and if so, ignoring the port. Or by allowing the user to tell SDRC, "only use the ports I've checked off, and ignore the others."

Ergonomics is very important to me, as I had a carpal-tunnel type of injury some years back. So I want to have buttons and knobs and only move the mouse as little as possible. Which is why I'm putting so much effort into this.

See here for further explanation of what I'm trying to accomplish:
https://coyotemidi.com/docs/using-coyot ... back-midi/

Screen clips attached. I also saved an SDRC error report, but it's too big to attach here. If you want that, let me know hos to send that to you.

--Peter

Thanks, noted and added to my list.

[G0OFE]

I meant to post about this.

Seems trying to edit any Midi setting within Console, when Console is not connected to the controller will cause an immediate crash. Just needs a sanity check to make sure it's connected, I think.

AS for mode and bandwidth changes, I made some suggestions n the Requests area. The beauty of MIDI is that things can be done from the controller, without having to give the appropriate window focus.