Current state of DMX support on Apple Silicon Macs? #mac-m1 #powerline
|
Greetings All,
?
After an extended late-night dive into the group archive, I can't seem to find a final word on whether the JMRI DMX-via-USB support (whether Anyma or Powerline) works when using Java for ARM on Apple Silicon Macs (M1-M4 processors). There are a couple of 2022 threads that mention that it was broken, but the only possible response I found in the code was a commit for release 5.3.3 that appeared to be a minor change for some component of DMX support. It didn't look like a smoking gun, but looks can be deceiving.
?
I'm asking because my 2020 Intel iMac will likely need to get replaced with a M4 (or later) unit sometime between now and when my layout is getting built. I can certainly buy a USB-to-DMX dongle, a decoder, some lights, and play around with it, but that won't be a true acid test since I'm still back in Intel land.
?
The ultimate goal is to have the layout lighting run in two modes:
My assumption (at the moment) is that this functionality would likely require either a LogixNG or Python/Jython script that listens to the "maintenance mode" memory value and the fast clock value.
?
Thanks in advance.
?
Paul
? |
开云体育The issue I had found with DMX was that not all DMX dongles are equal. But worse, I was working from Windows systems. Due to lower level libraries the only way I could get it working was:
? If the other method had worked, and I think it would from Mac or Linux, would be just sending that buffer once every time something changed. The device would then have been repeating it to the DMX devices. ? Net result is I have no idea if it works or not on Mac or Linux. Granted right now I’m tired and might be able to think of more things tomorrow. ? -Ken Cameron, Member JMRI Dev Team
? ? |
|
On Sat, Mar 15, 2025 at 05:39 PM, danielb987 wrote:
Thank you, Daniel. I had yet to find the documentation for lighting controls from LogixNG, and the cited example of triggering light objects based on the fast clock was?very helpful.
?
I hadn't noticed that the standard light controllers that you can associate with lights also include a mode. For the lights that simply turn on/off at a given intensity and at a given fast clock time, this should work quite nicely with no scripting necessary. Very cool.
?
For variable intensity lights that need to brighten or dim over time, the could be finicky to adjust, especially for the RGBWW strip lights where each color component is a separate light to control. I'll have to experiment with it.
?
?I think my strategy will be to use the available light controllers for simply light control and a LogixNG script for the lighting transitions that demand more flexibility than the light configuration and available controllers provide. |
|
I’ve done some experimenting with this on an M1 Mac. Note that I don’t have a DMX512 box or anything like that, so I’m just testing whether a connection will _try_ to open.
1) When running an Intel Java install via Rosetta-2, both the Powerline DMX512 and Anyma DMX512 connection types seem to start up fine. 2) When running an Apple Silicon Java install natively, the Powerline DMX512 connection type seems to start up fine. 3) When running an Apple Silicon Java install natively, the Anyma DMX512 connection type fails to start because the LibUsb included with JMRI for Apple Silicon is not loading properly. So that’s good news / bad news / meh news a) The good news is that you can use an Apple Silicon Mac with Rosetta 2 and (probably) have a working native connection b) More good news is that can (probably) use an Apple Silicon Mac natively with a Powerline connection, though I don’t know what the difference between those two connection types is. c) The bad news is that Rosetta 2 won’t be supported by Apple forever. Some future OS upgrade will remove it, at which point you won’t be able to use a native Anyma connection if you upgrade to that OS version. d) The meh news is that we might eventually be able to fix this. We are distributing a .jar file that _should_ contain the necessary code, but for some reason it’s not working. That libusb4java file is maintained by a different software project and they might eventually provide a version that works on Apple Silicon. Or somebody might take that open-source () and create one themselves. I can look into that some, but I don’t have DMX512 hardware or type-specific knowledge so I’m in no position to really test anything, Sorry there doesn’t seem to be a more explicit answer. Bob — Bob Jacobsen rgj1927@... |
|
On Sun, Mar 16, 2025 at 12:02 PM, Bob Jacobsen wrote:
c) The bad news is that Rosetta 2 won’t be supported by Apple forever. Some future OS upgrade will remove it, at which point you won’t be able to use a native Anyma connection if you upgrade to that OS version. Deprecation of Rosetta 2 is a complicated issue. The previous PowerPC-to-Intel incarnation of Rosetta was limited to about five years, so it's natural to assume that Apple will kill it with this fall's (2025) MacOS upgrade (or perhaps next year's). There are, however, two reasons that Rosetta 2 may hang around longer:
Like you, I'm inclined to assume that it's going to go away, so I don't want to rely on it either.
d) The meh news is that we might eventually be able to fix this. We are distributing a .jar file that _should_ contain the necessary code, but for some reason it’s not working. That libusb4java file is maintained by a different software project and they might eventually provide a version that works on Apple Silicon. The problem of the missing darwin-aarch64 code in the libusb4java project is pretty simple. While the script builds both darwin-x86-64 and darwin-aarch64, the script omits the darwin-aarch64 platform, so it's not in the jar file.?
Or somebody might take that open-source () and create one themselves.? I don't love the idea from a maintainability standpoint, but forking our own libusb4java project could resolve this.
Sorry there doesn’t seem to be a more explicit answer. Sometimes, that's the norm for distributed software development. I get it. We just have to rattle the necessary cages or roll our own until these dependent projects get some love.?
?
Best regards,
?
Paul
?
? |
开云体育If we did do our own libusb4java, it might cure an issue in how Windows can do a better job of using the DMX interfaces. One of the preferred methods can’t be used from Windows due to a buffer size issue somewhere inside that code. ? -Ken Cameron, Member JMRI Dev Team
? ? |
|
TLDR: I’ve done a little more work on why JMRI’s USB HDI support, used by e.g. the Anyma DMX support, doesn’t work in native mode on Apple Silicon. We _do_ have a version of that code that should work natively, but it’s not working on my M1 Mac. Is this due to an improper setup on my part, or something broken in the .jar JMRI uses? I could use some help sorting that out from somebody who understands dynamic linking on the Mac in Java. Please contact me off list if you can help. Thanks!
Longer: When the Apple Silicon version used by JMRI fails to load, we get this: [java] 16:19:03,132 mri.jmrix.AbstractUsbConnectionConfig ERROR - UnsatisfiedLinkError - the serial library has not been installed properly [AWT-EventQueue-0] [java] 16:19:03,132 mri.jmrix.AbstractUsbConnectionConfig ERROR - java.library.path=/Users/jake/Documents/Trains/JMRI/projects/JMRI:/Users/jake/Documents/Trains/JMRI/projects/JMRI/lib/macosx/aarch64:/Users/jake/Documents/Trains/JMRI/projects/JMRI/lib/macosx:/Users/jake/Documents/Trains/JMRI/projects/JMRI/lib [AWT-EventQueue-0] [java] 16:19:03,132 mri.jmrix.AbstractUsbConnectionConfig ERROR - Exception is {} [AWT-EventQueue-0] [java] java.lang.UnsatisfiedLinkError: /private/var/folders/b5/7f3mtqj55fd7pxzhnckz68nh0000gn/T/usb4java12025525072169804161.tmp/libusb4java.dylib: dlopen(/private/var/folders/b5/7f3mtqj55fd7pxzhnckz68nh0000gn/T/usb4java12025525072169804161.tmp/libusb4java.dylib, 0x0001): Library not loaded: /opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib [java] Referenced from: <D242CF53-6770-32AD-BCF1-717B7A28DDA7> /private/var/folders/b5/7f3mtqj55fd7pxzhnckz68nh0000gn/T/usb4java12025525072169804161.tmp/libusb4java.dylib [java] Reason: tried: '/opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib' (no such file), '/opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib' (no such file), '/usr/lib/libusb-1.0.0.dylib' (no such file, not in dyld cache) [java] at jdk.internal.loader.NativeLibraries.load(Native Method) ~[?:?] [java] at jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388) ~[?:?] [java] at jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232) ~[?:?] [java] at jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174) ~[?:?] [java] at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2394) ~[?:?] [java] at java.lang.Runtime.load0(Runtime.java:755) ~[?:?] [java] at java.lang.System.load(System.java:1953) ~[?:?] [java] at org.usb4java.Loader.load(Loader.java:323) ~[usb4java-1.3.0.jar:?] The line about "the serial library has not been installed properly” is from a JMRI error handler, so I don’t think that really means much. These lines seem to be the core of the problem: [java] 16:19:03,132 mri.jmrix.AbstractUsbConnectionConfig ERROR - Exception is {} [AWT-EventQueue-0] [java] java.lang.UnsatisfiedLinkError: /private/var/folders/b5/7f3mtqj55fd7pxzhnckz68nh0000gn/T/usb4java12025525072169804161.tmp/libusb4java.dylib: dlopen(/private/var/folders/b5/7f3mtqj55fd7pxzhnckz68nh0000gn/T/usb4java12025525072169804161.tmp/libusb4java.dylib, 0x0001): Library not loaded: /opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib [java] Referenced from: <D242CF53-6770-32AD-BCF1-717B7A28DDA7> /private/var/folders/b5/7f3mtqj55fd7pxzhnckz68nh0000gn/T/usb4java12025525072169804161.tmp/libusb4java.dylib [java] Reason: tried: '/opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib' (no such file), '/opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib' (no such file), '/usr/lib/libusb-1.0.0.dylib' (no such file, not in dyld cache) I _think_ those mean that the jar-contained org/usb4java/darwin-aarch64/libusb4java.dylib library was found and loading started, but then the process failed when that in turn tried to access /opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib But I don’t have a /opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib file, or anything close to that. There’s not even a /opt/homebrew/opt, let alone the rest of the path. It seems that the org/usb4java/darwin-aarch64/libusb4java.dylib in the .jar file has that string baked in. I do have a file by that name at a different path. Homebrew decided to install it at /usr/local/Cellar/libusb/1.0.27/lib/libusb-1.0.0.dylib If I make a symbolic link from /opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib to the file I have, then the file gets found (yeah!), but we get a new error because that file has x86_64 architecture (??) % file /opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib /opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib: Mach-O 64-bit dynamically linked shared library x86_64 I _think_ when I copied my system from my previous Intel machine, all the Intel-format libraries were copied over and are still here. But I don’t know what to do about this. Anybody have any ideas? If so, perhaps contact me off list. This is getting quite technical. Thanks in advance! Bob On Mar 16, 2025, at 5:19?PM, Paul Anderson via groups.io <paul@...> wrote:— Bob Jacobsen rgj1927@... |
|
Returning to the original question in this thread: Would an Apple Silicon Mac, e.g. an M4, be able to run a DMX512 connection natively?
I’ve made some more progress on this: I have been able to set up a M1 Mac with the right native libraries (as opposed to x86_64 Intel libraries) and JMRI is able to make a HID connection to another device in the same way an Anyma connection would be made. So that works. I think the answer is “Yes, if the Mac is set up with native libraries”. I don’t have an actual Anyma DMX512 system to check with, so I can’t be 100% sure. Bob — Bob Jacobsen rgj1927@... |
Paul Anderson
Ken Cameron
Bob Jacobsen