Cubase and Daylights Savings again...
- KVRAF
- 6113 posts since 7 Jan, 2005 from Corporate States of America
-
- KVRAF
- 3506 posts since 12 May, 2011
Windows + Auto-update Daylight Saving Time + Cubase = plugin rescan. Twice a year without fail. Hey ho. Put it in your diary/calendar and be prepared for the next one in March.
-
- KVRian
- 538 posts since 23 Jan, 2008 from Hamburg, Germany
Cubase does this since the first Cubase VST version where the Plugins didn't even have GUIs.
I was prepared to wait for ages when I started Cubase 9 yesterday. But it started as "fast" as usual. Then I noticed that I haven't used Cubase for at least half a year.
I was prepared to wait for ages when I started Cubase 9 yesterday. But it started as "fast" as usual. Then I noticed that I haven't used Cubase for at least half a year.
-
Guillermo Navarrete Guillermo Navarrete https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=306387
- KVRist
- 478 posts since 4 Jun, 2013 from Hamburg, Germany
Hi,
"the root cause is that FNFileSystem::getFileTimes() on Windows returns the time as local time and not as universal time.
And the issue was analyzed by our QA and the conclusion was: changing this had high risk.
So if you use FNFileSystem::getFileTimes() to cache something then you will have the same problem."
Basically that's it, it is not catastrophic, it happens twice a year and repairing it will take many valuable resources and it is risky (which means, repairing it might break something else).
Best regards,
GN
Quoted from JIRA:thejonsolo wrote:You can change the time and it makes no difference. But if you have Auto Daylight Savings checked in Windows, when your OS clock changes, a rescan takes place.
Never been explained by Steinberg. They just commented that they would rather spend their time on something else than worry about those of us who complain twice per year. Oh well. I just wanted to start a topic, ha ha ha.
"the root cause is that FNFileSystem::getFileTimes() on Windows returns the time as local time and not as universal time.
And the issue was analyzed by our QA and the conclusion was: changing this had high risk.
So if you use FNFileSystem::getFileTimes() to cache something then you will have the same problem."
Basically that's it, it is not catastrophic, it happens twice a year and repairing it will take many valuable resources and it is risky (which means, repairing it might break something else).
Best regards,
GN
- KVRAF
- 6097 posts since 5 Jul, 2001 from Just about .... there
Hey G,Guillermo Navarrete wrote:Hi,
Quoted from JIRA:thejonsolo wrote:You can change the time and it makes no difference. But if you have Auto Daylight Savings checked in Windows, when your OS clock changes, a rescan takes place.
Never been explained by Steinberg. They just commented that they would rather spend their time on something else than worry about those of us who complain twice per year. Oh well. I just wanted to start a topic, ha ha ha.
"the root cause is that FNFileSystem::getFileTimes() on Windows returns the time as local time and not as universal time.
And the issue was analyzed by our QA and the conclusion was: changing this had high risk.
So if you use FNFileSystem::getFileTimes() to cache something then you will have the same problem."
Basically that's it, it is not catastrophic, it happens twice a year and repairing it will take many valuable resources and it is risky (which means, repairing it might break something else).
Best regards,
GN
I think what people want to know is not why the time error as much as why it has anything to do with plugins.
If you have to ask, you can't afford the answer
- KVRAF
- 6113 posts since 7 Jan, 2005 from Corporate States of America
Because they're generating VST registry GUIDs with the value retuned by the get time function...?
- dysamoria.com
my music @ SoundCloud
my music @ SoundCloud
- KVRAF
- 6097 posts since 5 Jul, 2001 from Just about .... there
I don't know that they are registry GUIDs, but as I wrote earlier I thought I remembered that they do a "version" check using that function, I'm not sure if they had the guid in the VST xml file back in the day. Can't remember.Jace-BeOS wrote:Because they're generating VST registry GUIDs with the value retuned by the get time function...?
If you have to ask, you can't afford the answer
- KVRAF
- 3303 posts since 27 Mar, 2010 from UK
This is why I love alternatives to c/r etc. Korg is a PITA for official users since the dropped the dongle support
But it is only once a year. hellishly annoying none the less!
- KVRAF
- 6097 posts since 5 Jul, 2001 from Just about .... there
I don't believe this had anything to do with copy protection. I think it was version identification.MFXxx wrote:This is why I love alternatives to c/r etc. Korg is a PITA for official users since the dropped the dongle supportBut it is only once a year. hellishly annoying none the less!
If you have to ask, you can't afford the answer
- KVRAF
- Topic Starter
- 2991 posts since 13 Apr, 2008 from Charleston, SC
I understand somewhat the explanation offered as to what is happening in the background. But I do NOT understand why it triggers a RESCAN of the plugins.
It seems to me that we should be able to TURN OFF scanning for plugins if we so desire. I mean if I don't want something scanning my computer, I should be able to turn of that feature without removing it.
Either way...this is dead until the Spring. Move along, ha ha ha
It seems to me that we should be able to TURN OFF scanning for plugins if we so desire. I mean if I don't want something scanning my computer, I should be able to turn of that feature without removing it.
Either way...this is dead until the Spring. Move along, ha ha ha
- KVRAF
- Topic Starter
- 2991 posts since 13 Apr, 2008 from Charleston, SC
AAAAAGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Spring. GEEEEZZZZZZZZ.
Spring. GEEEEZZZZZZZZ.