Quick Sign In:  

Forum: VirtualDJ 8.1 Technical Support

Topic: OnStop / OnStart not called during a hard reset of the D3D device. - Page: 1

This part of topic is old and might contain outdated or incorrect information

I use OnStop and OnStart to well start and stop things like threads etc. In OnDeviceClose I also stop things. OnStop is called during deactivation but OnDeviceClose is not. This is fine and in this case the threads are just idle and nothing going on.

Now when you do a hard reset of the D3D device like when you do ctrl+alt+del to bring up task manager, then OnStop / OnStart are not called. OnDeviceInit and OnDeviceClose are called though. Now if you don't stop and start your stuff in OnStop and OnStart you potentially have things still doing work in a multi-threaded environment after deactivation.

It seems you have this hard reset working pretty well now. I have tracked that since the early days of VDJ8 and now seems pretty good. Except this appears to me to have been missed. It is not too big a deal because I just catch it in OnDraw but seems there should be better consistency here. So when hard reset occurs, OnDeviceClose and OnDeviceInit are called but OnStop and OnStart are not called. During deactivation OnStop is called and OnDeviceClose is not called and this is how it should be for deactivation but seems to me OnStop / OnStart should also be called during hard reset.
 

Posted Tue 01 Dec 15 @ 3:01 pm
Oops spoke too soon... When a video effect (any video effect) is running displaying something and then bringing up task manager when videoForceFullscreen is set to 1 causes VDJ UI to go completely gray and stops video output. Only way out is to end process thru task manager that you just brought up :) When a video effect is not active it appears ok even if you have video on a deck. It may be that OnStop / OnStart not being called is playing a bigger role than I thought but could be something else as well. It appears that the video effect only has to be activated once. Then even after deactivation the problem still occurs. I have not traced into it yet.

PC 8.1 build 2587
AMD Radeon HD 5450
 

Posted Wed 02 Dec 15 @ 3:34 pm
AdionPRO InfinityCTOMember since 2006
I'm not sure if that is actually wanted behavior.
If you have a video driver crash, or a cable disconnect/reconnect, you will usually just get a quick OnDeviceClose/OnDeviceInit
Depending on the plugin, it is however likely that after recreating the DirectX resources, that you can just continue what you were doing.

Calling OnStop/OnStart on the other hand, may cause some plugins to restart timers and animation positions, so the recovery would not be as smooth.
 

Posted Thu 03 Dec 15 @ 4:09 pm
You may be right on that end Adion and was not too concerned about it and mostly just info. But the gray screen condition and end process to get out is probably something you want to take a look at. Can you reproduce that?

Adion wrote :
Calling OnStop/OnStart on the other hand, may cause some plugins to restart timers and animation positions, so the recovery would not be as smooth.


I have asked several times why you call OnStop/OnStart for audio only visualizations when user tries to deactivate it. I have never gotten an answer on it but I can assume it all ties back to awkward way visualizations are currently handled in VDJ. Also if you are not completely stopping in OnDeviceClose you are already in trouble. OnStop and OnStart has always been the middle ground for this and should be consistent.
 

Posted Thu 03 Dec 15 @ 4:38 pm
SBDJPRO Infinity Member since 2006
I disagree; you don't need to stop everything in OnDeviceClose(). The functions serve two different purposes.
 

Posted Thu 03 Dec 15 @ 7:57 pm
As a general rule I think you do because when else are you going to clean up? Especially since the device is subject to change and you may have outstanding allocations. You could on Release I suppose but that would not be good as I see it. Device may be gone, stuff doing work or allocations needlessly, etc.

Please explain your rational though.

OnStop and OnDeviceClose have different meanings and I use OnStop and OnDeviceClose in different ways. To me OnDeviceClose means it is time to clean up. OnStop means to me put things on hold like threads etc. but not time to clean up entirely. In OnStop I do a partial cleanup. Every thing is still pretty much ready to go but with a reduced foot print and most thread processing has been halted. If you don't do things in OnStop which occurs on deactivation, then it can be just sitting there using up resources or spinning it's wheels. OnDeviceClose is not necessarily called right after deactivation.
 

Posted Thu 03 Dec 15 @ 8:06 pm
SBDJPRO Infinity Member since 2006
If OnDeviceClose() is called then your plugin may not be stopping, it may just be losing (and may immediately regain) it's 3D device. In that scenario it may well be wasteful to deallocate memory, stop threads, timers and other non-video resources only to restart them instantly.

