The No.1 Website for Pro Audio
 Search This Thread  Search This Forum  Search Reviews  Search Gear Database  Search Gear for sale  Search Gearslutz Go Advanced
Windows 10 is rolling out... share your experiences here Audio Interfaces
Old 23rd February 2018
  #5431
Quote:
Originally Posted by Owen L T View Post
Well, perhaps you should doubt it. I don't know anyone meeting that description, nor was it anything approaching the scenario under discussion here; I wasn't talking about 800 tracks, I was talking about 50 tracks. (It's right there in my post - the part you chose not to quote.)

And I was also talking about the fact that, because of this Windows limitation, a single computer can be using just a tiny percentage of its CPU, and a fraction of its RAM, but can't load any more plug-ins because of the operating system architecture.

My computer isn't maxed out, or anything close to it. But Windows is.

I'm not asking a hoover to suck up a brick; just to be able to do the things it's physically capable of, and what it was intended to do.

The entire point is that Macs with exactly the same specs can run much, much higher plug-in counts, entirely because of their OS. But none of this was well-documented or well-understood a few years ago, so a lot of us are stuck with perfectly good hardware that can't do its job properly.

And yes, I'm well aware that film composers and others run multiple computers. But it's utterly insane to have to buy multiple highly spec'd computers, each running at only 10% of capacity, merely because of an operating system's limitations.

It's hard to tell whether your post was intended to be helpful ...
While I recognize this as an issue which needs to be fixed, I do think the amount of people who are bothered by this is extremely small.
I just spoke to one of our heaviest VST users, dual 12 core Xeon (48 threads), a huge RAID5 array for libraries and more plugins than we have access to (I am not complaining here), just upgraded his array to over 6TB as well as RAM from 128 to 196GB (yes, it was not enough).
No issue.
In fact, NONE of our customers over the last 10 years have had this issue - they typically know to contact me for ANY issue.
So you can press that Apple button all you want, fact is that only an absolute minority of people have this issue. Annoying IF it pops up, but by far not a reason to dismiss an OS.
Old 23rd February 2018
  #5432
Lives for gear
 
norbury brook's Avatar
 

Quote:
Originally Posted by DAW PLUS View Post
While I recognize this as an issue which needs to be fixed, I do think the amount of people who are bothered by this is extremely small.
I just spoke to one of our heaviest VST users, dual 12 core Xeon (48 threads), a huge RAID5 array for libraries and more plugins than we have access to (I am not complaining here), just upgraded his array to over 6TB as well as RAM from 128 to 196GB (yes, it was not enough).
No issue.
In fact, NONE of our customers over the last 10 years have had this issue - they typically know to contact me for ANY issue.
So you can press that Apple button all you want, fact is that only an absolute minority of people have this issue. Annoying IF it pops up, but by far not a reason to dismiss an OS.
I think that sums it up perfectly Leon. If you can max out a 48 thread machine with 128 GIGS OF RAM without hitting that DLL limit then it's not really that big of an issue for 99% of us.

I'm mixing a 90 track 24/96k project at the moment and it's my CPU that's getting near the stops with lots of plugins :D


MC
Old 23rd February 2018
  #5433
Lives for gear
 
ponzi's Avatar
I am aware that ve pro is much used and discussed among your orchestral composer types, and I know how it works well enough for my curiosity. Cantible looks like an interesting option. Are there other approaches used for these computer farm type studios?

While I think its important to press computer and software companies to improve their products for daw use, I will observe that a desktop computer running a mainstream daw is fully capable to doing the work that probably 90% of all of our favorite hits were prepared on--lets say 64 tracks, 6 effects per track (same ones for all tracks). So, is this really holding folks back in a functional sense? In the olden days with hardware, there were not more than a dozen outboard compressor/reverb/whatever units per track. Clearly it his holding some folks back from doing what they want to do in their daw, but I am kind of wondering musically how much it is holding things back.

It does seem that if microsoft implemented some limit on dlls or whatever, said limit could likely be increased due to more powerful computers over time, and surely daw users have high end computers for the most part compared to your internet/email average computer user.
Old 23rd February 2018
  #5434
Quote:
Originally Posted by Owen L T View Post
Well, perhaps you should doubt it. I don't know anyone meeting that description, nor was it anything approaching the scenario under discussion here; I wasn't talking about 800 tracks, I was talking about 50 tracks. (It's right there in my post - the part you chose not to quote.)

And I was also talking about the fact that, because of this Windows limitation, a single computer can be using just a tiny percentage of its CPU, and a fraction of its RAM, but can't load any more plug-ins because of the operating system architecture.

My computer isn't maxed out, or anything close to it. But Windows is.

I'm not asking a hoover to suck up a brick; just to be able to do the things it's physically capable of, and what it was intended to do.

The entire point is that Macs with exactly the same specs can run much, much higher plug-in counts, entirely because of their OS. But none of this was well-documented or well-understood a few years ago, so a lot of us are stuck with perfectly good hardware that can't do its job properly.

And yes, I'm well aware that film composers and others run multiple computers. But it's utterly insane to have to buy multiple highly spec'd computers, each running at only 10% of capacity, merely because of an operating system's limitations.

It's hard to tell whether your post was intended to be helpful ...
Hyperbole methinks. I've never even heard of this issue until this thread, let alone experienced it.
Old 23rd February 2018
  #5435
Motown legend
 
Bob Olhsson's Avatar
 

Many of the biggest broadcasters have run Pro Tools on PCs for a long time. They'd switch in a heartbeat if today's macs outperformed their PCs. Now Mac system 9 and earlier DID outperform same-spec. PCs but that was prior to 18 years ago.
Old 23rd February 2018
  #5436
It's still strange to me that these FLS slots are being used. Normally, thread-local variables is what developers would use, and there's no limit there. I find it weird to think that all these plugins are fiber-aware.

The FLS issue, if it's not just an issue of statically linked runtimes in these plugins, is super strange.

Now, if the problem is that all these plugins statically link the runtime, and Arturia does it on every one of their DLLs within the plugin, then this makes sense.

Pete
Old 23rd February 2018
  #5437
Gear Maniac
 
Pictus's Avatar
 

Quote:
Originally Posted by ponzi View Post
I am aware that ve pro is much used and discussed among your orchestral composer types, and I know how it works well enough for my curiosity. Cantible looks like an interesting option. Are there other approaches used for these computer farm type studios?
You can use Reaper...
ReaMote is REAPER's network FX functionality. It allows you to have any FX chain
in your project processed on a remote machine on your local network.
This is very useful if you have a lot of CPU consuming effects and want to add
more CPU power to your project without upgrading your main host's CPU.
ReaMote - CockosWiki

Old 23rd February 2018
  #5438
kdm
Lives for gear
Quote:
Originally Posted by Psychlist1972 View Post
It's still strange to me that these FLS slots are being used. Normally, thread-local variables is what developers would use, and there's no limit there. I find it weird to think that all these plugins are fiber-aware.

The FLS issue, if it's not just an issue of statically linked runtimes in these plugins, is super strange.

Now, if the problem is that all these plugins statically link the runtime, and Arturia does it on every one of their DLLs within the plugin, then this makes sense.

Pete
You should probably talk to Arturia, Steinberg, Waves and other developers about why they are using dlls. Every plugin on the market that I use is a dll (and it is a very long list), and they use varying numbers of FLS slots. Waves uses anywhere from 1 to 4 per unique plugin instance. It is easy to skirt the problem by simply sticking to plugins that use 1 FLS slot, and are dynamically linked - large mixes can be created in under 20-30 FLS slots used. But that is only one way of working.

I haven't found a statically linked plugin yet, and can still max out the limit with dynamically linked plugins, as have other users who have posted here, and others I know of.

I know the DAW builders and others are dismissing this problem simply because they don't see it. But that doesn't take into account the users' typical method of working. Cpu power, RAM and SSDs don't determine whether an end user is going to use many of the same plugins (i.e. few FLS slots), or a wide variety of VIs hosted locally (many FLS slots). Hosting VIs outside of the DAW avoids the issue, but also assume a specific way of working that does not apply to everyone. One doesn't need a $10k PC with a $2k-$5k cpu to max out FLS slots. It isn't about the number of plugins you can run, but the number of *unique* plugins. I don't know how to make that any clearer.

Many of the end users with the most powerful systems are not using a huge range of different plugins - each instance of dynamically linked plugins still uses cpu overhead, so comparing cpu power to FLS slots is completely irrelevant.

Perhaps once people have a way of testing their free FLS slots (I am working on that), I think more will realize this limit is well within reach. Just because most people don't see it, doesn't mean it is of no concern. At one time 1G of ram seemed more than enough. Now 128G is commonplace, and easy to fill up for those of us with very large templates and multiple sample libraries.

We could just ignore the issue and wait and see what happens in 2, 3 or 5 years. But by then I know there will be a lot more people hitting the limit, and we may not be in a position to wait another year or two for a fix from developers and/or Microsoft. I only brought this problem up because any limit we can easily hit with our aging i7s, i5s and slower systems, is worth looking into. Whether the solution lies with Microsoft raising the limit (if possible), or developers moving away from dlls to some other programming method, I don't know, but I do know the limit is well within reach for the average user.

Last edited by kdm; 23rd February 2018 at 08:15 PM..
Old 23rd February 2018
  #5439
Lives for gear
 
TAFKAT's Avatar
 

Quote:
Originally Posted by Owen L T View Post
On the other hand, in my experience, a significant proportion of Cubase and Nuendo users work on Macs - and, therefore, zero proportion of those users are reporting the issue. .
From all the experience I have had with Cubendo over the last 20+ years, the larger majority of users are on Windows. If there has been a significant shift as you claim to Mac, then thats news to me.

Do you have anything to support that claim or is it purely your personal assumption as to why its not as widely experienced ?
Old 23rd February 2018
  #5440
Lives for gear
 
Owen L T's Avatar
Quote:
Originally Posted by TAFKAT View Post
From all the experience I have had with Cubendo over the last 20+ years, the larger majority of users are on Windows. If there has been a significant shift as you claim to Mac, then thats news to me.

Do you have anything to support that claim or is it purely your personal assumption as to why its not as widely experienced ?
It is limited to watching a steady stream of studio-owning friends switching over to Macs over the years, while I remained the lone Windows hold out - on the basis that one could get just as good a performance out of a PC, for less cost and more custom options. That's why I couched it in terms of "in my experience", and in direct response to rather a condescending reply from someone who assumed I knew "lots of guys" who don't know their a** from a hole in the ground. (Not his exact words!)

The point of my observation was that, at the very least, none of the people running Cubase on Macs have to deal with this limitation - which right away removes a certain percentage of people who might otherwise complain quite vocally on forums.

As far as I know, there are no stats on what percentage of Windows users are experiencing this. All I know for certain is:

(i) It was reported at least two years ago.
(ii) There are multiple threads about this on GS and Cubase forums.
(iii) Both Steinberg and Presonus acknowledged this issue well over a year ago.
(iv) The symptoms and the cause have been consistent for those reporting it.
(v) No other proximate cause has been suggested by any party.

I'm not one to Windows-bash gratuitously. I have always run my studio PC on a Windows platform, on a PC which has been built specifically to run Cubase, by music computer specialists, with the highest specs available at the time.

Right now, there is a known problem with Windows being unable to deal with plug-in counts that are well within the capabilities of the hardware. Which is frustrating.
Old 23rd February 2018
  #5441
Quote:
Originally Posted by kdm View Post
You should probably talk to Arturia, Steinberg, Waves and other developers about why they are using dlls. Every plugin on the market that I use is a dll (and it is a very long list), and they use varying numbers of FLS slots. Waves uses anywhere from 1 to 4 per unique plugin instance. It is easy to skirt the problem by simply sticking to plugins that use 1 FLS slot, and are dynamically linked - large mixes can be created in under 20-30 FLS slots used. But that is only one way of working.

I haven't found a statically linked plugin yet, and can still max out the limit with dynamically linked plugins, as have other users who have posted here, and others I know of.

I know the DAW builders and others are dismissing this problem simply because they don't see it. But that doesn't take into account the users' typical method of working. Cpu power, RAM and SSDs don't determine whether an end user is going to use many of the same plugins (i.e. few FLS slots), or a wide variety of VIs hosted locally (many FLS slots). Hosting VIs outside of the DAW avoids the issue, but also assume a specific way of working that does not apply to everyone. One doesn't need a $10k PC with a $2k-$5k cpu to max out FLS slots. It isn't about the number of plugins you can run, but the number of *unique* plugins. I don't know how to make that any clearer.

Many of the end users with the most powerful systems are not using a huge range of different plugins - each instance of dynamically linked plugins still uses cpu overhead, so comparing cpu power to FLS slots is completely irrelevant.

Perhaps once people have a way of testing their free FLS slots (I am working on that), I think more will realize this limit is well within reach. Just because most people don't see it, doesn't mean it is of no concern. At one time 1G of ram seemed more than enough. Now 128G is commonplace, and easy to fill up for those of us with very large templates and multiple sample libraries.

We could just ignore the issue and wait and see what happens in 2, 3 or 5 years. But by then I know there will be a lot more people hitting the limit, and we may not be in a position to wait another year or two for a fix from developers and/or Microsoft. I only brought this problem up because any limit we can easily hit with our aging i7s, i5s and slower systems, is worth looking into. Whether the solution lies with Microsoft raising the limit (if possible), or developers moving away from dlls to some other programming method, I don't know, but I do know the limit is well within reach for the average user.
I think you misunderstood.

A DLL itself does not automatically use an FLS slot unless the developers coded it to do so, or it uses the statically-linked VC runtime (which uses a slot), or the universal runtime (which uses 2 slots). [edit: but to use the slot more than once, it would have to be statically linked]

So if the plugins were using the dynamically-linked runtime, and were not otherwise fiber-aware, this becomes practically a non-issue.

Fibers are not something the typical DLL is aware of. They are not so common in code that one would reasonably expect to see such a high percentage of fiber aware plugins. Most developers use threads unless they're building something like SQL Server.

It's more likely that they are using the statically linked runtime.

I don't personally have contacts at Arturia, but I'll see what I can find.

Pete
Old 23rd February 2018
  #5442
Lives for gear
 
TAFKAT's Avatar
 

Quote:
Originally Posted by Owen L T View Post

The point of my observation was that, at the very least, none of the people running Cubase on Macs have to deal with this limitation - which right away removes a certain percentage of people who might otherwise complain quite vocally on forums.
So you have nothing concrete that there is in fact a significant % of Cubendo users that are using Mac, so it was an assumption only, thanks for clearing that up for me.

Quote:
As far as I know, there are no stats on what percentage of Windows users are experiencing this.
Correct , but just as much as some of us are being accused of being dismissive, which is not the case actually , even more so those that are effected are refusing to accept that there are a far larger number unaffected from our direct experience. My experience being drawn from a far wider depth and width across the number of end users in the specific environment that it should be rearing its head.

Is that saying that the problem doesn't deserve further investigation, no, but making sweeping irrational statements about the hopelessness of Windows OS for DAW use isn't going to be conducive either.
Old 23rd February 2018
  #5443
kdm
Lives for gear
Quote:
Originally Posted by Psychlist1972 View Post
I think you misunderstood.

A DLL itself does not automatically use an FLS slot unless the developers coded it to do so, or it uses the statically-linked VC runtime (which uses a slot), or the universal runtime (which uses 2 slots). [edit: but to use the slot more than once, it would have to be statically linked]

So if the plugins were using the dynamically-linked runtime, and were not otherwise fiber-aware, this becomes practically a non-issue.

Fibers are not something the typical DLL is aware of. They are not so common in code that one would reasonably expect to see such a high percentage of fiber aware plugins. Most developers use threads unless they're building something like SQL Server.

It's more likely that they are using the statically linked runtime.

I don't personally have contacts at Arturia, but I'll see what I can find.

Pete
Thank you Pete. I was going from your comment contrasting .dlls with .libs, but I assume that isn't the distinction we need to make here as all of the plugins we use (that I know of) are dlls. The same seems to apply to separate components for most DAWs, or the ones I am aware of so far.

So to clarify - if a plugin uses 1 or 2 FLS slots for the first instance only, and no additional slots for additional instances within a DAW session, it is likely using using either the statically linked VC runtime, or the universal runtime (2 slots)?

I was under the impression that any plugin that used FLS slots for each and every instance (not just the first instance) was using static linking, but it sounds like our definition of static linking vs. dynamic linking here may be too limited as it depends on which runtime the dll calls, if any - correct?

All of the plugins I have tested only use FLS slots one time - usually either 1 or 2. Each additional time that plugin is inserted in a project uses no additional FLS slots. I do know of some VIs that use 0 slots with the first instance. This could account for why most users have yet to reach the FLS limit. The problem I and others have seen is isolated to using a number of unique plugins, not plugins that allocate FLS slots with each instance in the project. The other part of this is how many the DAW uses. Most are between 15 and 35 slots (empty project, total FLS slots free, based on a total of 128 available).

Arturia knows about this problem as I and others have been in contact with them already. Steinberg knows as well. I am going to contact Waves and see what they say about the 3-4 slot usage on some of their plugins. Perhaps there are good reasons why some plugin developers made the choices they made.
Old 23rd February 2018
  #5444
Lives for gear
 
Owen L T's Avatar
Quote:
Originally Posted by TAFKAT View Post
those that are effected are refusing to accept that there are a far larger number unaffected from our direct experience.
Since you're so keen on backing up statements with hard data, perhaps you can point to a single post in this thread where someone is "refusing to accept" that most Windows have not noticed the effects of this limitation.

All I, or any of the other people posting (in this thread at least) are saying is: the limitation is real, is widely known (in as much as, again, Steinberg and Presonus have directly addressed this, and Presonus has changed the way their own plug-ins handle C++ runtime as a result), and only affects Windows machines.
Old 23rd February 2018
  #5445
Quote:
Originally Posted by kdm View Post
Thank you Pete. I was going from your comment contrasting .dlls with .libs, but I assume that isn't the distinction we need to make here as all of the plugins we use (that I know of) are dlls. The same seems to apply to separate components for most DAWs, or the ones I am aware of so far.

So to clarify - if a plugin uses 1 or 2 FLS slots for the first instance only, and no additional slots for additional instances within a DAW session, it is likely using using either the statically linked VC runtime, or the universal runtime (2 slots)?

I was under the impression that any plugin that used FLS slots for each and every instance (not just the first instance) was using static linking, but it sounds like our definition of static linking vs. dynamic linking here may be too limited as it depends on which runtime the dll calls, if any - correct?

All of the plugins I have tested only use FLS slots one time - usually either 1 or 2. Each additional time that plugin is inserted in a project uses no additional FLS slots. I do know of some VIs that use 0 slots with the first instance. This could account for why most users have yet to reach the FLS limit. The problem I and others have seen is isolated to using a number of unique plugins, not plugins that allocate FLS slots with each instance in the project. The other part of this is how many the DAW uses. Most are between 15 and 35 slots (empty project, total FLS slots free, based on a total of 128 available).

Arturia knows about this problem as I and others have been in contact with them already. Steinberg knows as well. I am going to contact Waves and see what they say about the 3-4 slot usage on some of their plugins. Perhaps there are good reasons why some plugin developers made the choices they made.
Let's take the ideal, for the moment:

If every unique plugin DLL used the same version of dynamically-linked runtime, it would use only 1 (or 2 if the universal runtime) slots across *every* plugin. Net result would be only one slot used in the entire process.

There would be no issue if that were the case, assuming that none of them are allocating FLS slots explicitly in their code with FlsAlloc() (which, again, most developers don't use)

Now, let's take the case of a host DLL with 10 sub DLLs, all of which are statically linked to the VC runtime. Assuming they use the old runtime, that means that whole thing would automatically use up at least 11 slots because each statically linked instance of the VC runtime will FlsAlloc() once itself.


Here's a somewhat simplified pic I just did to show what I'm talking about




Actions / Remedies:

First set of activities
  • Talk to the DAW vendors about static vs. dynamic linking of the runtimes in the DAW. This has already happened and they have already taken steps.
Second set of activities:
  • Find out if the big users of FLS slots are doing so because of a number of instances of the statically-linked runtime, or if they are actually using Fiber Local Storage.
  • If they are using the static runtime, we would encourage them to move to the dynamic runtime instead, across all of their DLLs in their suite.
  • If they are actually using FLS "just because", we'd encourage them to just use thread variables.
  • If they are actually using FLS because they really need to (which, again, seems like it would be rare), we'd stand down.
  • If they are using FLS slots because some framework they're using (Qt, OpenGL, JUCE, something else) uses it behind the scenes, then we talk to the framework developers.

Third set of activities:
  • I'm talking with teams inside MS to see if there's a way we can increase the number of slots in the future, and if so, what the implications of that are. I know from similar discussions, that I need the partner evidence up front. The kernel team doesn't like to make changes that support bad practices, even if it's a challenge to get the developers to change their ways. They're going to need a lot of partner evidence to support any change. I've already gotten "why are they using FLS at all?" questions here.
  • I may put together a small whitepaper on best practices here and point audio developers to it via the new version of my micro-site here: (old version that is currently up) Pro Audio Partner Resources - Windows app development

It would be super helpful if you can provide that FLS info plugin to the public. Even better if it can be open-sourced and put on GitHub for any developer to use. If you want to share it, but don't want to take on the overhead, I'm happy to put it up on my own GitHub.

Pete
Old 24th February 2018
  #5446
Lives for gear
 

Quote:
Originally Posted by foamboy View Post
Would you happen to have any insight or links that discuss sample farming? My older Win 7x64 system is very stable but I also have a few older boxes laying around that if I could utilize them for farming , it would be awesome. What software is recommended and would be a good starting point with regards to NIC cards etc.

Thanks,

fb
As mentioned, VePro is one popular way.

Another alternate way (especially if ALL your computers already have a/d, d/a interface cards that they've accumulated over the years...and (also helpful) the interfaces have wordclock, adat optical, adat 9pin, s/pdif for clocking purposes....

.... you can invest in a master clock synchronizer (say, an old Motu Digital Timepiece if you're not doing above 48k recording) or other clocks such as those by Antelope etc. It would connect to all the clock points on your various cards, and then seamlessly sync everything while you operate the shebang from your transport on your main daw.

In the second scenario, you are chase/locking computers similar to chaselock of tape machines in the old days, and in addition, the master clock provides a master clock for stuff like samples being on several diff computers....

ie, you hit play on your master daw (which of course must be a daw that can handle time code........ ie ie... which I believe includes all daws EXCEPT Studio One), and any/all your slaves running a same/exact copy of your daw.... or even a different daw, all stay in framelock sync as if they were one giant computer.

Scenario two is more old days patch bay mentality in one respect in that a lot of routing on those types of setups are done with actual patch cords between the computer interfaces.... or an actual set of patch bays in between.

Doing things this way then brings up the thought...... what is all the d/a, a/d i/o doing to my final sound in this scenario?

Some would claim that they'd rather stick with an all-digital ethernet VePro solution.

Ah.... but others.... just might believe that using all those physical patch bays adds i/o mojo..... because in the old days.... hey, you were using a zillion wires and patch bays between things.

Just maybe that old Kontakt mellotron that you haven't quite liked.... would sound a big mojo-ier coming out of its own computer on its own patch cord over to the master daw....... maybe not.

Another one of those gearslutz arguments that go on forever.

I don't know why, but for the past fifteen years, I seem to really like daw mixdowns that are captured (via patch cords) into two tracks of an entirely separate synchronized computer. Maybe it's just cuz I grew up with multitrack tape machines and separate mixdown machines.... so maybe what I like can't be quantified in any way.

But in a farm, you sure have those types of options for mixing, making stems, and much more.

By the way, search "daw farms" etc here to see various gs topics/discussions on the subject.
Old 24th February 2018
  #5447
kdm
Lives for gear
Quote:
Originally Posted by Psychlist1972 View Post

If every unique plugin DLL used the same version of dynamically-linked runtime, it would use only 1 (or 2 if the universal runtime) slots across *every* plugin. Net result would be only one slot used in the entire process.

There would be no issue if that were the case, assuming that none of them are allocating FLS slots explicitly in their code with FlsAlloc() (which, again, most developers don't use)
Thank you Pete - that is what I thought, and makes sense. Given your action steps, it sounds like one solution would be to get every plugin developer on the same runtime version (given how many versions my system has, the notion that they are all using different versions is no surprise).

None of the plugins or VIs I have been testing seem to be using statically linked VC runtimes, but they do allocate their own FLS - if I follow what you are saying about *all plugins* using 1 or 2 slots, the many versions of runtimes are a big part of the problem - hence each manufacturer's plugin still allocates it's own slots, when the could all (Waves, Fabfilter, Presonus, etc) share one, if they all compiled using the same version. Correct?

Here is one semi-realistic example of what we have currently, using plugins and VIs that I know all use dynamic linking, so we will only use one instance of each plugin in a project for this example/test:

Let's say our DAW uses 40 FLS slots. That leaves 88 free (I am taking a bit of an average between various DAWs since they all vary from 110 or so free down to 71 free).

If we load one instance of the following:
Kontakt 5.x (2)
EW Play 5 (3)
Omnisphere (1)
Arturia Arp 2600 (6)
Arturia CMI (8)
Arturia Modular (6)
Waves Abbey Road Plates (3)
Waves SSL G Stereo (2)
Waves REDD 17 (1)
Waves HVerb (2)
Fabfilter ProQ2 (2)
Fabfilter ProC2 (2)
Fabfilter ProMB (2)
Slate VMR (2)
Bx Console E (2)
Bx Console N (2)
Bx Console G (2)
Bx Delay 2500 (2)
Exponential Audio Nimbus (2)
Izotope Stutter Edit (2)


That's 54 slots out of 88, leaving 34. This isn't even beginning to tax a basic i7 system, or cover many other VIs and plugins available. If they all used the same runtime version, that total would be down to 1 or 2, instead of 54, correct?

I could go on and eliminate most if not all of the remaining 36, but since most people will tend to use multiple instances of several of the above (or other plugins), this at least puts us in the *average user* category.

Thanks again - I am more than happy to take this to developers I am in contact with, if you don't mind me copying and forwarding your action items here so nothing is lost in translation through me.

Yes, I will post a link to the FLS test plugin soon - I am waiting for the developer's permission and a public link. Probably the first of next week.
Old 24th February 2018
  #5448
Lives for gear
 

Can anyone explain why Windows Update doesn't recognize reboots or shutdowns as the cue to finish the installation of said and insists it's prompt be used?

Am I tangled in the reboot schedule setting of WU? Now I have to see if it's possible to change the behavior. I don't recall a specific setting, seems it'd be buried since it deals with WU.

I just realized the last cumulative has been awaiting a restart after a shutdown and several reboots through Start. No sooner do I finish the reboot, more updates are in the queue.

The next Quality and Feature 'upgrades' are going to be special. I hope I'm wrong, but I'm seeing different.

After this last dance with the Insider Preview, I'm seriously considering going back to W7. I've been pro W10 since I delved into it seriously. What I've realized is, is although there are no serious issues with it, it's the incessant pokes and prods and running the stick along the fence boards, meant to torment, that has wracked up some accumulative damage with me. Gone are the days you could make an image and when updates accumulated apply them to a fresh restore and grab a new image. I went years without installing XP or W7 from scratch, just updating the images, and I restored regularly. Not W10, I've lost track of the 'do-overs'.
Old 24th February 2018
  #5449
Lives for gear
 
Analogue Mastering's Avatar
You overthink all of this to much.
Just go to update and reboot when update tells you to reboot, go to update again and search for updates and repeat untill there are no further updates.
Then reboot once more, just to be sure to get all pending reboots out of it’s system.

Many updates after an initial install are sequential. This means the next update can only happen once the previous is completed. Rebooting is part of completing the update. It’s just common sense, not rocket science.
You don’t want to “manage” or postpone update related reboots. It’s not rcommended to continue to do critical work in a “pending reboot” state.

Quote:
Originally Posted by Nate Wade View Post
Can anyone explain why Windows Update doesn't recognize reboots or shutdowns as the cue to finish the installation of said and insists it's prompt be used?

Am I tangled in the reboot schedule setting of WU? Now I have to see if it's possible to change the behavior. I don't recall a specific setting, seems it'd be buried since it deals with WU.

I just realized the last cumulative has been awaiting a restart after a shutdown and several reboots through Start. No sooner do I finish the reboot, more updates are in the queue.

The next Quality and Feature 'upgrades' are going to be special. I hope I'm wrong, but I'm seeing different.

After this last dance with the Insider Preview, I'm seriously considering going back to W7. I've been pro W10 since I delved into it seriously. What I've realized is, is although there are no serious issues with it, it's the incessant pokes and prods and running the stick along the fence boards, meant to torment, that has wracked up some accumulative damage with me. Gone are the days you could make an image and when updates accumulated apply them to a fresh restore and grab a new image. I went years without installing XP or W7 from scratch, just updating the images, and I restored regularly. Not W10, I've lost track of the 'do-overs'.
Old 24th February 2018
  #5450
Lives for gear
 
TREMORS's Avatar
My Win10 home install kept trying to update to 1709 35 (!) times, failing everytime, and telling me to reboot to install in the notification area.

I finally had to use the media tool to fresh install it, and updates since have been ok.

I hope my Window Pro daw install does better (it's set to defer).
Old 24th February 2018
  #5451
Lives for gear
 

Quote:
Originally Posted by TREMORS View Post
My Win10 home install kept trying to update to 1709 35 (!) times, failing everytime, and telling me to reboot to install in the notification area.

I finally had to use the media tool to fresh install it, and updates since have been ok.

I hope my Window Pro daw install does better (it's set to defer).
You can download the latest ISO and upgrade with it at your convenience. You can run it from W10 natively. It's not just for clean installs. Probably best as the update path is sequential, next relying on previous.
Old 24th February 2018
  #5452
Motown legend
 
Bob Olhsson's Avatar
 

The reason I never defer updates is to minimize what happens when I update. If I were to run into a problem, it's pretty simple to back out of an update or even refresh the system.
Old 25th February 2018
  #5453
Lives for gear
 
Analogue Mastering's Avatar
Quote:
Originally Posted by Bob Olhsson View Post
The reason I never defer updates is to minimize what happens when I update. If I were to run into a problem, it's pretty simple to back out of an update or even refresh the system.
Exactly! When current none of these things are major isssues.
Old 25th February 2018
  #5454
Lives for gear
 
Mike O's Avatar
 

It doesn't seem rational too me to be running Insider Previews in a production DAW environment. And then complain about the number of reboots or other unexpected behavior. Perhaps I misunderstand......
Old 25th February 2018
  #5455
Lives for gear
 

Quote:
Originally Posted by Mike O View Post
It doesn't seem rational too me to be running Insider Previews in a production DAW environment. And then complain about the number of reboots or other unexpected behavior. Perhaps I misunderstand......
I multi-boot with hidden partitions. I have a dedicated DAW install along with a 'Test' install that I use for a guinea pig, a commerce install strictly for said, an office install with just those programs and the Insider install where I keep track of what's coming so as not to get surprised. (Don't get me wrong, I like surprises, but the MS variety not so much.) I also have a couple of Linux versions on the machine and W7.

I was just reporting my experiences, might help others to know if it's smooth sailing or a gale in store or anything in between.
Old 26th February 2018
  #5456
Lives for gear
 

Quote:
Originally Posted by Nate Wade View Post
I multi-boot with hidden partitions. I have a dedicated DAW install along with a 'Test' install that I use for a guinea pig, a commerce install strictly for said, an office install with just those programs and the Insider install where I keep track of what's coming so as not to get surprised. (Don't get me wrong, I like surprises, but the MS variety not so much.) I also have a couple of Linux versions on the machine and W7.

I was just reporting my experiences, might help others to know if it's smooth sailing or a gale in store or anything in between.
Hey I have a question.... fully understanding that everyone has diff preferences..

but....

what keeps you doing multi-boot/various partitions....rather than..... just a simple bay/tray with 5/6 totally separate C drives for when you want diff profiles?

You know... pop in the daw C drive tray when you're doing daw stuff. Pop that C drive out and pop in a different C drive set up for your testing. etc. With any/all your D/E drives just always in for whatever storage needs. All the C drives store neatly away when not in use.

I experimented with multi-boot over a good chunk of time in the 90s/early 2000s, using stuff like system commander and even my own multiboot with the process you can set up with win xp and 7.

But it was a tremendous headache for me... and don't even get me started on how convoluted it was to do any reliable backing up of a system with so much complication.

A simple set of various C drives (which is certainly inexpensive to do) in trays and slid into bays. It's so easy for me to handle/visualize/backup etc..... I never understand why anyone would select dual/multiboot over separate trays (notwithstanding that I still do multiboot with my Apple Minis for windows).

It's true that several C drives mean several rounds of MS updating going on... but I'm used to that. Plus, if any anomalies were to occur with one of the C drive profiles but not the others (after a win update), it'd be easier to nail down where culprits might be. Not that I've experienced that.

Dual/multi boot though.... I just can't get into it.
Old 26th February 2018
  #5457
Lives for gear
 

Quote:
Originally Posted by thenoodle View Post
Hey I have a question.... fully understanding that everyone has diff preferences..

but....

what keeps you doing multi-boot/various partitions....rather than..... just a simple bay/tray with 5/6 totally separate C drives for when you want diff profiles?

You know... pop in the daw C drive tray when you're doing daw stuff. Pop that C drive out and pop in a different C drive set up for your testing. etc. With any/all your D/E drives just always in for whatever storage needs. All the C drives store neatly away when not in use.

I experimented with multi-boot over a good chunk of time in the 90s/early 2000s, using stuff like system commander and even my own multiboot with the process you can set up with win xp and 7.

But it was a tremendous headache for me... and don't even get me started on how convoluted it was to do any reliable backing up of a system with so much complication.

A simple set of various C drives (which is certainly inexpensive to do) in trays and slid into bays. It's so easy for me to handle/visualize/backup etc..... I never understand why anyone would select dual/multiboot over separate trays (notwithstanding that I still do multiboot with my Apple Minis for windows).

It's true that several C drives mean several rounds of MS updating going on... but I'm used to that. Plus, if any anomalies were to occur with one of the C drive profiles but not the others (after a win update), it'd be easier to nail down where culprits might be. Not that I've experienced that.

Dual/multi boot though.... I just can't get into it.
So much has changed since the days of GAG and Acronis. It's basically plug and play these days. Every OS partition calls itself C:\ and never know the others exist so it is exactly like having multiple physical drives where you can have different drivers, setting, etc... without conflict. With the software I use I could fill my case and external bays with C:\ drives and boot from any and not have to physically switch anything, just reboot. Yes, you can assign any drive drive 0 when you set up the boot entry and boot from any drive no matter where it is.

It's all about hidden partitions, Windows' Boot Mangler is a good example how not to do it.

I have a DAW at day 1 newness with nothing else installed which I can restore at any time in 10-15 minutes. My commerce install has nothing but a fully updated vanilla OS install, again the new car smell is minutes away so there's no buildup of crud. Same with the office install, nothing but that. Any are a reboot away, nothing else to do.

Were I making a living at this, I'd feel a lot better knowing a perfect install was a reboot away if something took out the everyday. I could look at the talent with a straight face, blame it on MS Update, all the while rebooting to a working install. Wouldn't last long enough to become a big deal.

Anyways, it's night and day from your experience. Might want to re-examine.
Old 26th February 2018
  #5458
Motown legend
 
Bob Olhsson's Avatar
 

I would never use partitions because I've had a drive go down. I use two separate SSD system disks with windows dual-boot and have never had a problem. I have system drive backups on my 6 TB. audio drive and can quickly restore either drive from a backup while running the other system drive.
Old 26th February 2018
  #5459
Lives for gear
 

Quote:
Originally Posted by Bob Olhsson View Post
I would never use partitions because I've had a drive go down. I use two separate SSD system disks with windows dual-boot and have never had a problem. I have system drive backups on my 6 TB. audio drive and can quickly restore either drive from a backup while running the other system drive.
I've got installs on three internal disks a reboot away. OS drives contain only OS's, no data, same goes for OS partitions.
Old 26th February 2018
  #5460
Gear Addict
 
throbert's Avatar
 

Quote:
Originally Posted by thenoodle View Post
Hey I have a question.... fully understanding that everyone has diff preferences..

but....

what keeps you doing multi-boot/various partitions....rather than..... just a simple bay/tray with 5/6 totally separate C drives for when you want diff profiles?

You know... pop in the daw C drive tray when you're doing daw stuff. Pop that C drive out and pop in a different C drive set up for your testing. etc. With any/all your D/E drives just always in for whatever storage needs. All the C drives store neatly away when not in use. Also you may want to take a look at his W 10 install tute that I copied to pdf.

I experimented with multi-boot over a good chunk of time in the 90s/early 2000s, using stuff like system commander and even my own multiboot with the process you can set up with win xp and 7.

But it was a tremendous headache for me... and don't even get me started on how convoluted it was to do any reliable backing up of a system with so much complication.

A simple set of various C drives (which is certainly inexpensive to do) in trays and slid into bays. It's so easy for me to handle/visualize/backup etc..... I never understand why anyone would select dual/multiboot over separate trays (notwithstanding that I still do multiboot with my Apple Minis for windows).

It's true that several C drives mean several rounds of MS updating going on... but I'm used to that. Plus, if any anomalies were to occur with one of the C drive profiles but not the others (after a win update), it'd be easier to nail down where culprits might be. Not that I've experienced that.

Dual/multi boot though.... I just can't get into it.
From earlier posts, my understanding is Nate uses a couple apps by Terabyte.
TeraByte Drive Image Backup and Restore Suite

BootIt® Bare Metal
that Manages partitions, installs and boots multiple operating systems. Still trying
to get a grasp on this, been following and doing a little research on Nates
recommendations, cause it looks like a good way to deal with W 10 and the crappy
MS update scheme. Also, you may want to take a look at Nates W 10 install tute
that I saved to pdf, basically about installing and disabling any updates with out
your permission to keep MS from screwing with it and your drivers.
Attached Files

Last edited by throbert; 26th February 2018 at 05:37 AM..
Topic:
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
Forum Jump