Dj Pari M
I like to set my skin fps to 60 to keep things looking snappy..in latest build using fruit's skin..with values of 60 fps or slightly less than 60..there is a lag created on the jog when scratching...at 30 fps and values not far from 30(up and down)..it seems fine.also I'm not sure if the lag is present on all skins
发表时间 Tue 12 Oct 21 @ 5:05 am
Dj Pari M
i had to do a follow up here...because there is a problem here for me...
anything 56 fps and under(skin fps)...all is well
57 -60 fps(i do not really see the need for more than 60),weirdly enough scratching with the crossfader only gives a massive bug...normal baby scratches without use of the crossfader works fine at any fps
edit i got the cause of the problem..to construct a workaround to NOT have the search bar active when mixing so i could use keyboard shortcuts instead of typing...i added " & browser_scroll 0" to my crossfader script...
is this command done for now and why at 57+ fps???
this is truly weird lol
anything 56 fps and under(skin fps)...all is well
57 -60 fps(i do not really see the need for more than 60),weirdly enough scratching with the crossfader only gives a massive bug...normal baby scratches without use of the crossfader works fine at any fps
edit i got the cause of the problem..to construct a workaround to NOT have the search bar active when mixing so i could use keyboard shortcuts instead of typing...i added " & browser_scroll 0" to my crossfader script...
is this command done for now and why at 57+ fps???
this is truly weird lol
发表时间 Thu 17 Mar 22 @ 10:12 pm
PhantomDeejay
Is your graphics card up to the task ? (Depending on screen resolution of course)
Have you updated your graphics card drivers to their latest version ?
VirtualDJ is not exactly a "desktop" application when it comes to graphics.
Consider it more as a "light game"
Which means that your graphics card should be able to cope with that refresh rate at your current resolution with all things going around.
On my laptop I can go up to 165FPS (it's native screen refresh rate) without any issues. But then again my laptop has a really powerful GPU that's more than enough for this job.
On my desktop PC (which is older and has a decent GPU) I can go to 60FPS without any real issue, but not above that since I'm running a 4K display and the GPU starts to struggle above that.
Have you updated your graphics card drivers to their latest version ?
VirtualDJ is not exactly a "desktop" application when it comes to graphics.
Consider it more as a "light game"
Which means that your graphics card should be able to cope with that refresh rate at your current resolution with all things going around.
On my laptop I can go up to 165FPS (it's native screen refresh rate) without any issues. But then again my laptop has a really powerful GPU that's more than enough for this job.
On my desktop PC (which is older and has a decent GPU) I can go to 60FPS without any real issue, but not above that since I'm running a 4K display and the GPU starts to struggle above that.
发表时间 Thu 17 Mar 22 @ 10:21 pm
Dj Pari M
so u are saying that my gpu will be a factor for just the scrolling part of the mentioned script?
because the crossfader default mapping works fine at any fps...earlier builds work fine also..so i think it is the later builds and not my gpu...IMHO of course..
it will be good if any others can try to replicate the bug
because the crossfader default mapping works fine at any fps...earlier builds work fine also..so i think it is the later builds and not my gpu...IMHO of course..
it will be good if any others can try to replicate the bug
发表时间 Thu 17 Mar 22 @ 11:08 pm
PhantomDeejay
The action you put in the crossfader, does something, doesn't it ?
Now every time you move the crossfader from one end to another you may think that it's "one" action, but in fact the action you scripted gets executed around 100 times (or more) for that single movement (in fact as many times as your crossfader reports it's updated position).
Depending on the action and the load it produces on your system several things may not works exactly as expected.
There's no need to "set focus" of the browser on every step of the crossfader.
Imagine that a single "scratch pattern movement" would result telling VirtualDJ to use "browser_scroll 0" 500 times in less than 2 seconds.
Does that sound reasonable ?
For starters try this:
This script in theory should put some relief on your system since it checks first if "search" field is active.
However a proper solution would be to not execute a script hundreds or even thousands of times without being necessary. So, a proper solution would be to map a button (like maybe ESC) to do that job and train yourself to use that instead.
Maybe another solution would be to use "ONLOAD" key of your keyboard mapper to put that script.
Therefore each time you load a track the browser would switch "focus"
PS: Some controllers (older or cheap models) have simple MIDI crossfaders.
This means that they can report up to 128 steps while going from one end to another and therefore executing your action 128 times.
Newer or more expensive controllers usually offer 14bit MIDI crossfaders.
This means that in theory they can report up to 16384 steps from one end to another.
In reality they don't report that many steps. Their precision is 16384 steps, but they still report their position some hundreds times when going from one side to another.
Just FYI :)
Now every time you move the crossfader from one end to another you may think that it's "one" action, but in fact the action you scripted gets executed around 100 times (or more) for that single movement (in fact as many times as your crossfader reports it's updated position).
Depending on the action and the load it produces on your system several things may not works exactly as expected.
There's no need to "set focus" of the browser on every step of the crossfader.
Imagine that a single "scratch pattern movement" would result telling VirtualDJ to use "browser_scroll 0" 500 times in less than 2 seconds.
Does that sound reasonable ?
For starters try this:
crossfader & search ? browser_scroll +0 : nothing
This script in theory should put some relief on your system since it checks first if "search" field is active.
However a proper solution would be to not execute a script hundreds or even thousands of times without being necessary. So, a proper solution would be to map a button (like maybe ESC) to do that job and train yourself to use that instead.
Maybe another solution would be to use "ONLOAD" key of your keyboard mapper to put that script.
Therefore each time you load a track the browser would switch "focus"
PS: Some controllers (older or cheap models) have simple MIDI crossfaders.
This means that they can report up to 128 steps while going from one end to another and therefore executing your action 128 times.
Newer or more expensive controllers usually offer 14bit MIDI crossfaders.
This means that in theory they can report up to 16384 steps from one end to another.
In reality they don't report that many steps. Their precision is 16384 steps, but they still report their position some hundreds times when going from one side to another.
Just FYI :)
发表时间 Fri 18 Mar 22 @ 12:01 am
uvazhayl
I also have fps jumping, but only in version x64
I read that this is due to not supporting dx11 gpu
发表时间 Fri 18 Mar 22 @ 12:16 am
Don Moir
You really can't trust info from some that blame something else first rather than their own software. That is where you start. That's where I start and it is common sense to do that. They have no idea what the problem is yet. Blaming drivers and other things right off the bat is ridiculous. No one knows until it gets investigated which is something they generally avoid and that is a missed opportunity.
o - someone was saying their skin rate would jump from 60 to 80 and become jerky.
o - someone said this is a new problem and maybe centered on jog wheel and I think they were trying to fix a problem there.
o - some said the problems did not occur on 32 bit version.
Let's say your monitor has a 60hz refresh rate for this example. We want smoothness. We don't want tearing. Tearing happens when partial frames are sent to the display. It can be god awful. Jerky motion happens when you are not displaying at a consistent rate and this can happen for a few reasons. Back in the day it was pretty much impossible to control these 2 problems. It annoyed me for years. DirectX did have hardware full screen mode and that worked well. Hardware full screen is not a window taking up the entire screen. It is a special mode that takes over the monitor. When using it you can move windows over it but they will disappear. So while it made display smooth etc. it is not user friendly. When Window Vista came out they MS introduced the Desktop Window's Manager. In Vista and Win7 you can turn it on or off. It is always on in Win 8 and up. It basically takes over all your screens and uses the GPU. So it is kind of like all your screens have become like hardware full screen mode except everything behaves normal and is much more intuitive. DWM helps greatly to remove tearing and allows for much smoother behavior. Also as this has evolved GPUs and CPUs have become much better. My machine is several years old. It's a box with parts in it. I upgraded the CPU years ago and upgraded the GPU a couple years ago. It still sings but newer computers are going to be much better still. I can't even get tearing on my computer anymore. They did a great job getting rid of it. They make sure full frames are sent to the display. Jerky behavior can happen because the timing is off. Maybe it's your timing or maybe because DWM is trying to sync everything up or maybe your machine is overloaded. Maybe a combination of the 3. I have dozens of programs running most of the time and generally every thing is smooth for me. Occasional jerky when windows are poping up etc but mostly very good.
The GPUs generally have 3 display modes. 1) Immediate mode - this sends the image to the display and does not worry too much about sync. Could cause much tearing and jerky in the old days. No tearing on my machine these days using that mode. If let the machine go flat out in that mode I get about 1000 frames per second. Of course my 60 hz monitor can only display 60 frames per second. So frames are being thrown away but windows manages this very well indeed. 2) half rate mode - The GPU will sync at half the rate of the monitor refresh so it would be 30 fps for a 60 hz monitor. Half rate was only available in hardware full screen mode for DX9 and DX9EX. Would crash if you tried to use it in a window. In DX11 it is also available when used in a window. 3) full rate mode - displayed at the monitor refresh rate. Modes 2 and 3 are useful because the GPU handles all the syncing etc. All this is just coming of age in recent years. Before that it was not possible to get good smooth output except in special circumstances.
In VDJ the only fps that is smooth for me is 60 fps. It used to be that both the skin fps and video fps had to be 60 otherwise it would effect the smoothness. Now they can be different like skin can be 30 and video can be 60 and won't be effected. Like I said though no frame rate other than 60 is on time for me in VDJ. 50 gives me about 57/58. 45 gives me about 51. 30 gives me about 33. Well these odd numbers can cause jerky behavior. Frames will be lost etc. Now I don't offer arbitrary frames rates like in VDJ because it is not going to work for smoothness. Smoothness (and tearing) is most noticeable when things are scroll horizontally and vertically. Your not going to see it much in videos that just laying flat and don't move much. But for me everything is capable of moving around changing shape etc so smoothness comes into play for everything.
Now those off time fps rates in VDJ are not a problem with my video card or any driver. That is strictly the way they are managing it. In my own stuff I choose to use fps rates that are an even multiple of the real frame rate. Like for 60 good rates would be 10, 20, 30, and 60. But 25, 50, and 100 also work very well. That do to the very good management of all this in windows. All this can be very tricky to get right. You can do things that seem to make sense and it just doesn't work. I also offer recording and allow variable frame rates for that and that can be harder to manage but to me VDJ is far enough off to make things unsmooth. IT'S NOT THE DRIVER in this case. For me it's almost never the driver. I had 2 driver issues in that last several years. One was were one of the Intel GPU cards was reporting that it could do something when it could not. So it lied. I determined in this it was the driver quickly. I had to reach out to a person that had the problem. I gave him some software that checked it out completely. Now I was certain it was the driver. It is usually not easy to determine a driver problem. I don't know, not one knows without inverstigation. If anyone here tells you it's a driver problem run for the hills because they don't have a clue. I wanted more proof of this Intel problem. So I search a lot. Did not find much. On and off I would search. After about 6 months I started getting some clues and knew I was close. Then I found it. Hidden and not talked about. I found Intel admitting to it. I found the driver that fixed the problem. It was also hidden and never distributed. I had one other driver problem on Windows 7 and MS said they were not going to fix it. It was problem with the driver for DX11 on Windows 7. Well gee rather than just blame the driver I worked around it. That happens and you do it because end user just wants it to work.
Ok so this should be easy enough to test. I have a test program you can run that goes thru various frame rates on the fly. It goes thru about 6 or 7 frame rates changing about every 20 seconds. It can use DX9, DX9EX and DX11 in both 32 and 64 bit and works equally well in all cases here. It can use different ways for FPS too. I have not tried it on other machines so that also would help me know more. If all goes well it should help isolate the problem.
I will need to dress it up a little before I send it out so could be a week or so.
Send me an email with a meaningful title and I will see about sending it to you.
Oh the funny thing is now some people want an ALLOW_TEARING flag. For cases where you want a higher frame rate like in some games and where tearing is not so much an issue.
o - someone was saying their skin rate would jump from 60 to 80 and become jerky.
o - someone said this is a new problem and maybe centered on jog wheel and I think they were trying to fix a problem there.
o - some said the problems did not occur on 32 bit version.
Let's say your monitor has a 60hz refresh rate for this example. We want smoothness. We don't want tearing. Tearing happens when partial frames are sent to the display. It can be god awful. Jerky motion happens when you are not displaying at a consistent rate and this can happen for a few reasons. Back in the day it was pretty much impossible to control these 2 problems. It annoyed me for years. DirectX did have hardware full screen mode and that worked well. Hardware full screen is not a window taking up the entire screen. It is a special mode that takes over the monitor. When using it you can move windows over it but they will disappear. So while it made display smooth etc. it is not user friendly. When Window Vista came out they MS introduced the Desktop Window's Manager. In Vista and Win7 you can turn it on or off. It is always on in Win 8 and up. It basically takes over all your screens and uses the GPU. So it is kind of like all your screens have become like hardware full screen mode except everything behaves normal and is much more intuitive. DWM helps greatly to remove tearing and allows for much smoother behavior. Also as this has evolved GPUs and CPUs have become much better. My machine is several years old. It's a box with parts in it. I upgraded the CPU years ago and upgraded the GPU a couple years ago. It still sings but newer computers are going to be much better still. I can't even get tearing on my computer anymore. They did a great job getting rid of it. They make sure full frames are sent to the display. Jerky behavior can happen because the timing is off. Maybe it's your timing or maybe because DWM is trying to sync everything up or maybe your machine is overloaded. Maybe a combination of the 3. I have dozens of programs running most of the time and generally every thing is smooth for me. Occasional jerky when windows are poping up etc but mostly very good.
The GPUs generally have 3 display modes. 1) Immediate mode - this sends the image to the display and does not worry too much about sync. Could cause much tearing and jerky in the old days. No tearing on my machine these days using that mode. If let the machine go flat out in that mode I get about 1000 frames per second. Of course my 60 hz monitor can only display 60 frames per second. So frames are being thrown away but windows manages this very well indeed. 2) half rate mode - The GPU will sync at half the rate of the monitor refresh so it would be 30 fps for a 60 hz monitor. Half rate was only available in hardware full screen mode for DX9 and DX9EX. Would crash if you tried to use it in a window. In DX11 it is also available when used in a window. 3) full rate mode - displayed at the monitor refresh rate. Modes 2 and 3 are useful because the GPU handles all the syncing etc. All this is just coming of age in recent years. Before that it was not possible to get good smooth output except in special circumstances.
In VDJ the only fps that is smooth for me is 60 fps. It used to be that both the skin fps and video fps had to be 60 otherwise it would effect the smoothness. Now they can be different like skin can be 30 and video can be 60 and won't be effected. Like I said though no frame rate other than 60 is on time for me in VDJ. 50 gives me about 57/58. 45 gives me about 51. 30 gives me about 33. Well these odd numbers can cause jerky behavior. Frames will be lost etc. Now I don't offer arbitrary frames rates like in VDJ because it is not going to work for smoothness. Smoothness (and tearing) is most noticeable when things are scroll horizontally and vertically. Your not going to see it much in videos that just laying flat and don't move much. But for me everything is capable of moving around changing shape etc so smoothness comes into play for everything.
Now those off time fps rates in VDJ are not a problem with my video card or any driver. That is strictly the way they are managing it. In my own stuff I choose to use fps rates that are an even multiple of the real frame rate. Like for 60 good rates would be 10, 20, 30, and 60. But 25, 50, and 100 also work very well. That do to the very good management of all this in windows. All this can be very tricky to get right. You can do things that seem to make sense and it just doesn't work. I also offer recording and allow variable frame rates for that and that can be harder to manage but to me VDJ is far enough off to make things unsmooth. IT'S NOT THE DRIVER in this case. For me it's almost never the driver. I had 2 driver issues in that last several years. One was were one of the Intel GPU cards was reporting that it could do something when it could not. So it lied. I determined in this it was the driver quickly. I had to reach out to a person that had the problem. I gave him some software that checked it out completely. Now I was certain it was the driver. It is usually not easy to determine a driver problem. I don't know, not one knows without inverstigation. If anyone here tells you it's a driver problem run for the hills because they don't have a clue. I wanted more proof of this Intel problem. So I search a lot. Did not find much. On and off I would search. After about 6 months I started getting some clues and knew I was close. Then I found it. Hidden and not talked about. I found Intel admitting to it. I found the driver that fixed the problem. It was also hidden and never distributed. I had one other driver problem on Windows 7 and MS said they were not going to fix it. It was problem with the driver for DX11 on Windows 7. Well gee rather than just blame the driver I worked around it. That happens and you do it because end user just wants it to work.
Ok so this should be easy enough to test. I have a test program you can run that goes thru various frame rates on the fly. It goes thru about 6 or 7 frame rates changing about every 20 seconds. It can use DX9, DX9EX and DX11 in both 32 and 64 bit and works equally well in all cases here. It can use different ways for FPS too. I have not tried it on other machines so that also would help me know more. If all goes well it should help isolate the problem.
I will need to dress it up a little before I send it out so could be a week or so.
Send me an email with a meaningful title and I will see about sending it to you.
Oh the funny thing is now some people want an ALLOW_TEARING flag. For cases where you want a higher frame rate like in some games and where tearing is not so much an issue.
发表时间 Fri 18 Mar 22 @ 9:32 pm