If you really want OnStop() to be called during OnDeviceClose() then it's better that you call it yourself IMHO rather than it being imposed on everything.
 

Posted Thu 03 Dec 15 @ 9:44 pm
SBDJ wrote :
If OnDeviceClose() is called then your plugin may not be stopping, it may just be losing (and may immediately regain) it's 3D device. In that scenario it may well be wasteful to deallocate memory, stop threads, timers and other non-video resources only to restart them instantly.


It is a pretty rare case when OnDeviceInit is called right after OnDeviceClose but it does happen as in the case I described above. Problem is you don't know this is going to happen. You could time it but not really safe and rare anyway. Since it is a rare case, I guess you are arguing the point that you should be wasting resources most of the time rather conserving them because it might take 50ms to restart in some almost never happens scenario? And if you personally Scott are not free things up in OnStop or OnDeviceClose then when are you doing it? Maybe it is you don't allocate much but that is not relevant. I would think you would want to be doing background task though so as to not tie up drawing.

SBDJ wrote :
If you really want OnStop() to be called during OnDeviceClose() then it's better that you call it yourself IMHO rather than it being imposed on everything.


Never said I wanted OnStop to be called during OnDeviceClose but I effectively do that already. I said there should be some consistency to the whole thing and normally that means OnStop and OnStart are paired within OnDeviceInit and OnDeviceClose. So you get deactivated say. OnStop gets called. I do a partial shut down conserving resources. You may get reactivated again, ok ready to go. OnDeviceClose may never be called after deactivation if plugin stays selected until VDJ shuts down. Since I do properly shut down completely in OnDeviceClose, because it is the only place that makes sense, and when OnStop and OnStart is not called, I must catch it in OnDraw which is not a big deal and again rare. You would think you would want consistency to your API though.

Here is what it says in the SDK about OnDeviceInit and OnDeviceClose:

// called when DirectX is initialized and closed
// if you need to allocate private surfaces or textures,
// this is the place to do it
virtual HRESULT VDJ_API OnDeviceInit();
virtual HRESULT VDJ_API OnDeviceClose();

Says nothing about OnDeviceClose but the assumption has to be, if OnDeviceInit is the place to allocate surfaces or textures, then clearly OnDeviceClose is the place to free them... laughing as I write this.

Also I may never get the answer lol, but I have asked at least 7 or 8 times why you call OnStop and OnStart when user tries to deactivate the AOV. I know by now no answer usually means either there is no answer or the answer would be embarrassing. I can probably answer it for you now but think your answer would be interesting. This one I do time although only to cover it and not something I should need to do.
 

Posted Thu 03 Dec 15 @ 10:23 pm
SBDJPRO Infinity Member since 2006
Don Moir wrote :
It is a pretty rare case when OnDeviceInit is called right after OnDeviceClose but it does happen as in the case I described above. Problem is you don't know this is going to happen. You could time it but not really safe and rare anyway. Since it is a rare case, I guess you are arguing the point that you should be wasting resources most of the time rather conserving them because it might take 50ms to restart in some almost never happens scenario? And if you personally Scott are not free things up in OnStop or OnDeviceClose then when are you doing it? Maybe it is you don't allocate much but that is not relevant. I would think you would want to be doing background task though so as to not tie up drawing.


Well if the device is closed, then OnDraw isn't being called so you're not tied up drawing. You'll also have nothing to draw since you won't have a device. But a lot of plugins do things *other* than drawing, things that don't need to stop just because the device is unavailable. Or they may have things they don't want to stop just because the device isn't available at that moment. So calling OnStop() because the 3D device isn't available isn't logical.

SBDJ wrote :
I said there should be some consistency to the whole thing and normally that means OnStop and OnStart are paired within OnDeviceInit and OnDeviceClose.


But that's not what those are for. Those functions are not paired because it doesn't make sense to pair them. They serve different purposes.

Don Moir wrote :
So you get deactivated say. OnStop gets called. I do a partial shut down conserving resources. You may get reactivated again, ok ready to go. OnDeviceClose may never be called after deactivation if plugin stays selected until VDJ shuts down.


OnDeviceClose() is called after OnStop() if the plugin is selected when VDJ closes. I even just tested it to be sure.

