Warning. Power draw sometimes occurs when plug ins shut off

[toodamnhip]

2DamHip, just verifying all the troubles that you report could be a full-time job. Unless something has changed very recently (like since yesterday), I simply do not experience a power draw when a VI is off.

I also use V-Racks, which allows me to keep my sequences intact, without the intrusion of a VI track within a sequence. When I turn off a V-Rack, there's simply no chance of it drawing power from my sequence chunk.

I don't know what's going on at your location, but it has not been happening here. I've read where several other people have said the same thing. What bothers me is that now you've announced to the world that DP sucks at managing its resources, when it clearly does not.

I turn off VI's all the time not to save CPU resources, but simply to cut down on loading times when I'm beyond the need of the VI. The file opens almost instantly, not having to wait for the VI to load, and if a VI does not load, it cannot draw CPU resources. I'm content with that conclusion, and no, I'm not going to go chasing your premise. It would take a serious chunk out of my already vanishing day.

I think you could consider the titles of your threads before posting "Warning. HUGE..." on a topic that is questionable at best, and which clearly is not affecting others in the way that you describe. Maybe it's a problem with your particular VI.

And as for the V-Racks issue, I recommend that everyone use V-Racks. It's so simple to manage, and you will never again have to wonder if you found and turned off all the VI's in your sequence. If you get just as good results using VEPro, then that's ok, too. But there are too many advantages to V-Racks to ignore them.

Shooshie

I like the title of my post and did it to warn others. You might see it as some sort of black PR against DP, I see it as helping other users who might not know this can happen.
I did it out of concern for others who might not realize this CAN happen. As you said, you have seen others report the same thing.
If it did NOT happen, I would NOT have reported it.
If I reported it, it is because it HAPPENED.
It happened because it CAN happen, thus, I warned others.
If you don’t want DP to get a bad rep for mishaps such as mine, then DP should NOT get clogged up with old resources.
You speak of all of this like I did something wring here.
I just use the product. I was minding my own business making music and DP clogged resources, or NI, or any # of plug ins or VIs, I don;t know. I don;t know why for sure, but I do know it DID happen.
I run a very clean computer, have all the repair tools one can imagine including disk warrior, Tech Tool ad infinitum, run system scripts to clean out things like old caches.
Sorry bro but if it happens on my computer, I report it.
Glad it isn;t happening on yours.
It was a HUGE power draw and I WARNED others.
Feel free to make a post that says “WARNING, false reports on DP power draws"

[James Steele]

I haven't seen this myself, either. I'll try and point someone at MOTU to this topic here, because as we all know in this day and age of online forums, if one person has a problem, it may as well be affecting everyone.

[toodamnhip]

I haven't seen this myself, either. I'll try and point someone at MOTU to this topic here, because as we all know in this day and age of online forums, if one person has a problem, it may as well be affecting everyone.

I have changed the title of the post, not because I think I was wrong in the original title, but to make a bit of peace and to reflect incoming data from members.

That said, I have seen this issue before in my session files and have seen others have the same issue.
As data is coming in, it seems clearer that this is an intermittent problem.

I cannot know the full scope of the problem from the viewpoint of all users when I post so I post to warn users cuz this problem, when it does occur, sucks and I want users to have a “fix”.
So we now know it is intermittent or unusual..(I think).
OK, Fine.
I doubt I am a solitary person subjecting the rest of the forum to my one and only messed up session file problem.
Seen it before, heard about it before....
It CAN happen.
Stuff sticks memory.
The more plugs and VIs and the longer the time span a session file is used, the more likely this is to occur.
Maybe I seem to have more problems at times because I run HUGE demanding session files over a span of many yrs...
Maybe I am Murphy.
“Murphy”....(from Murphy’s law....lol)

[Kubi]

Silly question (which may already have been asked and/or answered.)

In cases where the processing power didn't get released for you when you disabled the VIs/tracks in question: If you then closed the project and/or quit DP, and then re-loaded the project with the VIs/tracks in question disabled from the get-go, do you see the proper amount of (reduced) CPU usage then?

Reason I'm asking is obviously, maybe there are instances where the resources don't get freed upon disabling, but then are free when the project gets loaded with the VIs/tracks disabled from the start. In other words, maybe there's a bug that sometimes, for some people, fails to free resources upon the act of disabling? Or are those tracks and VIs you mention always sucking power, even when the project was loaded with them disabled?

