June 24 2026 APP 2.0.0-beta46 has been released !
Improved internal memory configuration (lower ! memory usage), fixed beta45 startup issue, fixed Set Save Directory & 2-panel mosaics.
May 27 2026 APP 2.0.0-beta45 has been released !
Fully Multi-Threaded LNC, many improvements for the registration engine, platform upgrade, and further tuning of internal memory consumption and memory release back to OS.
Apr 14 2026: Google Pay, Apple Pay & WeChat Pay added as payment options
Update on the 2.0.0 release & the full manual
We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.
Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.
I have been running into major integration speed issues when using APP on macOS Big Sur (11.1). I am on a fairly powerful computer (MacPro 2019, 12 cores@3.3 Ghz, 23 threads and 16 GiB of RAM dedicated to APP) and performance is good, ~5 to 10 seconds to integrate a frame. However, if I don't actively use the computer during integration, each frame takes several minutes to integrate (~4 to 10 minutes).
Here is an excerpt of today's logs, while I am away from the computer:
10:39:00 - 6) INTEGRATE: integrate light frames: wrote frame: 320 to file mapper
10:39:00 - 6) INTEGRATE: integrate light frames: wrote weights of frame: 320 to file mapper
10:46:04 - 6) INTEGRATE: integrate light frames: loaded frame 321 of 749 frames
10:46:04 - 6) INTEGRATE: integrate light frames: wrote frame: 321 to file mapper
10:46:04 - 6) INTEGRATE: integrate light frames: wrote weights of frame: 321 to file mapper
10:54:24 - 6) INTEGRATE: integrate light frames: loaded frame 322 of 749 frames
10:54:24 - 6) INTEGRATE: integrate light frames: wrote frame: 322 to file mapper
10:54:24 - 6) INTEGRATE: integrate light frames: wrote weights of frame: 322 to file mapper
And while I'm using the computer:
11:42:59 - 6) INTEGRATE: integrate light frames: loaded frame 404 of 749 frames
11:43:05 - 6) INTEGRATE: integrate light frames: wrote frame: 404 to file mapper
11:43:07 - 6) INTEGRATE: integrate light frames: wrote weights of frame: 404 to file mapper
11:43:07 - 6) INTEGRATE: integrate light frames: loaded frame 405 of 749 frames
11:43:12 - 6) INTEGRATE: integrate light frames: wrote frame: 405 to file mapper
11:43:15 - 6) INTEGRATE: integrate light frames: wrote weights of frame: 405 to file mapper
11:43:15 - 6) INTEGRATE: integrate light frames: loaded frame 406 of 749 frames
11:43:20 - 6) INTEGRATE: integrate light frames: wrote frame: 406 to file mapper
11:43:22 - 6) INTEGRATE: integrate light frames: wrote weights of frame: 406 to file mapper
11:43:22 - 6) INTEGRATE: integrate light frames: loaded frame 407 of 749 frames
11:43:28 - 6) INTEGRATE: integrate light frames: wrote frame: 407 to file mapper
11:43:30 - 6) INTEGRATE: integrate light frames: wrote weights of frame: 407 to file mapper
I have already verified the energy saver settings of my system:
- "Prevent computer from sleeping automatically when the display is off" is enabled
- "Put hard disks to sleep when possible" is disabled
I have also tried to use the built-in system tool called "caffeinate" to prevent the system from sleeping, to no avail.
Note that I also use a dedicated NVMe drive as my working directory so I doubt it's I/O related.
I would love to hear any suggestions on how to address this issue. It makes running integrations over night effectively useless.
The only thing I can think of would be to prevent the display from going to sleep but I'm hesitant to do so as the high contrast UI theme of APP leaves a lot of afterimages on my display (feature request: provide other themes, for instance a completely dark one, to prevent this).
I am on a MacBook and don’t see your performance issues. I do have the option to prevent the display from going to sleep enabled. Of course that doesn’t mean that you are not seeing a real issue. I am merely trying to point out that this may be solvable for you as well.
Perhaps you could consider dimming the screen manually while APP is running? Or open an empty terminal (assuming the color schema is white on black) and maximize that?
Wouter
Thanks Wouter. I can indeed use such workarounds (keeping videos/music running in the background also seems to help keep the computer running at its intended speed) but it'd be nice to find something more systemic.
It will be something Mabula will look into, but the problem here is that it's a system specific issue of MacOS. For cross platform development, some of these things are more tricky as MacOS relies heavily on xCode and that development environment. So we'll definitely look into if we can make this work.
Thank you! I'm hardly surprised considering how aggressive Apple has been over the past few years wrt saving energy. Which is nice, except when I do want my computer to get work done 🙂 Let me know if I can help in any way!
What Wouter suggests is what I do during imaging sessions - i.e. "prevent computer from sleeping when the display is off". Basically my MacBook Air is always on so that it never screws up an imaging session. So at home its always on too and haven't noticed a processing problem. I allow the screen saver but dim the screen manually during imaging.