Don Moir wrote :
and when OnStop and OnStart is not called, I must catch it in OnDraw which is not a big deal and again rare. You would think you would want consistency to your API though.


If OnStart() and OnStop() aren't being called then please provide us with a test scenario so we can replicate and fix that. I've never seen that myself.

Don Moir wrote :
Here is what it says in the SDK about OnDeviceInit and OnDeviceClose:

// called when DirectX is initialized and closed
// if you need to allocate private surfaces or textures,
// this is the place to do it
virtual HRESULT VDJ_API OnDeviceInit();
virtual HRESULT VDJ_API OnDeviceClose();

Says nothing about OnDeviceClose but the assumption has to be, if OnDeviceInit is the place to allocate surfaces or textures, then clearly OnDeviceClose is the place to free them... laughing as I write this.


// called when DirectX is initialized and closed
// if you need to allocate private surfaces or textures,
// this is the place to do it
virtual HRESULT VDJ_API OnDeviceInit();
virtual HRESULT VDJ_API OnDeviceClose();

I think you're clutching at straws there mate, it's quite clear. As I said before, yes, OnDeviceClose is the place to free your 3D resources. But say you're doing FFT, then you might not want to free that in OnDeviceClose().

Don Moir wrote :
Also I may never get the answer lol, but I have asked at least 7 or 8 times why you call OnStop and OnStart when user tries to deactivate the AOV. I know by now no answer usually means either there is no answer or the answer would be embarrassing. I can probably answer it for you now but think your answer would be interesting. This one I do time although only to cover it and not something I should need to do.


I leave it in to annoy you :p
 

Posted Fri 04 Dec 15 @ 12:11 am
Scott no bad feelings but is it just not worth it for me to spend any time with you.... Use your energies to answer the one thing that is a real problem rather than beating around the bush with ridiculous answers. One thing though, yes OnDraw is not called on deactivation but guess you missed the part about threads being shut down and you would not know that things are being decoded on the fly in the background of TM. But if all you do is simple drawing then yeah not so big a deal. And not so big a deal for me either way but I just see it as sloppy. I mentioned not a big deal in the beginning of the thread but you seem to be trying to make it one. If I was you I would be doing multi-threaded drawing and texture handling in the background for milkdrop but it appears you do that all in OnDraw which can tie things up. If you did manage this with threads etc. you might also want to be shutting things down in OnStop. Your responses come from a place that only takes into account very simple things, but yet, you are trying to act like an expect... geezes the computer business is bonkers with 'experts' these days that don't have a clue :) That is not a personal thing but it is a real thing. You see it everywhere if you have the eyes for it.

First post 3rd paragraph in this thread about OnStop / OnStart not called:

It is not too big a deal because I just catch it in OnDraw but seems there should be better consistency here.


Also you fail to realize once again, it is not about me. When you say you leave the thing in with AOV deactivation to annoy me that is just avoiding the answer once again. It is not me that is annoyed by it. Hell I use it for testing haha. It is your users that do not know why it happens. It also indicates sloppy VDJ behavior but that's ok too I guess. The annoying thing is you can't answer simple questions. It is not like brain science you know haha.

Now one would think rather than all this nonsense someone would respond to the one bad bug I reported here but heck that is not important :)

2nd post this thread:

1) videoForceFullscreen = 1
2) run any video effect
3) ctrl+alt+del and bring up task manager

4th post this thread

You may be right on that end Adion and was not too concerned about it and mostly just info. But the gray screen condition and end process to get out is probably something you want to take a look at. Can you reproduce that?

After step 3 above, the VDJ user interface is now entirely gray meaning drawing has stopped and only way out is end process. I asked Adion if he could repeat this. Happens here every time. I have not traced into it at all yet because that is your job and waiting for a response but all I got so far is BS.

I guess now though, I will get the fall back answer that "we don't recommend videoForceFullscreen = 1" That can mostly be that you are having a hard time with it and window mode can also be easier to deal with both internal and for user. VDJ7 always used hardware fullscreen and don't believe you can turn that off. It could be you could but most went with the default.