I certainly haven't experienced this - and have been running a couple of projects recently where I carried a lot of "dead" tracks with full processing in the project for safekeeping. So I very much have been relying on this working, and for me it seems to have been working just fine.

[toodamnhip]

Silly question (which may already have been asked and/or answered.)

In cases where the processing power didn't get released for you when you disabled the VIs/tracks in question: If you then closed the project and/or quit DP, and then re-loaded the project with the VIs/tracks in question disabled from the get-go, do you see the proper amount of (reduced) CPU usage then?

Reason I'm asking is obviously, maybe there are instances where the resources don't get freed upon disabling, but then are free when the project gets loaded with the VIs/tracks disabled from the start. In other words, maybe there's a bug that sometimes, for some people, fails to free resources upon the act of disabling? Or are those tracks and VIs you mention always sucking power, even when the project was loaded with them disabled?

I certainly haven't experienced this - and have been running a couple of projects recently where I carried a lot of "dead" tracks with full processing in the project for safekeeping. So I very much have been relying on this working, and for me it seems to have been working just fine.

The tracks that were shut off had been shut off for some time.
Some additional tracks were added and also shut off. But the session file just got to the point where it was a sluggish piece of junk.
I would say re-start would not have helped.
However, I never did tests like such as completely rebuilding the session file from scratch and re-importing the old session file contents.

I just threw the VIs into another chunk and all was well.

I guess another good test could be to bring the “bounced/off” folder BACK into the session file and see if things are still sluggish.

There could be many experiments.

[toodamnhip]

Silly question (which may already have been asked and/or answered.)

In cases where the processing power didn't get released for you when you disabled the VIs/tracks in question: If you then closed the project and/or quit DP, and then re-loaded the project with the VIs/tracks in question disabled from the get-go, do you see the proper amount of (reduced) CPU usage then?

Reason I'm asking is obviously, maybe there are instances where the resources don't get freed upon disabling, but then are free when the project gets loaded with the VIs/tracks disabled from the start. In other words, maybe there's a bug that sometimes, for some people, fails to free resources upon the act of disabling? Or are those tracks and VIs you mention always sucking power, even when the project was loaded with them disabled?

I certainly haven't experienced this - and have been running a couple of projects recently where I carried a lot of "dead" tracks with full processing in the project for safekeeping. So I very much have been relying on this working, and for me it seems to have been working just fine.

The tracks that were shut off had been shut off for some time.
Some additional tracks were added and also shut off. But the session file just got to the point where it was a sluggish piece of junk.
I would say re-start would not have helped.
However, I never did tests like such as completely rebuilding the session file from scratch and re-importing the old session file contents.

I just threw the VIs into another chunk and all was well.

I guess another good test could be to bring the “bounced/off” folder BACK into the session file and see if things are still sluggish.

There could be many experiments.

[FMiguelez]

TooDamnHip, if I may say so, I think the best thing you could do to solve your problem is to simply transfer all your unused VI tracks to another chunk (via clippings would be the fastest way).

That way they are still a few clicks away if needed, and your computer should thank you for that. Like this they should be TOTALLY gone and your CPU won't be bothered by them.
Think of this as "archiving" part of your project, which is pretty much what you are doing anyway... But instead of having them sitting around inactive in your main chunk, they'd be out of the way on their own chunk.

This is the only way I can manage my enormous template... by subdividing it among chunks. It works!

If you have track takes for the MIDI tracks, then duplicate your active chunk, and delete everything but the VI tracks in your copy. This way the takes are still available as well.

[toodamnhip]

TooDamnHip, if I may say so, I think the best thing you could do to solve your problem is to simply transfer all your unused VI tracks to another chunk (via clippings would be the fastest way).

That way they are still a few clicks away if needed, and your computer should thank you for that. Like this they should be TOTALLY gone and your CPU won't be bothered by them.
Think of this as "archiving" part of your project, which is pretty much what you are doing anyway... But instead of having them sitting around inactive in your main chunk, they'd be out of the way on their own chunk.

This is the only way I can manage my enormous template... by subdividing it among chunks. It works!

If you have track takes for the MIDI tracks, then duplicate your active chunk, and delete everything but the VI tracks in your copy. This way the takes are still available as well.

Exactly, that is what I’ve done.

[Shooshie]

