M4L Stability
Re: M4L Stability
AFAIK this is not entirely Live problem. As i understand it it is M4L issue and that same issue is causing Live to crash. So it's m4l.
-
f.poce@tiscali.nl
- Posts: 103
- Joined: Sun Mar 21, 2010 4:14 pm
Re: M4L Stability
Ableton developers pointed out in the beta forum that there is one crash situation on Windows which they do recognize (and are working on - so it was reported):
At M4L initialization (that is: when you start M4L for the *first time* since Live was open, so with the *black* Max for Live logo popping up) things can go wrong.
In particular on Windows 7 OS. M4L requires some windows dll library to start. With large M4L devices those libraries may be called before being fully loaded, causing a Live crash. It is a matter of timing (therefore the unpredictable aspect).
# Workaround/Procedure:
A workaround (not a solution), as they suggested, is to load the simplest Max for Live device possible first.
For instance load the basic (empty) "Max Midi Effect" device, which you can find in Live browser under Max for Live // Max Midi Effect.
Wait then a few seconds. Half a minute maybe. Yes, it does sound stupid, but they said it should allow dll's to be loaded properly.
This should have the effect of starting up Max for Live engine with no issues.
After that it should be possible to load complex M4L devices or Liveset saved with such devices, without crashes.
My own experience kind of confirms this workaround does indeed help.
I still had very sporadic issues, but much better.
At M4L initialization (that is: when you start M4L for the *first time* since Live was open, so with the *black* Max for Live logo popping up) things can go wrong.
In particular on Windows 7 OS. M4L requires some windows dll library to start. With large M4L devices those libraries may be called before being fully loaded, causing a Live crash. It is a matter of timing (therefore the unpredictable aspect).
# Workaround/Procedure:
A workaround (not a solution), as they suggested, is to load the simplest Max for Live device possible first.
For instance load the basic (empty) "Max Midi Effect" device, which you can find in Live browser under Max for Live // Max Midi Effect.
Wait then a few seconds. Half a minute maybe. Yes, it does sound stupid, but they said it should allow dll's to be loaded properly.
This should have the effect of starting up Max for Live engine with no issues.
After that it should be possible to load complex M4L devices or Liveset saved with such devices, without crashes.
My own experience kind of confirms this workaround does indeed help.
I still had very sporadic issues, but much better.
Last edited by f.poce@tiscali.nl on Sun Mar 15, 2015 12:27 am, edited 6 times in total.
Re: M4L Stability
Every time I hear about this issue with loading libraries, dependancies and non-resolving race conditions ... I think about this ...
http://www.lurklurk.org/linkers/linkers ... incircularCircular Dependencies
One final complication with DLLs is that Windows is stricter than Unix in requiring every symbol to have a resolution at link time. On Unix, it's possible to link a shared library that contains an unresolved symbol that the linker has never seen; in this situation, any other code that pulls in this shared library must provide that symbol, or the program will fail to load. Windows doesn't allow this sort of laxity.
In most systems this isn't a problem. Executables rely on high-level libraries, the high-level libraries rely on lower-level libraries, and everything gets linked in the opposite order—low-level libraries first, then higher-level libraries, and finally the executables that rely on it all. However, if there are circular dependencies between binaries, then things are trickier. If X.DLL needs a symbol from Y.DLL, and Y.DLL needs a symbol from X.DLL, then there is a chicken-and-egg problem: whichever library is linked first won't be able to find all of its symbols.
Windows does provide a way around this, roughly as follows.
-
f.poce@tiscali.nl
- Posts: 103
- Joined: Sun Mar 21, 2010 4:14 pm
Re: M4L Stability
You might just be spot on actually.
Anyway, to anyone on Windows (specially 7): just give a try to the procedure specified above (in my previous post).
Anyway, to anyone on Windows (specially 7): just give a try to the procedure specified above (in my previous post).
Angstrom wrote:Every time I hear about this issue with loading libraries, dependancies and non-resolving race conditions ... I think about this ...
http://www.lurklurk.org/linkers/linkers ... incircular
Re: M4L Stability
It seems daft for me to comment on the issue without all the facts, but I can't help but attempt to fix problems, it's in my nature.f.poce@tiscali.nl wrote:You might just be spot on actually.
Anyway, to anyone on Windows (specially 7): just give a try to the procedure specified above (in my previous post).
Angstrom wrote:Every time I hear about this issue with loading libraries, dependancies and non-resolving race conditions ... I think about this ...
http://www.lurklurk.org/linkers/linkers ... incircular
Perhaps I'll mention my suspicion to Torsten through centercode, I thought they'd have this fixed by now.
Re: M4L Stability
Precisely that is my experience as well. With the exception that on win 10 things are working in kinda better way...but sporadic crashes are there.f.poce@tiscali.nl wrote:Ableton developers pointed out in the beta forum that there is one crash situation on Windows which they do recognize (and are working on - so it was reported):
At M4L initialization (that is: when you start M4L for the *first time* since Live was open, so with the *black* Max for Live logo popping up) things can go wrong.
In particular on Windows 7 OS. M4L requires some windows dll library to start. With large M4L devices those libraries may be called before being fully loaded, causing a Live crash. It is a matter of timing (therefore the unpredictable aspect).
# Procedure:
A workaround (not a solution), as they suggested, is to load the simplest Max for Live device possible first.
For instance load the basic (empty) "Max Midi Effect" device, which you can find in Live browser under Max for Live // Max Midi Effect.
Wait then a few seconds. Yes it sounds stupid, but they said it allows all dll's to be loaded. This has the effect of starting up Max for Live engine with no such issues.
After that it should be possible to load complex M4L devices without crashes.
My own experience kind of confirms this workaround does indeed help. I still had very sporadic issues, but much better.
Overall win 10 is much better and i believe win 8 is great as well..
Re: M4L Stability
I tried this work arround. Crashed the first time. 2nd time I set a timer and waited 60 secs. Then loaded Polyrthumus (?) without incident. Of course save the M4L device is a bit dubious since it will crash on start up. So I just created some midi clips to work with and removed the M4L plug in from the track.
PIA.
PIA.
Re: M4L Stability
I had posted this on a separate page (viewtopic.php?f=1&t=205944), but hadn't seen this page until Because789 pointed me here...
_______________________________
Hi, I too suffer the instability of M4L devices. Particularly, it seems, the larger devices - but sometimes it could be any (I think).
Makes me doubly careful to hit Ctrl-S regularly!
I've trimmed my system down as much as I can possibly get away with, and still have a useable PC that can connect to the net.
When some (no real pattern) MaxForLive devices are loaded in the Set, Ableton 'freezes' occasionally too. Using ProcessExplorer, I've discovered that Live.exe is spiking to 99-100% CPU for maybe 5-10 seconds at a time, then recovers for maybe a minute or two, until the next freeze. Live itself doesn't crash, and like I say, there's no real pattern to when this event happens, but I believe that MaxForLive devices are the common denominator.
I've cleared out every old/unused ASIO and Midi driver from my system, except my Focusrite Scarlett and SonicCore Scope drivers, aggressively disabled Windows Services, disabled real-time scanning in Microsoft Security Essentials, disabled Windows Update, did all the other bits that S|C recommend for smooth-running Scope, uninstalled and then reinstalled both Live and the Max Runtime, and wrote a little batch script I can run as Administrator that kills other services that I occasionally use (like the Dropbox app and the NVidia Control Panel software), and while it may have alleviated the frequency of occurrence, it still hasn't fully gone away.
One thing I did not do is save the Live Set after the freeze happens. So, I'm not sure if restarting Live would mean that the freezing no longer happens - or if there's something written to the Live Set that would cause the freeze to reoccur when I load the set again. I'm always afraid that I would corrupt my Live Set if a freeze happens - instead, I just exit Live and choose not to save the Set. And yes, this has made me very diligent with CTRL-S when working in Live.
And I do get the crashes too. Crashes that aren't OutOfMemory issues, crashes mostly when loading devices (esp. MaxForLive devices) that are complex.
I understand that a straw poll such as the one in this post aren't scientific - but the same percentage of Windows users have Stability of M4L that don't. Regardless of the sample size, or who might be answering, that is not sustainable! In the face of direct competition from Bitwig, Ableton have to prioritise this.
Like, in a Beta Release, is there any flag we can pass to the Live runtime to get it to omit deeper messages?
And would getting an SSD for my Sample drive be a good idea to help alleviate the crashes I get when loading M4L devices that use loads of samples?
There's some synchronisation bug happening here. Heck, if they want a PC to aid with replication, I'll ship them mine!
Maybe those of us that do experience M4L crashes have some common issue? I'd be willing to supply system specs of what's running when I do have crashes, enumerate loaded drivers, whatever...
And no, I haven't yet sent Ableton a crash report. I am gonna devote tonight / tomorrow to working some pattern, any pattern, (even if the pattern is "There is no pattern") and annotate my crash dumps with info that I hope Ableton will find usable and useful.
This instability simply is not sustainable. I'm a programmer by day, a deployment engineer - if the software we deliver in my workplace acted like this...... well, it did after one release, and yes, I worked an 87 hour week that week..........
Win7 32-bit.
_____________________________
Because789 pointed me at the workaround that Fabrizio mentioned above. It may alleviate the issue, I will be checking. Thanks!
Yes, loading all DLLs up-front could make sense. It definitely is some kind of synchronization issue.
I do hope they can iron out their dependencies. There's a clue in the relative slowness of startup... Something is waiting for something, ...
A post in a different forum, re. M4L:
"It is the one thing that takes the longest to launch. Even off an SSD, it doesn't seem to matter to Max boot time."
I had thought it was trying to get a handle on all Audio Drivers, Audio Interfaces, and Midi I/O - maybe pinging those endpoints to check if they're alive or whatnot (network terminology - sorry). Does M4L attempt to get a handle on Audio and Midi I/O like the Standalone MaxRuntime does? Or does it defer those duties to Ableton?
If it's a DLL load issue, I will attach depends.exe (http://www.dependencywalker.com/) to Live.exe, fire it up, and see what really is happening in DLL terms under that (large!) hood. I encourage any other users to perform same, see if there's a pattern, one where we can help Ableton out with some hard facts.
There seems to be some common mention of this getting worse about 9 months ago - this is my experience too. Was it an update to Live? Or to the Max runtime? Or did Microsoft release some Win7 patch around that time that might be tripping us up? Do we know?
Should I be posting this on their Beta forums?
Thanks lads.
_______________________________
Hi, I too suffer the instability of M4L devices. Particularly, it seems, the larger devices - but sometimes it could be any (I think).
Makes me doubly careful to hit Ctrl-S regularly!
I've trimmed my system down as much as I can possibly get away with, and still have a useable PC that can connect to the net.
When some (no real pattern) MaxForLive devices are loaded in the Set, Ableton 'freezes' occasionally too. Using ProcessExplorer, I've discovered that Live.exe is spiking to 99-100% CPU for maybe 5-10 seconds at a time, then recovers for maybe a minute or two, until the next freeze. Live itself doesn't crash, and like I say, there's no real pattern to when this event happens, but I believe that MaxForLive devices are the common denominator.
I've cleared out every old/unused ASIO and Midi driver from my system, except my Focusrite Scarlett and SonicCore Scope drivers, aggressively disabled Windows Services, disabled real-time scanning in Microsoft Security Essentials, disabled Windows Update, did all the other bits that S|C recommend for smooth-running Scope, uninstalled and then reinstalled both Live and the Max Runtime, and wrote a little batch script I can run as Administrator that kills other services that I occasionally use (like the Dropbox app and the NVidia Control Panel software), and while it may have alleviated the frequency of occurrence, it still hasn't fully gone away.
One thing I did not do is save the Live Set after the freeze happens. So, I'm not sure if restarting Live would mean that the freezing no longer happens - or if there's something written to the Live Set that would cause the freeze to reoccur when I load the set again. I'm always afraid that I would corrupt my Live Set if a freeze happens - instead, I just exit Live and choose not to save the Set. And yes, this has made me very diligent with CTRL-S when working in Live.
And I do get the crashes too. Crashes that aren't OutOfMemory issues, crashes mostly when loading devices (esp. MaxForLive devices) that are complex.
I understand that a straw poll such as the one in this post aren't scientific - but the same percentage of Windows users have Stability of M4L that don't. Regardless of the sample size, or who might be answering, that is not sustainable! In the face of direct competition from Bitwig, Ableton have to prioritise this.
Like, in a Beta Release, is there any flag we can pass to the Live runtime to get it to omit deeper messages?
And would getting an SSD for my Sample drive be a good idea to help alleviate the crashes I get when loading M4L devices that use loads of samples?
There's some synchronisation bug happening here. Heck, if they want a PC to aid with replication, I'll ship them mine!
Maybe those of us that do experience M4L crashes have some common issue? I'd be willing to supply system specs of what's running when I do have crashes, enumerate loaded drivers, whatever...
And no, I haven't yet sent Ableton a crash report. I am gonna devote tonight / tomorrow to working some pattern, any pattern, (even if the pattern is "There is no pattern") and annotate my crash dumps with info that I hope Ableton will find usable and useful.
This instability simply is not sustainable. I'm a programmer by day, a deployment engineer - if the software we deliver in my workplace acted like this...... well, it did after one release, and yes, I worked an 87 hour week that week..........
Win7 32-bit.
_____________________________
Because789 pointed me at the workaround that Fabrizio mentioned above. It may alleviate the issue, I will be checking. Thanks!
Yes, loading all DLLs up-front could make sense. It definitely is some kind of synchronization issue.
I do hope they can iron out their dependencies. There's a clue in the relative slowness of startup... Something is waiting for something, ...
A post in a different forum, re. M4L:
"It is the one thing that takes the longest to launch. Even off an SSD, it doesn't seem to matter to Max boot time."
I had thought it was trying to get a handle on all Audio Drivers, Audio Interfaces, and Midi I/O - maybe pinging those endpoints to check if they're alive or whatnot (network terminology - sorry). Does M4L attempt to get a handle on Audio and Midi I/O like the Standalone MaxRuntime does? Or does it defer those duties to Ableton?
If it's a DLL load issue, I will attach depends.exe (http://www.dependencywalker.com/) to Live.exe, fire it up, and see what really is happening in DLL terms under that (large!) hood. I encourage any other users to perform same, see if there's a pattern, one where we can help Ableton out with some hard facts.
There seems to be some common mention of this getting worse about 9 months ago - this is my experience too. Was it an update to Live? Or to the Max runtime? Or did Microsoft release some Win7 patch around that time that might be tripping us up? Do we know?
Should I be posting this on their Beta forums?
Thanks lads.
-
irrelevance
- Posts: 463
- Joined: Tue May 20, 2008 7:31 pm
Re: M4L Stability
Does anyone else encounter Exception EOF errors from m4l plugins? I'm win 7 64bit and I have max patches loaded as default and rarely get startup crashes but it can happen. These EOF crashes look like this in the log:
Exception: "C\User\Name\Documents\Ableton\User Library\Presets\Midi Effects\Max Midi Effect\Imported\Max Device Name.amxd": EOF
Memory Usage: v:2.6 GB, R:2 GB P: 2.1
When these errors occur the Live screen freezes while audio continues to play but the program has become completely unresponsive and requires a hard reset (End Process Tree) in Windows Task Manager to exit the program.
Exception: "C\User\Name\Documents\Ableton\User Library\Presets\Midi Effects\Max Midi Effect\Imported\Max Device Name.amxd": EOF
Memory Usage: v:2.6 GB, R:2 GB P: 2.1
When these errors occur the Live screen freezes while audio continues to play but the program has become completely unresponsive and requires a hard reset (End Process Tree) in Windows Task Manager to exit the program.
Re: M4L Stability
To comment your post i can say to you that i:Eanna wrote:
And no, I haven't yet sent Ableton a crash report. I am gonna devote tonight / tomorrow to working some pattern, any pattern, (even if the pattern is "There is no pattern") and annotate my crash dumps with info that I hope Ableton will find usable and useful.
Because789 pointed me at the workaround that Fabrizio mentioned above. It may alleviate the issue, I will be checking. Thanks!
There seems to be some common mention of this getting worse about 9 months ago - this is my experience too. Was it an update to Live? Or to the Max runtime? Or did Microsoft release some Win7 patch around that time that might be tripping us up? Do we know?
Should I be posting this on their Beta forums?
Thanks lads.
- sent numerous crash report about this in the period of 4 months (nothing happened though)
- can say that indeed before i think Max was much more stable. When i started to use live and m4live it wasn't that buggy. In the meantime i did not updated windows with any update or fix or whatever(but updated Ableton and m4live) and i tried to replicate these errors (and they did replicated) on three different computers with win7 clean install.
I have much better result with win 10 tech preview and people claim better stability with Win8. Still crashing but much better. My guess is that they updated Max and Ableton somehow and now it is crashing like hell on win7. Terrible experience..
Re: M4L Stability
Yes, I agree, it's been a right nightmare...tecolo wrote:My guess is that they updated Max and Ableton somehow and now it is crashing like hell on win7. Terrible experience..
I've not found any pattern to the crashes btw, and the "Load the basic M4L Midi Device" workaround helps for some large sample-based instruments (Sonic Faction's "Sickness" would never load fully for me before now), but is not a reliable solution - I still get occasional crashes, and am revisited by the 99% CPU chew of Ableton.exe on devices such as Oscillot.
Why am I spending money on devices that don't work on my system?? Call me a foolhardy optimist... I probably am.
The more I experience these issues, the more I believe that delay-load DLLs must be somehow conflicting here. I didn't get too far with depends.exe showing the DLL load process - have had to download the VC Redistributable DLLs one by one (not sure how these get packaged once installed) - and the nature of how it operates, it may well be that depends.exe's intrusive nature of reflecting on the DLL load process will mask the synchronization issue of these DLL load events... I.e. I might have a stable (but hugely slowed-down) Ableton if I could get depends.exe to complete the Ableton Launch process!
What has me worried is that it appears that those with a full Max 7 licence seem to be affected. I would have thought that the Max7 Runtime may have solved the issue... seemingly not. And I'm acutely aware that an issue like this can turn into a blame game between Ableton dev and Cycling 74 dev - I hope I'm wrong about that! I hope both teams work together.
The good news is that there was some update event in the relatively-recent past that cause this issue. That should make finding the bug far easier, I would have thought.
I responded to the Ableton Survey email today - gave them a 0 score for stability - I urge those that got a similar email do the same, impressing upon Ableton that Stability is a huge issue - one that had me looking at bitwig.com again.
-
stringtapper
- Posts: 6302
- Joined: Sat Aug 28, 2004 6:21 pm
Re: M4L Stability
So it looks like about 95% of the users with these M4L crashes are on Windows?
Unsound Designer
Re: M4L Stability
Well I'm not sure if it's 95% - judging by the poll here viewtopic.php?f=1&t=205944
But I'm not sure the nature of the issues that os x users experience.
The significant issues do appear to be manifested on windows tho, yeah.
But I'm not sure the nature of the issues that os x users experience.
The significant issues do appear to be manifested on windows tho, yeah.
-
NoSonic822
- Posts: 700
- Joined: Sat Jun 01, 2013 8:38 am
Re: M4L Stability
let me just say that max4L hass been incredibly unstable in the past , has been since i first got suite......, it basically made me never use any of the devices, because they always caused crashing.....i just noticed an update though foir max and using it now, maybe this will help..Eanna wrote:Well I'm not sure if it's 95% - judging by the poll here viewtopic.php?f=1&t=205944
But I'm not sure the nature of the issues that os x users experience.
The significant issues do appear to be manifested on windows tho, yeah.
Re: M4L Stability
I guess the obvious question here is whether there is any installation of M4L with the latest Ableton release or with the public beta on Win7 32/63-bit that has stability...?
If there are those with rock-solid Win7 M4L, then it must be something in the configuration of the machine.
User tecolo above has said:
> i tried to replicate these errors (and they did replicated) on three different computers with win7 clean install.
So, clean installations of Win7 appear to suffer the issue. Not sure what additional configuration tecolo's clean machines had - what ASIO driver might have been installed, any other hardware drivers, etc. But, that does not read well, that a clean install of win7 on multiple machines has the problem. I guess that, if the problem is some Memory Sharing issue or other, would a slow memory bus potentially be a problem? Or a slow HardDrive? Or something innate to a CPU configuration - like hyperthreading / multi-core support / core affinity? I know my own memory bus is pretty slow on my stock Dell desktop unit, but the machine is otherwise well specced. Might it be a graphics driver issue? I did upgrade my Graphics Driver (again) last week to see if that had any effect - it didn't.
I am forever suspicious of the standalone Max Runtime trying to enumerate every Audio and Midi Endpoint using a variety of APIs when its audio and midi engine is launched. E.g. the LiquidRhythm standalone uses the Max Runtime to look after Midi and Audio I/O - it's Preferences dialog enumerates a bunch of Audio and Midi APIs to connected hardware units - some of which don't work, some of which I never see in other programs - APIs other than ASIO are displayed there. And, with my Sonic Core Scope PCI cards, if Scope is not started, Max will see its ASIO endpoints, but appears to attempt to 'ping' them or something... If Scope isn't started, Max will hang on startup... The only way I can get LiquidRhythm standalone to start successfully is if I start Scope beforehand. Ableton, and other DAWs, do not behave like this - Scope doesn't have to be started beforehand. I expect that M4L Max Runtime doesn't use use the Max audio and midi subsystem - it defers that to Ableton... so maybe I shouldn't be so suspicious?
I've also read elsewhere in this thread that there are no instability issues when Ableton's audio engine is switched off. Others appear to recommend a higher audio buffer size. These point to the interfacing points between M4L and Ableton's audio subsystem....
I still lean towards a DLL load / synchronization issue. It feels like I have a more stable Ableton if I load that basic M4L Midi Device, and let Ableton sit for 5+ mins, during which all delay-load DLLs would be loaded "in concert". Obviously, a 'feeling' isn't exactly scientific..... And I'm not a Windows developer, so, "a little knowledge is a dangerous thing".
I appreciate that a badly-coded / non-standard M4L patch / patch compiled for a previous version of M4L may theoretically cause issues. But, Skinnerbox, MaxForCats, SonicFaction, even the stock LFO device - these are reputable M4L developers who have released patches recently, and their devices are implicated - especially the 'bigger' devices (=> load synchronization issues).
I only have patience for this kinda "black-box diagnostics" stuff, cause I know that, if it is fixed (and heck, it's software - of course it's fixable), I'll be very happy/relieved - it's worth the short-term pain, so long as we, as a fully-paid-up user community, can get Ableton to listen up, to recognise the issue, and to prioritise its fixing.
And no, I have no mind to install a later version of Windows as some kind of workaround. I've only one audio PC, I'm not embarking on a purchase of Windows and subsequent OS rebuild, especially since I am not seeing any guarantee of rock-solid stability on later Windows releases.
Should I be posting on the Beta forums? Is there activity discussing these issues on the Beta forums?
If there are those with rock-solid Win7 M4L, then it must be something in the configuration of the machine.
User tecolo above has said:
> i tried to replicate these errors (and they did replicated) on three different computers with win7 clean install.
So, clean installations of Win7 appear to suffer the issue. Not sure what additional configuration tecolo's clean machines had - what ASIO driver might have been installed, any other hardware drivers, etc. But, that does not read well, that a clean install of win7 on multiple machines has the problem. I guess that, if the problem is some Memory Sharing issue or other, would a slow memory bus potentially be a problem? Or a slow HardDrive? Or something innate to a CPU configuration - like hyperthreading / multi-core support / core affinity? I know my own memory bus is pretty slow on my stock Dell desktop unit, but the machine is otherwise well specced. Might it be a graphics driver issue? I did upgrade my Graphics Driver (again) last week to see if that had any effect - it didn't.
I am forever suspicious of the standalone Max Runtime trying to enumerate every Audio and Midi Endpoint using a variety of APIs when its audio and midi engine is launched. E.g. the LiquidRhythm standalone uses the Max Runtime to look after Midi and Audio I/O - it's Preferences dialog enumerates a bunch of Audio and Midi APIs to connected hardware units - some of which don't work, some of which I never see in other programs - APIs other than ASIO are displayed there. And, with my Sonic Core Scope PCI cards, if Scope is not started, Max will see its ASIO endpoints, but appears to attempt to 'ping' them or something... If Scope isn't started, Max will hang on startup... The only way I can get LiquidRhythm standalone to start successfully is if I start Scope beforehand. Ableton, and other DAWs, do not behave like this - Scope doesn't have to be started beforehand. I expect that M4L Max Runtime doesn't use use the Max audio and midi subsystem - it defers that to Ableton... so maybe I shouldn't be so suspicious?
I've also read elsewhere in this thread that there are no instability issues when Ableton's audio engine is switched off. Others appear to recommend a higher audio buffer size. These point to the interfacing points between M4L and Ableton's audio subsystem....
I still lean towards a DLL load / synchronization issue. It feels like I have a more stable Ableton if I load that basic M4L Midi Device, and let Ableton sit for 5+ mins, during which all delay-load DLLs would be loaded "in concert". Obviously, a 'feeling' isn't exactly scientific..... And I'm not a Windows developer, so, "a little knowledge is a dangerous thing".
I appreciate that a badly-coded / non-standard M4L patch / patch compiled for a previous version of M4L may theoretically cause issues. But, Skinnerbox, MaxForCats, SonicFaction, even the stock LFO device - these are reputable M4L developers who have released patches recently, and their devices are implicated - especially the 'bigger' devices (=> load synchronization issues).
I only have patience for this kinda "black-box diagnostics" stuff, cause I know that, if it is fixed (and heck, it's software - of course it's fixable), I'll be very happy/relieved - it's worth the short-term pain, so long as we, as a fully-paid-up user community, can get Ableton to listen up, to recognise the issue, and to prioritise its fixing.
And no, I have no mind to install a later version of Windows as some kind of workaround. I've only one audio PC, I'm not embarking on a purchase of Windows and subsequent OS rebuild, especially since I am not seeing any guarantee of rock-solid stability on later Windows releases.
Should I be posting on the Beta forums? Is there activity discussing these issues on the Beta forums?