The thing is though that hardware full screen is better than window full screen. In most cases hardware full screen completely eliminates tearing and is faster than some window is. Now do you see this kind of thing tearing with just video playback? Not normally but seems you are always trying to avoid doing things based on a certain limited experience. I have been doing computer animation for a very long time and wish I had the time to bring that to the table but we used to spend endless hours about tearing and other side effects. Mostly you see tearing with horizontal movement but can happen with any animation. The thing with video and images that are animating is it can greatly reduce the appearance of tearing. Straight line objects such as text and non animating images moving horizontally are the worse. Your eyes and brain can automatically remove the tearing to a certain degree.

You have a flexible program and you have users that do all kinds of things and I trust you know that. Do you really want to create this flexible program so it only works well one way? I don't know how many responses I have gotten from some at Atomix that essentially says "well just don't do that" haha... have you created the '"don't that list yet". I mentioned that awhile back in some thread and just smiling. If it was not for smiling you might be crying. I am not your enemy at least not yet haha... I actually defend you when I can do that honestly. I also tell it like it is with hope things will get better.

Forget about whether you agree with me or not. Can you reproduce the problem and will you fix it or not? If you cannot reproduce the problem with just one simple test try again with some other computer. Every time here, no if's and's or but's. By the way you have task manager up at this point to shut VDJ down :)

I ran test with gray screen - end process for VDJ under Win7 with no aero.
 

Posted Fri 04 Dec 15 @ 1:10 am
SBDJPRO Infinity Member since 2006
I'm not sure why you think my answers are ridiculous, but I will abide your request and bow out.
 

Posted Fri 04 Dec 15 @ 1:55 am
Not so much ridiculous Scott, well intended I think, but I can just tell by your answers and the assumptions you make. It varies but 3 to 5 years is not enough time. One really good thing though is you appear to be hard working and that is a real plus.
 

Posted Fri 04 Dec 15 @ 2:19 am
AdionPRO InfinityCTOMember since 2006
OnStop/OnStart being called when you try to disable a audio only vis is just because it is currently treated no different from a normal plug in. So you can stop it, but later the video engine will find out that it is still required and re-enable it.
It would indeed be nicer if it didn't, but it's very low on the priority list since it hardly causes anyone trouble. (I haven't seen any sight of actual dj's being confused or bothered by this on the forum or support tickets)

I would still like to encourage to use OnDeviceClose/OnDeviceInit to clean up and recreate directx allocations, OnLoad/Release for other most other preparations, OnStart/OnStop just for starting/stopping work, and OnDraw limited as much as possible to only drawing.
If the user's system is capable of using your plugin with video enabled and OnDraw being called, then it shouldn't have much problem running it without OnDraw being called.
I can't think of any real scenario's where the user would start your video plugin, but then disable the video output just to save some system resources. (If he deliberately does that he could also stop your plugin)
In real-world scenario's, it is much more likely that OnDeviceInit is called shortly after OnDeviceClose, and in this case it is important to be able to resume as fast as possible, since like I said it could happen when a cable got accidentally disconnected or the video driver crashed.
 

Posted Fri 04 Dec 15 @ 4:52 am
Adion wrote :
OnStop/OnStart being called when you try to disable a audio only vis is just because it is currently treated no different from a normal plug in. So you can stop it, but later the video engine will find out that it is still required and re-enable it.
It would indeed be nicer if it didn't, but it's very low on the priority list since it hardly causes anyone trouble. (I haven't seen any sight of actual dj's being confused or bothered by this on the forum or support tickets)


Yes I agree low priority and had already figured the reason out. Nice to get an actual answer though. It took me quite a bit of time to figure out why for sure. I though it suspicious it had never been answered until now and was laughing to myself coming up with reasons why it might not have been answered. Hey entertainment is part of all this :)

Adion wrote :
I would still like to encourage to use OnDeviceClose/OnDeviceInit to clean up and recreate directx allocations


I never said anything different about that and think we totally agree but read on and would not even think otherwise. Of course textures and such are also allocated after OnDeviceInit as media changes in TM and for normal reasons. Always completely freed in OnDeviceClose though.

Adion wrote :
OnStart / OnStop just for starting/stopping work,


Correct. OnStop for me puts it into a dormant state. Nothing going on. Some threads are left open, but they have been put to sleep and ready to be restarted on next OnStart.