ToodamHip, my apologies for making you feel like you did something wrong. I believe you acted in good conscience; my complaint is that maybe you just reacted a little too strongly. I think many would have posed this as a question: "could some VI's not be releasing the CPU when disabled?" It's certainly an interesting topic, and one whose outcome and relevance we all want to know. But I can attest to the fact that it's not happening here, not now, not ever. If there is some tiny draw that I'm unaware of, well, it sure isn't affecting anything I do. But I seriously doubt that I'm seeing any kind of CPU draw on disabled VIs.

You don't see the problem, do you? The problem comes when people see the "warning" followed by HUGE. We just got through the iLok debacle, and people are still afraid even to open the Pace site, weeks later. A subject title like yours causes people to take a step back from what they're doing, even to the point of not using VIs or V-Racks or whatever until they hear that the problem is 100% solved and resolved.

But we know now that most people do not experience this. So, rather than "Warning! HUGE…" you could at least have posted "Some VIs may not be releasing CPU when disabled." It would have opened debate, received a lot of participation, but it would not have alarmed everyone into what surely has made it around the internet by now: "Warning! DP sucks at VI management. Choose another DAW." Of course, DP handles VIs extremely well.

Again, I support your discussion of whatever is causing your problem; I do not support the needlessly alarmist post title. That's all. Under a more inquisitive title, there would not have been any backlash like this, and you'd only be discussing the possibilities of how, why, where, and when this is happening. And to whom it's happening. There may be other factors involved.

Post freely and often. You DO uncover a lot of odd behaviors, and sometimes they're universal. This one was not. Until we all agree that there's a big problem, or unless there is a genuine emergency like the iLok situation, which could shut down users simply from following Pace's instructions, couldn't we agree that thread titles DO matter, and that a more conservative approach is usually better for everyone?

Positive comments gradually infiltrate the user base over time, but negative ones travel at the speed of light, and the more dramatic they are, the more people they reach.

Shooshie

[toodamnhip]

ToodamHip, my apologies for making you feel like you did something wrong. I believe you acted in good conscience; my complaint is that maybe you just reacted a little too strongly. I think many would have posed this as a question: "could some VI's not be releasing the CPU when disabled?" It's certainly an interesting topic, and one whose outcome and relevance we all want to know. But I can attest to the fact that it's not happening here, not now, not ever. If there is some tiny draw that I'm unaware of, well, it sure isn't affecting anything I do. But I seriously doubt that I'm seeing any kind of CPU draw on disabled VIs.

You don't see the problem, do you? The problem comes when people see the "warning" followed by HUGE. We just got through the iLok debacle, and people are still afraid even to open the Pace site, weeks later. A subject title like yours causes people to take a step back from what they're doing, even to the point of not using VIs or V-Racks or whatever until they hear that the problem is 100% solved and resolved.

But we know now that most people do not experience this. So, rather than "Warning! HUGE…" you could at least have posted "Some VIs may not be releasing CPU when disabled." It would have opened debate, received a lot of participation, but it would not have alarmed everyone into what surely has made it around the internet by now: "Warning! DP sucks at VI management. Choose another DAW." Of course, DP handles VIs extremely well.

Again, I support your discussion of whatever is causing your problem; I do not support the needlessly alarmist post title. That's all. Under a more inquisitive title, there would not have been any backlash like this, and you'd only be discussing the possibilities of how, why, where, and when this is happening. And to whom it's happening. There may be other factors involved.

Post freely and often. You DO uncover a lot of odd behaviors, and sometimes they're universal. This one was not. Until we all agree that there's a big problem, or unless there is a genuine emergency like the iLok situation, which could shut down users simply from following Pace's instructions, couldn't we agree that thread titles DO matter, and that a more conservative approach is usually better for everyone?

Positive comments gradually infiltrate the user base over time, but negative ones travel at the speed of light, and the more dramatic they are, the more people they reach.

Shooshie

