Are there plans to also release native arm binaries for Logic 2?
For Apple M1 there is Rosetta - but that’s not really a long term strategy.
At least for me it would be a deal breaker if there isn’t anything on the roadmap.
So - what’s the plan?
2 Likes
Unfortunately, we don’t have any official plans to announce for this yet. I added a comment/vote for you in the idea post below. Thanks for letting us know your need for this, and we agree… emulation isn’t great long term.
We initially had some stability issues with running the app on Rosetta. However, since releasing 2.3.38 almost a year ago, we implemented updates to the app to significantly improve performance on Rosetta, and we’ve been quite pleased with it so far.
Doing it this way for now has allowed us to work on other priority items in the pipeline. Rebuilding the app for ARM, although great long term, would halt our development efforts for a good amount of time short term (which we unfortunately can’t afford), especially given that our software team is only comprised of 3 members at the moment.
Are you a current user of our logic analyzers, or are you planning on purchasing one? If the former, I’m curious to know if you’re running into any specific issues on M1 right now that we could attempt to solve.
1 Like
Thanks for the detailed reply.
Publishing a build for ARM shouldn’t really mean “rebuilding for ARM”. Unless you have some optimisations written in assembler it should not take up that much time.
IIRC it was Logic 1 that I used before. I am now thinking of getting myself an analyzer.
I didn’t try Logic 2 yet - so I cannot speak to problems to solve. It’s more thinking of longevity. If there is no plan for supporting ARM - it becomes a statement. Or a risk. Whatever you want to call it.
If I buy standalone hardware it will just keep working. But I’ve had my share of hardware where outdated software compatibility rendered it useless. Hence my hesitance to invest if there is no commitment on your side.
No judgement - just stating my thoughts as a consumer.
1 Like
I completely understand.
Internally, this is something we’ve been looking into, but we’re not ready to make a public commitment yet.
In case anyone is curious what’s holding this up, we think we have a handle on most of the technical issues, but there is some non-trivial work that needs to be done.
- Our app’s front-end (an electron, JavaScript application) isn’t setup to do a cross build, as some native components that are redistributed are also used during the build process. The easiest solution for us would be to build releases of the application for M1 on M1 hardware. Unfortunately, M1-based cloud build solutions aren’t available through our current providers yet, so we’ll likely use M1 hardware at our office for builds.
- The back-end of our application does have some x86 SIMD accelerated code. We could likely start with a non-optimized version of this for M1 users, however it would be best if we could either add an equivalent implementation (NEON) or try out one of these other migration paths we’ve looked into.
- Our application also ships with a standalone copy of python, so that we’re able to run python extensions in a consistent environment across all machines. Exactly how this gets deployed, along with how it integrates with our C++ code, will need a pretty comprehensive upgrade in order to target M1.
- There are a handful of other sticking points that will need to be worked out too.
The biggest piece of this however is really the extensive testing, and commitment to supporting a new architecture. This is something we’ll likely release as a private beta first, and get some feedback on it, before we consider official support.
This is really only an issue due to the complex nature of our software stack, and our very small team. (We’re 3 software engineers, including myself.) I do look forward to getting this out the door eventually though.
- Mark
5 Likes
- Our app’s front-end (an electron, JavaScript application) isn’t setup to do a cross build, as some native components that are redistributed are also used during the build process. The easiest solution for us would be to build releases of the application for M1 on M1 hardware. Unfortunately, M1-based cloud build solutions aren’t available through our current providers yet, so we’ll likely use M1 hardware at our office for builds.
Not sure what providers you are using - but I do know that some people work around this through QEMU - not sure this works for you. Just stating some people can make it work. Not sure about Electron. That said - I am sure there should have been plenty of people making it work. I would look at them for guidance.
That said - from testing perspective a native ARM worker might be indeed a good choice.
- The back-end of our application does have some x86 SIMD accelerated code. We could likely start with a non-optimized version of this for M1 users, however it would be best if we could either add an equivalent implementation (NEON) or try out one of these other migration paths we’ve looked into.
OK - that’s indeed a tricky one.
- Our application also ships with a standalone copy of python, so that we’re able to run python extensions in a consistent environment across all machines. Exactly how this gets deployed, along with how it integrates with our C++ code, will need a pretty comprehensive upgrade in order to target M1.
I personally would just start getting a build working on an ARM and worry about things like fat binaries later. I am not sure it really is that hard as it sounds.
Anyway - much appreciate the openness about this.
cheers,
Torsten
1 Like
Thanks for your openness about the technical challenges. I am sure you can manage them.
We would be happy to participate in a private beta and give extensive feedback for using Saleae on Linux/ARM64.
1 Like
I’m interested in ARM Linux.
I would like to take a RaspberryPi 4, 3D print an enclosure, and make a dedicated, standalone oscilloscope.
I love the form factor you’ve created, it’s great for travelling. However, when I’m working on my bench, then it’s much nicer to have a scope ready to go without needing my USB ports or colliding with my debugger.
1 Like
I get it that this is an old topic… But being a long time Mac user and having seen this movie before (68k, PPC) Rosetta support will disappear, and sooner than we think. Then, my $1000 logic 16 becomes a door stop or I set up a Linux box (I will not use Windows). One of the reasons I supported this product through two purchases was precisely because of Mac support. It would be sad to lose that.
@ehklei19 We hear you! Quite a few users have shared the same sentiment, and I’ve added a comment for you below to take note of your reasoning for needing this.
MacOS is one of our three officially supported operating systems (Win10 and Ubuntu being the other two), and several of us here at the company run MacOS as our primary OS.
We made some progress last year on this last year, however, we had to put the project on pause due to other priorities on our plate. Mark, our CTO, highlights some details about our progress and next steps below.
I fully empathize with your staffing situation. Your products are probably so good because you run a lean operation. My post was an attempt to point out that Apple could put down Rosetta sooner than you might think and with less warning than you might like. They have been known to do things like this before. Since Intel is now totally and completely dead to them look to see how quickly the x86 macs age-out now. My 2016 MBP has been vintage since Ventura released. More will go with the upcoming Sonoma. It’s a “don’t get caught out with your knickers down” situation, as far as I can tell.
1 Like
@ehklei19 The point you brought up below seems to be our biggest risk.
We certainly don’t want to get into a situation where a large part of our user base ends up not being able to use their Logic device. I’ll make sure to get this risk evaluated and discussed with everyone here.
Awesome! Great work.