hairless-midiserial
hairless-midiserial copied to clipboard
projectgus
[macOS] No 64-bit target
In order to allow hairless to be more future ready, it should be recompiled to target x64 architecture. Currently it is PowerPC and Intel x86 (32-bit). Apple suppose to remove 32-bit frameworks and mentions 10.14 as last version with 32-bit support.
TODO:
- Make sure target can be compiled under Mac based QT with 64-bit support. (seems updating to QT5 should be merged - https://github.com/projectgus/hairless-midiserial/pull/31)
- Re-compile it with 64-bit architecture.
- Update the github.io website with newer binary release.
Seems like a reasonable TODO list. Please let me know how you get on with this. Please remember that an updated Hairless will need testing on the other supported platforms as well.
I don't mind getting this / implementing.
Hope it didn't read to harsh as this was written in friendly collaborative manner.
Only considerations / questions -
- Should I fork and pull request?
- What's the status of the QT5 pull-request, will it be applied? Or should I base on it? Maybe separate the baud feature from QT switch.
I can easily test on macOS and Windows 10 (32bit / 64bit). For Linux, which flavor? Is Ubuntu 64 bit VM enough or a vanilla Raspbian?
Thanks.
Hi, I didn't want to fork project just for that.
- I've used the QT5 pull-request and only made minor changes to use macOS SDK 10.13 (so it won't complain on newer 10.14 SDK).
I works as expected. only thing I'm trying to figure out is why QSettings is in compatible. They both write plist with minor differences so each one does not read the other ones.
I might just get QT 4.x and try to compile it as universal binary without really touching the code. (another sad thing is QT 5.10 drops 32-bit support for macOS).
Here is a 64-bit build if this won't make it anywhere. hairless-midiserial.zip
(I'll update if I have news, though if anyone got some tidbits on why/what got wrong on the preferences it'll be helpful). here are the default settings of original binary downloaded (0.4) vs the compiled one (using pull request but removing the MIDI baud support, #31 ).
(I've tried to do things with, QSettings::setDefaultFormat() & QSettings::setIniCodec() but it didn't help).
@talaviram are the code changes you made available anywhere?
I works as expected. only thing I'm trying to figure out is why QSettings is in compatible. They both write plist with minor differences so each one does not read the other ones.
Do you get errors when the build compiled with QT5 tries to open settings saved from QT4?
are the code changes you made available anywhere?
Only code changes I've made is:
- applied #31 pull request (Merge branch 'master' of https://github.com/dholth/hairless-midiserial)
- patched to remove MIDI baudrate. - 0001-Removed-31250-aka-MIDI-baud.-Requires-serial-library.txt
- changed build props:
macx {
- CONFIG += ppc x86
+ CONFIG += i386 x86_64
+ # squash 10.14 warning on latest QT
+ QMAKE_MAC_SDK = macosx10.13
}
(not commited as I'm still trying to figure out).
Do you get errors when the build compiled with QT5 tries to open settings saved from QT4? No errors.
As I've attached above, the actual plist generated by QSettings is different. The 32-bit old plist is also detected with wrong values when opened under Xcode with plist viewer...
It might be related to this? https://github.com/qt/qtbase/commit/764f5bf48cc87f4c72550b853ab93b815454cd48
but I'm still trying to figure out what has changed.
@projectgus - Ok, I think I've found the reason for preferences "broken". IIUC you compiled the Mac build as cross-compilation? The values "broken" are just enums set to their linear value instead of their explicit one) Eg:
enum Values { TWO = 2, THREE = 3 }
was eventually compiled under the 32-bit macOS as - TWO (resulted 0), THREE (resulted 1).
Should I keep it like that for compatibility and pull-request? Thanks!
Compilation was native, I never got cross-compiling for macOS to work correctly.
This is possibly a bug in the version of Qt that the last build was linked with. Which preferences are behaving like this?
You can compare for youself... I've already provided 2 files I've used for diffing. https://github.com/projectgus/hairless-midiserial/issues/51#issuecomment-429227186
Anything with enum from qextserialport.h (BaudRateType, etc...) will produce it's enum location.
I also notice that the calls aren't explicit, eg:
result.BaudRate = (BaudRateType) settings.value("baudRate", (int)BAUD115200).toInt();
(no BaudRateType::baudRate, but I'm not a cpp expert ;) )
So it might be difference from llvm / gcc and/or flags (I guess when you've compiled it was when Apple used gcc)
As you're the ~~maintainer~~ developer/creator the question is what you find as the desired behavior:
- avoid settings break at all cause.
- upward fix (I guess we can detect those since you don't expect a baudRate of 19 for example...), so we can assume low numbers are enum linear position. (this will be applied only for mac build).
- just keep it that way, minimal code changes.
It looks like qextserialport changed the integer value of these enums in https://github.com/qextserialport/qextserialport/commit/2cadf8cece00af6a625400c69498c564f8472035#diff-a4a619676ba7e97cc59e03ec3e8be26dL74
The version of qextserialport in the v0.4 build likely predates this change.
I don't mind if hairless-midiserial loses the old baud rate value, provided it doesn't crash. What does it do right now if the value is invalid?
It keeps the invalid value so 115200 is set to 19. It won't crash, hairless just won't work until you restore defaults or set proper values.
Now with macOS Catalina 10.15 dropping 32bit support, having 64-bit target is a must-have.
The build above works.
I didn't do much. But if I remember I've used QT5 which requires some changes included here: https://github.com/projectgus/hairless-midiserial/pull/31
Sadly I wasn't able to find time and build a universal binary (that got dropped in QT at some point of QT4). Also I don't know the exact commit of the release binaries (so the qextserialport differ making preferences differ).
Hi, unfortunately I was not able to install your hairless 64bit "hairless-midiserial.zip", is there a new version coming, soon, or any suggestions how I could manage to install it? I just got a message something like "contact developer for 64 bit compatible version"... would be great if I could install it, regards, Tobias
unfortunately I was not able to install your hairless 64bit
Sadly I've never checked it on other machines. it turns out QT builds are not static. I've been wasting a few hours now on trying and compile static build. First I thought of trying to compile the master with QT 4.8.2 (or latest QT4) but discovered it's nearly impossible on 'modern' (10.13!) macOS. Also QT5 isn't that friendly on that manner. Once I'll have a build I'll post it here.
Here is a static hairless. I've verified with otool and tested it on my Mojave machine with no Qt installed. Keep in-mind that it WILL warn you this isn't signed with Apple pushing into notarizing Apps. I've yet to need a paid Apple Developer ID so if I'll have one I'll try to hardened it and notarize. It's targeted to 10.7 but the static Qt is targeted to 10.12.
It works the same but since:
It looks like qextserialport changed the integer value of these enums in https://github.com/projectgus/hairless-midiserial/issues/51#issuecomment-444827803
Keep in mind the port settings are incompatible. It won't crash with older settings just won't work until you re-save the settings.
hairless-midiserial-macos_x64.zip
I tried your download, but in debug mode it just says Serial In: System Message #14
instead of:
Serial In: Ch 1: Note 65 on velocity 127
I'm building a midi scanner for an old pipe organ console and need to debug my hardware.
yeah, the mac osx catalina 64bit version is working for many users now.
WHY?????
On Mon, 16 Mar 2020 at 10:30, t0maszduda [email protected] wrote:
Hi has someone checked this version?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/projectgus/hairless-midiserial/issues/51#issuecomment-599459462, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDPOJNRPOR6LWQTYGQTZBLRHX5UVANCNFSM4FZOVPNQ .
I built a 64bit signed/notarized version of the app for a friend who uses it to teach a class at community college. It appears to work for her students running Catalina. YMMV.
hairless-midiserial.app.64bit.zip
@darrengit On Big Sur starts, icon bounces but then when you right-click it says the app is not responding.
@iolmao Oh bummer... it's happening to me too. Maybe I can find time to fix it during the winter holiday.
I also upgraded to big sur without even considering the possible compatibility issues and now I can not use the program, unfortunately. I am waiting for someone to solve this problem since I have no idea about what to do. If you guys have any possible suggestions, I could certainly try.
Hey guys, i have also the problem with big sure. As wizardofozk if someone (maybe @darrengit in winter holiday :D ) is able to fix the problem ore if anybody can tell my what to do please let me know
I spent a chunk of time this morning trying to fix this with no success. I'm able to build the app on BigSur, but the freezing problem persists... it's related to CoreMIDI and I wasn't able to find a quick solution.
I don't use hairless those days or looked into the code at all.
But I do know Apple changed midi API and broke older API... At least on iOS but it might be related?
https://forum.juce.com/t/ios-14-2-midi-connections-broken/42440/3
That's huge commit but https://github.com/juce-framework/JUCE/commit/9032f589ebdc5f6fff00216b567175a39547c782#diff-97ed8896d9ac559fbe80f36815bcc4a4a409af3288a9107daf21367fdd80f72b