Maybe James should make a NEW stickie. “POSITIVE COMMENTS ABOUT DP”.
That I agree, there should be MORE of.
I see your point of view but unfortunately, it WAS a HUGE Power draw. And I was WARNING people...lol.
So I guess you’d like me to not speak straight truth or censure myself a bit out of concern for MOTU’s reputation.
Honestly, I think MOTU has SUCKED at times at promoting DP and that the reason DP is not #2 at least lies with Boston corporate, not with us members screaming the sky is falling.
It is nice to see die hards like you defend the product.
But I have seen many members here try to carry MOTU on their backs into the music industry. I too have done so, at the HIGHEST levels, fighting for DP to be the workstation on million dollar productions.
But it is also up to MOTU. They are doing better but..if MOTU would put out LARGE ad campaigns for major swathes and sections of features DP has, with all it’s amazing features, this would do more for DP’s online presence than me curbing my HONEST reporting of my experiences with the product.
You do have a point, and so do I.
We have different styles. I applaud you and James for your hard work.
The power draw WAS Huge. I warned.
You fought out of love for our products reputation. That’s great!
Now I would also recommend you go and I push MOTU to promote properly if you want to really see market share and reputation change,.
MOTU loves selling their little interface gadgets like Apple sells it’s iphones.
But as Apple came through for it’s PRO users with its new computer, it’t time for MOTU to come through and scream to the high heavens about DP’s features. They’ve sold enough gadgets for awhile.
Time for a BIG ad campaign. DP should at least be #2 in the marketplace even with me and my “sky-is-falling” warnings...lol

[ccrane]

OTOH, having too many tracks in an active chunk, even if ALL are disabled, does slow my computer down quite a bit.

What if the disabled tracks are hidden?

[ccrane]

Just did a quick limited test using Omnisphere in DP 7.24/ OS 10.6.8 while monitoring RAM usage in Activity Monitor.

One thing I wanted to do was first restart DP and relaunch the session before actually removing the disabled VIs as I know DP usually requires a restart in order to bring its RAM usage fully back down.

Here are the steps I took:


1) New DP session using custom template (no VIs or plug-ins, just auxes), RAM USAGE: 345.0 MB

2) Add: 5 Omnispheres, RAM USAGE: 986.4 MB

3) Disabled the added 5 Omnispheres, RAM USAGE: 596.5 MB

4) Restart DP and relaunch session with the 5 disabled Omnispheres: RAM USAGE: 345.9 MB

5) Remove the added 5 Omnispheres: RAM USAGE: 343.3 MB

In this limited test using Omnisphere, restarting DP after disabling the VIs was more important than removing the plug-in completely.

I don't discount TDH's report though as he implied the VIs he had disabled were from previous sessions, so I imagine he relaunched DP at some point. Also, he was using several different VIs.

I do appreciate TDH's reporting as I am one of the hold outs who likes to have everything within DP and V-Racks are problematic for me as they don't allow for true VI automation (though sometimes MIDI CC is an option for a V-Racked VI)

More tests with different VIs need to be done to have a more definitive conclusion.

[Dan Worley]

Just did a quick limited test using Omnisphere in DP 7.24/ OS 10.6.8 while monitoring RAM usage in Activity Monitor.

One thing I wanted to do was first restart DP and relaunch the session before actually removing the disabled VIs as I know DP usually requires a restart in order to bring its RAM usage fully back down.

Here are the steps I took:


1) New DP session using custom template (no VIs or plug-ins, just auxes), RAM USAGE: 345.0 MB

2) Add: 5 Omnispheres, RAM USAGE: 986.4 MB

3) Disabled the added 5 Omnispheres, RAM USAGE: 596.5 MB

4) Restart DP and relaunch session with the 5 disabled Omnispheres: RAM USAGE: 345.9 MB

5) Remove the added 5 Omnispheres: RAM USAGE: 343.3 MB

In this limited test using Omnisphere, restarting DP after disabling the VIs was more important than removing the plug-in completely.

I don't discount TDH's report though as he implied the VIs he had disabled were from previous sessions, so I imagine he relaunched DP at some point. Also, he was using several different VIs.

I do appreciate TDH's reporting as I am one of the hold outs who likes to have everything within DP and V-Racks are problematic for me as they don't allow for true VI automation (though sometimes MIDI CC is an option for a V-Racked VI)

More tests with different VIs need to be done to have a more definitive conclusion.

If this is true and DP doesn't release RAM on disabled tracks until it's restarted, then I would say DP is broken and needs repair in this area.

Thanks for testing it and thanks to TDH for bringing it up.

[cuttime]

More tests with different VIs need to be done to have a more definitive conclusion.

If this is true and DP doesn't release RAM on disabled tracks until it's restarted, then I would say DP is broken and needs repair in this area.

Thanks for testing it and thanks to TDH for bringing it up.

Interesting. Is pre-rendering on?

[ccrane]

More tests with different VIs need to be done to have a more definitive conclusion.

If this is true and DP doesn't release RAM on disabled tracks until it's restarted, then I would say DP is broken and needs repair in this area.

Thanks for testing it and thanks to TDH for bringing it up.

Interesting. Is pre-rendering on?

No. Never have that on.