Now if you take the unusual pairing when OnDeviceClose/OnDeviceInit is called and OnStop / OnStart is not called as mentioned above and the title of this thread. It means I must do the OnStart in OnDraw since we both agree that OnDeviceClose is the place to clean up I am no longer started on next OnDraw. Of course not a big deal but was pointing out this is a hole in the implementation of the API in my opinion. So only thing we or I can do is move stuff to OnDraw which we want to reserve for fastest drawing. So we have things like 'is this the visualization' and 'do I need to start' in OnDraw. Neither is a big deal but sloppy nevertheless.

Adion wrote :
If the user's system is capable of using your plugin with video enabled and OnDraw being called, then it shouldn't have much problem running it without OnDraw being called.
I can't think of any real scenario's where the user would start your video plugin, but then disable the video output just to save some system resources. (If he deliberately does that he could also stop your plugin)
In real-world scenario's, it is much more likely that OnDeviceInit is called shortly after OnDeviceClose, and in this case it is important to be able to resume as fast as possible, since like I said it could happen when a cable got accidentally disconnected or the video driver crashed.


I don't know what you are referring to... I do know but what you are saying is not making sense. All that has been said so far is I do a partial shut down in OnStop and a complete shut down of resources in OnDeviceClose. But we already agreed above that resources should be freed in OnDeviceClose. Then you go on to say that OnDeviceInit is likely to be called right after OnDeviceClose in case a very rare thing happens like a cable got disconnected or the video driver crashed... haha hang on a sec, let me get my medication... So a cable has snapped or the video driver crashed and now I should worry about a 50ms startup time so I should not clean up in case hell freezes over lol... downing the medication... If a cable got disconnected or the video driver crashed you are looking at many seconds if not minutes to recover.

None of the above has been any problem with TM and I was pointing out some minor problems with the implementation of the API as I see it.

I wonder if the bug question will ever be answered ... more medication ahhhhh... Since it took about 8 attempts to get an answer for OnStop/OnStart for AOV, could be this bug may take 10 to 15 attempts or more :) I asked something very simple... Can you repeat it? That can be answered as Yes or No... Next question: are you going to fix it... Also Yes or No
 

Posted Fri 04 Dec 15 @ 6:31 am
AdionPRO InfinityCTOMember since 2006
Don Moir wrote :
Now if you take the unusual pairing when OnDeviceClose/OnDeviceInit is called and OnStop / OnStart is not called as mentioned above and the title of this thread. It means I must do the OnStart in OnDraw since we both agree that OnDeviceClose is the place to clean up I am no longer started on next OnDraw. Of course not a big deal but was pointing out this is a hole in the implementation of the API in my opinion. So only thing we or I can do is move stuff to OnDraw which we want to reserve for fastest drawing. So we have things like 'is this the visualization' and 'do I need to start' in OnDraw. Neither is a big deal but sloppy nevertheless.

I don't quite follow why you would do this starting in OnDraw, and not in OnDeviceInit.

Quote :
I don't know what you are referring to too... I do know but it is not making sense. All that has been said so far is I do a partial shut down in OnStop and a complete shut down of resources in OnDeviceClose. But we already agreed above that resources should be freed in OnDeviceClose. Then you go on to say that OnDeviceInit is likely to be called right after OnDeviceClose in case a very rare thing happens like a cable got disconnect or the video driver crashed... haha hang on a sec, let me get my medication... So a cable has snapped or the video driver crashed and now I should worry about a 50ms startup time so I should not clean up in case hell freezes over lol... Downing the medication...

Tell me then in which more likely scenario OnDeviceInit is not called?
Of course it's something that you prefer not to happen, but bad cables are not that uncommon, and driver crashes aren't either. (Just after the release of windows 10 it looked like driver manufacturers had to catch up on the drivers, so I had gpu driver crashes at least a few times a day)

Quote :
I wonder if the bug question will ever be answered ... more medication ahhhhh... Since it took about 8 attempts to get an answer for OnStop/OnStart for AOV, could be this bug may take 10 to 15 attempts or more :) I asked something very simple... Can you repeat it? That can be answered as Yes or No... Next question: are you going to fix it... Also Yes or No

I didn't try yet, so I don't know yet if I can reproduce or fix it :p
 

Posted Fri 04 Dec 15 @ 6:58 am
Also another point about cameras and OnStop while we are at it. When a user deactivates a plugin, that user expects that the plugin is deactivated by rational standards. Now ok to keep things ready for the most part but for the camera in TM I go ahead and close the camera. Why? Because the user has deactivated the plugin and this means by reasonable standards the camera should open in any other application. The startup of a camera in TM is done in a separate thread and so it does not impact drawing. Now take the native camera effect. It leaves the camera open when deactivated. I think it still does anyway. Do you not think this is yet another confusion issue? Hey Don, my camera won't open in TM why is that? Did you open it in native camera? Yes but I deactivated it. Does not matter, VDJ keeps it open... Best way... never open it again in native camera haha... not all together kidding though and just easier than trying to explain it. Also did you read the thread about visualizations somewhere where I pointed out how when native camera is used as the AOV it can become a dead AOV? Sorry I have lost track of where that is.

Also why are worrying about some rare thing like a video cable cable coming lose? Native camera does not know what to do when you unplug its camera. Easy crash or hang if you play with for a a minute or two. Cameras are something that are much more likely to be plugged in or switched out and handled perfectly in TM.
 

Posted Fri 04 Dec 15 @ 7:24 am
Adion wrote :
I don't quite follow why you would do this starting in OnDraw, and not in OnDeviceInit.


I think we already agree that OnDeviceInit / OnDeviceClose is essentially for some D3D initialization and shut down. I think we also agreed that OnStart and OnStop is for starting and stopping. A lot of the time OnDeviceInit is called and then multiple OnStart and OnStop calls can be made without OnDeviceClose being called and this is fine and expected behavior. So the common thing is to use OnStart and OnStop well for starting and stopping... Now for all practical reasons, OnStart can always be assumed to be called after OnDeviceInit is called or the intention is OnStart is implied by OnDeviceInit. But from an outsider looking in I have no real idea what you might do. So safe bet is to use OnStart for the actual starting. But when not called you must catch it in OnDraw. What you should do though is create some formal documentation that explains this behavior in detail. That way it is cut in stone and a new user trying to develop a plugin will know what to do rather than guess work. I have already had to guess what VDJFLAG_VISUALISATION is because it is not well documented. It does 2 things and one you may or may not even know about. It says in doc: "The effect generates visuals, rather than applying an effect on given images" That makes sense but it does not really define the behavior. Pop quiz. Do you know what behaviors it has? I know 2 things it does. I still do not know what VDJFLAG_VIDEO_MASTERONLY does and no behavior documented for it. Not some thing I dwell on because I have more things to do then mess with undocumented behavior. You might also want to document the audio only visualization behavior... no never mind... It is too confusing to even explain :)

Adion wrote :
Tell me then in which more likely scenario OnDeviceInit is not called?


Not so much that it is not called, but it is not defined as an OnStart operation. It's your doc change it so things are clear.

Adion wrote :
Of course it's something that you prefer not to happen, but bad cables are not that uncommon, and driver crashes aren't either. (Just after the release of windows 10 it looked like driver manufacturers had to catch up on the drivers, so I had gpu driver crashes at least a few times a day)


I wonder did it take you more than 100ms to get started back up? I bet it took minutes or more with some cussin and screaming. Because 50 to 100 milli-seconds is a very short time to go from dead stop to startup. In TM startup is very quick. That is because much of the opening of files and allocation is independent of OnDraw calls and done in other threads. Cameras can take longer but many of the more modern ones start up quick and that is independent for me anyway and does not effect OnDraw. Everything goes from dead stop to startup anyway all the time depending on user action. Not all the time but you know what I mean. Optimizations are always important. I quite often say if you don't do optimizations then programming is much easier and part of the reason there is so much junk today. Optimizations are something that are normally continuously evolving unless maybe you are a modern day programmer.

Adion wrote :
I didn't try yet, so I don't know yet if I can reproduce or fix it :p


Fair enough. Takes about 20 to 30 seconds to try and reproduce.
 

Posted Fri 04 Dec 15 @ 8:03 am
DHoudePRO InfinityMember since 2009
All issues aside, he may be onto something that I am seeing also. I am using Resolume, Spouted into VDJ (Spout Receiver). We are testing a re write of the Spout Receiver plugin, which runs as AOV.

In short, I actually crashed Resolume tonight. I had an 8.5 hr Automix set and near the end I mixed in some video music videos. The Resolume crash happened as a Music Video loaded and the Spout Receiver plug in, I assume had an OnStop message. Possibly removing the Spout output in Resolume. Which it probably did not like and assume crashed it.

I have all the screen shots, history and the event log if needed. But I think it is very relevant to this situation.
 

Posted Fri 04 Dec 15 @ 9:11 am
AdionPRO InfinityCTOMember since 2006
Don Moir wrote :
Adion wrote :
I don't quite follow why you would do this starting in OnDraw, and not in OnDeviceInit.


I think we already agree that OnDeviceInit / OnDeviceClose is essentially for some D3D initialization and shut down. I think we also agreed that OnStart and OnStop is for starting and stopping. A lot of the time OnDeviceInit is called and then multiple OnStart and OnStop calls can be made without OnDeviceClose being called and this is fine and expected behavior. So the common thing is to use OnStart and OnStop well for starting and stopping... Now for all practical reasons, OnStart can always be assumed to be called after OnDeviceInit is called or the intention is OnStart is implied by OnDeviceInit. But from an outsider looking in I have no real idea what you might do. So safe bet is to use OnStart for the actual starting. But when not called you must catch it in OnDraw. What you should do though is create some formal documentation that explains this behavior in detail. That way it is cut in stone and a new user trying to develop a plugin will know what to do rather than guess work. I have already had to guess what VDJFLAG_VISUALISATION is because it is not well documented. It does 2 things and one you may or may not even know about. It says in doc: "The effect generates visuals, rather than applying an effect on given images" That makes sense but it does not really define the behavior. Pop quiz. Do you know what behaviors it has? I know 2 things it does. I still do not know what VDJFLAG_VIDEO_MASTERONLY does and no behavior documented for it. Not some thing I dwell on because I have more things to do then mess with undocumented behavior. You might also want to document the audio only visualization behavior... no never mind... It is too confusing to even explain :)

There is no guessing involved though. OnStart is not called because OnStop was not called.
Simply add a variable 'isStarted' or something, and put it to true in OnStart and to false in OnStop. Now you can do all the cleanup you want when the device closes, and do all the restarting again when the device initializes again and isStarted is true.
I don't know about the resource consumption vs initialization time of your plugins, so obviously it is up to you to decide if it's better to stop everything or not.

Quote :
I wonder did it take you more than 100ms to get started back up? I bet it took minutes or more with some cussin and screaming. Because 50 to 100 milli-seconds is a very short time to go from dead stop to startup.

A brief flash of the screen, less than 1 second before the desktop is back and windows shows the 'recovered gpu driver' message. Another second or so for vdj to re-initialize, so in total a few seconds without display.

About camera's, I agree that it is not the nicest way to keep it open, but most webcam's I've tried so far are ridiculously slow, taking several seconds to start up, and another few seconds to stabilize the brightness. If you want to be able to flash camera images on/off in a live performance this delay would be far too long, which is why we've chosen to keep the camera open.
 

Posted Fri 04 Dec 15 @ 11:18 am
Adion wrote :
Simply add a variable 'isStarted' or something, and put it to true in OnStart and to false in OnStop. Now you can do all the cleanup you want when the device closes, and do all the restarting again when the device initializes again and isStarted is true.
I don't know about the resource consumption vs initialization time of your plugins, so obviously it is up to you to decide if it's better to stop everything or not.


I would think it would be clear to you by now I already know these things and reason I yelled at Scott a little for stating the obvious which I feel bad about now. The initial post was mostly a heads up to you. If you were to do updated documentation it is also easier to document absolute consistency.

Adion wrote :
About camera's, I agree that it is not the nicest way to keep it open, but most webcam's I've tried so far are ridiculously slow, taking several seconds to start up, and another few seconds to stabilize the brightness. If you want to be able to flash camera images on/off in a live performance this delay would be far too long, which is why we've chosen to keep the camera open.


Logitech cameras seem to open quicker. The Microsoft cameras I had opened much slower. Some of these cameras are opening all kinds of things like image detection etc. and part of the reason some can be slow. Can't speak for professional quality cameras though. Maybe the camera interfaces should have and on off buttons but they remain active? Could be confusing though.

I don't know if people use native camera as the AOV but do you see how leaving it open can lead to failure of having a camera image for the AOV? It is more of an issue because of the current AOV implementation though.
 

Posted Fri 04 Dec 15 @ 4:17 pm
95%