New roast does not line up with Background #1279
Comments
First of all note that Artisan 2.8.5 (as all versions ending in uneven numbers) are development builds, not to be used for anything but testing. Some of those builds simply don't work or have major known issues. Hm. Hard to see in detail from this screen shot (why not attach both, background and foreground .alog profiles, renamed to end in .txt, here to allow us to check), but to me it seems to both pairs of CHARGE annotations, the one of the background and the one of the foreground are perfectly aligned at this moment. Just maybe the CHAR>GE annotations of the background profile is not placed where it should be. Anyhow, there was no code change on this mechanism since several versions of Artisan.
Not relevant.
Most likely not an Artisan issue. Check first if calling your script from outside of Artisan, like from a shell running in the Terminal.app, works. |
|
Understood about 2.8.5 but it is working better for me than 2.8.4 (aside from this new issue). I don't recall the roast from the original screenshot I uploaded but it doesn't matter because the issue was consistent. Attaching .alog files for the background and active roast as well as a screenshot showing how the traces lined up after the roast ended. Regarding my "silent alarm", I had several using French Audrey to alert me to upcoming events. It appears they cancelled her in this version of the OS since I'm getting an error that she can't be found. When I don't reference her and use the default boring voice, it works. What have they done with her?! Sacre bleu! |
|
Running this on the simulator you see that align on CHARGE works as expected. However, the CHARGE mark on your background profile might not be placed where you expected it to be. This explains the relative large lag with your 2sec sampling rate. If your machine/comm setup allows you could reduce this to 1sec. Note that you can move the background profile (via the buttons in the background dialog or the cursor keys) during roasting to make it fit better your current roast. Anyhow, we are working to further improve autoCHARGE marking for the next version of Artisan. It is quite difficult to come up with an approach which is satisfying on all setups as the produced data is quite different. 
I am closing this one as it is kind of a duplicate (see 1232) Regarding "French Audrey" you might need to re-download her voice: https://support.apple.com/en-mk/guide/mac-help/mchlp2290/mac |
|
I understand this issue is now closed but just a quick followup…
1. This is the first time I’ve experienced this issue after years using Artisan and it was consistent across all my roasts. I acknowledge you saying the OS upgrade should not make a difference but that’s the only thing that changed with my setup.
2. I confirm, and correct when necessary, my CHARGE and DROP annotations every time before saving my profiles so the background mark should be where I expect it to be.
3. Artisan DID correctly line up the two graphs but only after I stopped the roast. So it aligned the graphs correctly, only after and not at the beginning of the roast as it has always done for me in the past.
And a quick comment regarding “French Audrey”. You are correct that I needed to re-download her voice but not only that, she was replaced with Aude so I had to edit all my alarms with the new name. I know you’re not Apple support but I’m going to just vent and exclaim that whoever is in charge of the voices at Apple should be immediately fired and blacklisted from the tech industry because why the hell would you do that?!
Dan
Fat Rabbit Coffee
***@***.***
www.fatrabbitcoffee.com
… On Oct 12, 2023, at 11:27 PM, Marko Luther ***@***.***> wrote:
Running this on the simulator you see that align on CHARGE works as expected. However, the CHARGE mark on your background profile might not be placed where you expected it to be. This explains the relative large lag with your 2sec sampling rate. If your machine/comm setup allows you could reduce this to 1sec. Note that you can move the background profile (via the buttons in the background dialog or the cursor keys) during roasting to make it fit better your current roast. Anyhow, we are working to further improve autoCHARGE marking for the next version of Artisan. It is quite difficult to come up with an approach which is satisfying on all setups as the produced data is quite different.
<https://user-images.githubusercontent.com/13909011/274814317-7e1f48e5-d588-4e1d-8a42-b0b6b66a877e.png>
I am closing this one as it is kind of a duplicate (see 1232)
Regarding "French Audrey" you might need to re-download her voice:
https://support.apple.com/en-mk/guide/mac-help/mchlp2290/mac
—
Reply to this email directly, view it on GitHub <#1279 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWUZI4EVKTOHNGVR2TCLA43X7DNORANCNFSM6AAAAAA555EX7I>.
You are receiving this because you authored the thread.
|
|
I cannot reproduce your issue here. Can you reproduce it using the Artisan Simulator on the two profiles you attached? If yes, please attach your Artisan settings file here (again renamed to end in .txt) and a screenshot of your Artisan about box to make sure which build are are exactly using. Thanks! |
|
I ran the simulator and experienced the same issue. Files attached as requested. The first screenshot shows the offset I'm talking about. The second screenshot shows how the graph corrects itself once I click 'OFF'. Never mind the charge point being late. When I correct that, everything lines up perfectly. Sometimes it recognizes the correct charge point and sometimes it's off by a bit like in this example. Consequently, I also ran the simulator on a roast prior to my update to Ventura when I did not experience the issue but I did experience the issue through the simulator so I don't know what else it could possibly be aside from something having to do with Ventura. |
|
Thanks for sending your settings and the further information. We have an idea what is going on here. Give us a moment time to resolve this. |
|
Here's another curious thing I just noticed, possibly related? I'm attaching two screenshots. The first shows the beginning of the roast where Artisan gets the charge point perfectly. The second shows after I stop the roast and Artisan curiously moves the charge point a bit later in time. The annotation is identical but it's off graphically. |
|
Unfortunately it is not possible to diagnose this one from a screenshot. Could you post this profile for me to take a look at? Thanks! |
|
Understood - I was just showing an example rather than requesting a diagnosis since it seems like the issue might be related to the other one currently being looked at. But attaching a different roast (because I don't think I have the .alog for the one I took pics of) that I believe suffered the same issue. |
|
Thanks for this additional profile. This issue is not caused by the OS version or Artisan version, but an issue how optimal smoothing works. For now you can just disable "optimal smoothing" under menu Config >> Curves, tab "Filters", untick "Optimal Smoothing Post Roast". We update as soon as possible. |
|
Dear Dan, the issue is caused by the application of different smoothing algorithms during recording then while being offline. If not recording OFFLINE smoothing algorithms can be applied which do not cause any time shifting as at any point the future is known. Thus to smooth a point the readings before, but also the reading after the point can be taken into account. This is not true during recording where only previous readings can be used to smooth the current one. This always leads to some shifting of the time. The more smoothing is applied the more shifting happens. There was also a difference of the handling of the background profile vs the foreground profile. For the background profile the future is know also during recording thus Artisan applied non-shifting OFFLINE algorithms. Further, there is an interplay of several smoothing algorithms that are applied in different places. The most fundamental is "Curve Smoothing" which is applied to every curve, but never during recording. That alone can lead to discrepancies in time shifting between the foreground and the background profile. The algorithm applied is a simple ONLINE decay averaging (in case "optional smoothing" is not ticked) which creates quite some time shifting and smoothing artefacts if applied strongly. There is further curve smoothing algorithm that can be activated via the "Smooth Spikes" flag. This one is a median filter which comes in two variants, an ONLINE and an OFFLINE variant. This one only introduce minimal or no time-shifting and takes away some of the high-frequency noise. Finally, there is the RoR computation which can be influenced by the selection of the delta span and the algorithm to use (polyfit or not). This one also has an "optimal" version which has the advantage of not causing any time shift but works only OFFLINE. After the RoR curve is computed (based on the smoothed version of the underlying curve), additional smoothing can be applied, which again adds more time shifting. I now revised the implementation such that during recording the same smoothing is applied to the background profile as is to the foreground profile being recorded. There should not be any relative timer-shifting between those anymore. Still it is adviced to apply only minimal software smoothing on the Artisan side to avoid the introduction of too much signal delay. Thus one should not use curve smoothing larger than 1 (maybe 2 is ok in some cases). "Smooth Spikes" can be activated if it helps. Then one should reduce the noise of the RoR curve by choosing a longer delta span, but not longer than needed. Delta smoothing should be applied only minimally or not at all. Optimal smoothing can be ticked, but will not have any consequences during recording. There new continuous builds as well as a specific signed and notarized universal binary for macOS which should run native on Apple Silicon (M1, M2, M3, ..). Please report if this works for you and I can close this issue. |
|
Marko,
Thank you for this detailed reply and the updated build. I forgot to update the issue the other day after I roasted a number of batches. You had suggested I turn off ‘Optimal Smoothing’ and I did. After doing that, things seemed better - as expected.
Dan
Fat Rabbit Coffee
***@***.*** ***@***.***>
www.fatrabbitcoffee.com <http://www.fatrabbitcoffee.com/>
… On Nov 4, 2023, at 8:07 AM, Marko Luther ***@***.***> wrote:
Dear Dan,
the issue is caused by the application of different smoothing algorithms during recording then while being offline. If not recording OFFLINE smoothing algorithms can be applied which do not cause any time shifting as at any point the future is known. Thus to smooth a point the readings before, but also the reading after the point can be taken into account. This is not true during recording where only previous readings can be used to smooth the current one. This always leads to some shifting of the time. The more smoothing is applied the more shifting happens.
There was also a difference of the handling of the background profile vs the foreground profile. For the background profile the future is know also during recording thus Artisan applied non-shifting OFFLINE algorithms.
Further, there is an interplay of several smoothing algorithms that are applied in different places. The most fundamental is "Curve Smoothing" which is applied to every curve, but never during recording. That alone can lead to discrepancies in time shifting between the foreground and the background profile. The algorithm applied is a simple ONLINE decay averaging (in case "optional smoothing" is not ticked) which creates quite some time shifting and smoothing artefacts if applied strongly.
There is further curve smoothing algorithm that can be activated via the "Smooth Spikes" flag. This one is a median filter which comes in two variants, an ONLINE and an OFFLINE variant. This one only introduce minimal or no time-shifting and takes away some of the high-frequency noise.
Finally, there is the RoR computation which can be influenced by the selection of the delta span and the algorithm to use (polyfit or not). This one also has an "optimal" version which has the advantage of not causing any time shift but works only OFFLINE. After the RoR curve is computed (based on the smoothed version of the underlying curve), additional smoothing can be applied, which again adds more time shifting.
I now revised the implementation such that during recording the same smoothing is applied to the background profile as is to the foreground profile being recorded. There should not be any relative timer-shifting between those anymore.
Still it is adviced to apply only minimal software smoothing on the Artisan side to avoid the introduction of too much signal delay. Thus one should not use curve smoothing larger than 1 (maybe 2 is ok in some cases). "Smooth Spikes" can be activated if it helps. Then one should reduce the noise of the RoR curve by choosing a longer delta span, but not longer than needed. Delta smoothing should be applied only minimally or not at all. Optimal smoothing can be ticked, but will not have any consequences during recording.
There new continuous builds <https://github.com/artisan-roaster-scope/artisan/releases/tag/continuous> as well as a specific signed and notarized universal binary for macOS which should run native on Apple Silicon (M1, M2, M3, ..) <https://github.com/artisan-roaster-scope/artisan/releases/tag/m1-test-native>.
Please report if this works for you and I can close this issue.
—
Reply to this email directly, view it on GitHub <#1279 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWUZI4FVZGQ3253GLWQKYL3YCZK4PAVCNFSM6AAAAAA555EX7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGQ3TANRQHA>.
You are receiving this because you authored the thread.
|
|
On your setup, I would reduce "Curve Smoothing" from 3 to 1, increase the "Delta Span" from 10 to 15 and tick "Optimal Smoothing" in case you like to see no time shift while OFF (no effect during roasting). Further I would deactivate the DeltaET curve as it is too noisy. This is normal, even on RTD setups, and most likely caused by machine vibration and air turbulences within the drum which renders the ET signal more noisy. |
M1 laptop - same I've used for years. Artisan 2.8.5. MacOS Ventura 13.6.
This is a new issue for me. When using a background profile, starting a new roast used to automatically line up the two graphs upon charge. Now, it doesn't line up until I end the roast. Then, it snaps into place. Much more useful to have it snap into place at the beginning so I can really compare along the way.
I did make one change which was updating my OS to Ventura from Monterey.
Another issue, which I'm not convinced is a fault of Artisan but is also a new issue, is that my audible alarms are no longer audible. I see the info at the top when an alarm goes off but I don't hear anything. I checked my audio output settings and all looks ok.
The text was updated successfully, but these errors were encountered: