the latest build feels little slower than the previous builds, is it just me or any other user feels the same as me? specially the agx module.
I was sort of waiting to see if anyone else experienced this. Just switching from photo to photo in the darkroom feels a little less snappy than the earlier 5.3 dev builds. I tried turning off denoise but it didnāt make much difference.
current master 5.3.0 build + a couple of RF lensfun data from: Kameratrollet
darktable-5.3.0+787~gf9e050a0bb_arm64.dmg (macOS >= 11.3)
darktable-5.3.0+787~gf9e050a0bb_x86_64.dmg (macOS >= 10.14)
you might run it with an in-memory library via terminal:
/Volumes/darktable/darktable.app/Contents/MacOS/darktable --library :memory:
or use a separate config directory:
/Volumes/darktable/darktable.app/Contents/MacOS/darktable --configdir ~/.config/darktable_test
also keep in mind that if you donāt disable writing sidecar files these can be messed up
both packages are unsigned, you might need to allow execution via terminal: " xattr -c <path/to/application.app> "
Release notes for 5.3.0 release: darktable/RELEASE_NOTES.md at master Ā· darktable-org/darktable Ā· GitHub
difference to released 5.2.1 see: Comparing release-5.2.1ā¦master Ā· darktable-org/darktable Ā· GitHub
1 Like
current master 5.3.0 build + a couple of RF lensfun data from: Kameratrollet
darktable-5.3.0+882~g916b7e4c99_arm64.dmg (macOS >= 11.3)
darktable-5.3.0+882~g916b7e4c99_x86_64.dmg (macOS >= 10.14)
you might run it with an in-memory library via terminal:
/Volumes/darktable/darktable.app/Contents/MacOS/darktable --library :memory:
or use a separate config directory:
/Volumes/darktable/darktable.app/Contents/MacOS/darktable --configdir ~/.config/darktable_test
also keep in mind that if you donāt disable writing sidecar files these can be messed up
both packages are unsigned, you might need to allow execution via terminal: " xattr -c <path/to/application.app> "
Release notes for 5.3.0 release: darktable/RELEASE_NOTES.md at master Ā· darktable-org/darktable Ā· GitHub
difference to released 5.2.1 see: Comparing release-5.2.1ā¦master Ā· darktable-org/darktable Ā· GitHub
2 Likes
Thank you @MStraeten.
Many thanks, I found a bug in the watermark module. Clicking on the font selection causes the programme to crash immediately. This happens regardless of the font, even after resetting the module when the field is still empty.
Thx Martin ā¦ for the effort you are putting in to updating this build !!
Andreas
issue reporting at GitHub Ā· Where software is built
Sorry no account on github, and I will not register an account.
the donāt expect a fix until someone files an issue 
1 Like
I have been able to reproduce the bug you reported and have reported the issue:
However, it would a great help for the darktable community if you would report such an issue if you find one. Any particular reason you donāt want to create a GitHub account?
Quite simply, when I retired in 2017, I vowed to only act according to my own ideas and leave everything behind me. This included avoiding anything to do with software development, which I had been involved with for 25 years.
But my newfound enthusiasm for darktable and co. has made me reconsider. Thank you for confirming the bug and logging it on Github.
I can confirm that 5.3.0-884 of the arm64 build does not exhibit the crash on the latest update of MacOS Sequoia. Release 882 did crash.
Keep in mind that the GitHub nightly builds are based on homebrew and the builds here on macports.
Macports cairo and pango versions are different (older) than the versions in homebrew.
So the builds here will have the issue until the upstream libraries are updated in macportsā¦
Yes I second that. The issue still persist till is fixed.
I have tested both the versions, both with the macport and the homebrew libraries. The nightly is fine, so the issue does not persist. That is why I have closed the issues on GitHub.
Just a question, is there any specific reasons for using macports?
I can confirm that with the nightly build 884, the error in the watermark module no longer exists.
homebrew just can build for the macOS version of the build machine (thatās the reason why the official build doesnāt support older macos versions)
Macports can build for older versions (even for Intel Macs in a silicon machine) - and these build are intended to provide darktable for those using quite old macs.
That makes such sense!