eDRUMin 1.6.1 BETA

[monospace]

This started out promising; 30 minutes of solid play with no crash (that's ~28mins more than previous builds) but it didn't last.
I'm using a couple of cheap Hosa switches for bank changes; would it make sense to unplug them to see if it makes a difference?

edrumin_crash_110221.txt.zip

(21.02 KiB) Downloaded 98 times

[Rob]

Well, we're making progress. I'm pretty sure I know what kinds of issues I'm looking for. I just need to assume that the data I receive from the device is not reliable and provide safe guards against that. I do do that already, but I'm obviously missing some. I'll spend another day on it. I'm going to feed the UI random garbage data and fix anything that comes up. That's again for the crash reports.

[Dadwrshpdrum]

Fixed a potential crash related to having a sustain / footswitch connected. Footswitches have two switches and the index of the switch is encoded in data from the device. Well, occasionally the device is saying it's switch number 255, which of course doesn't exist -> crash. I've fixed it in build 7 (no firmware update). The real source of the issue is in firmware however, so I still need to track that down and sort it out. I also fixed some macOS wierdness when plugging in and unplugging devices.

https://www.audiofront.net/eDRUMin_Cont ... .6.1.7.zip
https://www.audiofront.net/eDRUMin_Cont ... .6.1.7.zip

My Mac machine won’t run this installer. Says it can’t verify it is not malicious. First time this has happened. I’m on Catalina. Not sure if I have the latest security patch, but I suspect it is within the past few months current.

[Rob]

Changes in build 8

• Fixed a signing issue on macOS issue.
• Added dozens of safety checks incase data packets contain garbage information.
• Small tweak to the hit indicators.

I think you will need a large hammer to crash this one.

https://www.audiofront.net/eDRUMin_Cont ... .6.1.8.zip
https://www.audiofront.net/eDRUMin_Cont ... .6.1.8.zip

[hang12]

I loaded up 1.6.1 b8 from b4, and it updated the firmware to 5 from 4.
I had all sorts of extra-time GUI activity (the velocity hit dots under THRESH) happening while playing toms - that kept on appearing after I had stopped hitting the hardware - for like a second or so. Like there was a buffer still playing that hadn't quite spilled out yet.
So I went back to build 4 and all of that extra business stopped.

I haven't gone backwards in the past with builds. Does the firmware need to go backwards too?
There wasn't a '!' next to either of the eDRUMin10 devices after I loaded b4 from b8.

[Rob]

Like there was a buffer still playing that hadn't quite spilled out yet.

There is a buffer. Ya, this is a cut and paste issue. It was only reading one packet when it should have been reading all available packets. Fix coming soon. BTW, there shouldn't be any firmware updates in recent builds.

[Rob]

Changes in build 8

• Fixed a buffering issue

https://www.audiofront.net/eDRUMin_Cont ... .6.1.9.zip
https://www.audiofront.net/eDRUMin_Cont ... .6.1.9.zip

[hang12]

confirmed, build 1.6.1b9 fixed the buffering issue

Also, Auto-Select stopped jumping to eDRUM#2, as previously reported.
The two eDRUMin's are typically left powered on all the time, and had been powered up quite a while, and experienced at least one firmware update.
Last time the remedy was to (eventually, after re-booting the Mac, etc.) power cycle both eDRUMin's (the 'main' eDRUMin is plugged to the Mac mini directly, and the 'sub' eDRUMin is connected to the main), and power cycling worked this time as well.

[monospace]

Had the Control App open and active for more than three hours straight tonight — not continuously playing all of that time, but still — and no crashes. So there's that.

[Rob]

Ya, I think those crashes are finally resolved. The app should be bulletproof now. I'll give it a few more days and then I'll post this build to the downloads page.