"One deck to rule them all" or "loading decks so slow?!"
Posted: Sat Apr 11, 2009 18:40
I've had a search and haven't seen a solution, so I'm wondering if it's just me?..
This does happen on both laptop & desktop, although it is more noticeable on the laptop...
Basically switching to or loading decks causes the frame rate to slow, with the output screen flashing (as in vertical hold gone) with each new thumbnail that appears.
Looking at the processes with the SysInternals Process Monitor, viewiing thread details for Avenue, shows nvoglnt.dll taking quite a bit of cpu time.
This happens to be the Nvidia ICL Open GL driver, so is the rendering of thumbnails somehow GPU intensive?
If so, is there a technical explanation of why? or is it just down to thread priority?
I do understand code but I try not to write it.
I've got a 'temporary' workaround from having to switch decks - make a really big one that has all the clips I want to use. By big, I mean it has 150 columns...
This does take about 7 minutes to initialise (the memory usage is quite interesting, it starts about 23Mb and goes up to ~4/500Mb) and has of course fubar'ed using a keyboard to select clips, but it does let me use them all without interrupting the output, which is of course the most important thing.
Did have a bit of a problem with the bpm beat counter spazzing out and not being at all in sync, however strangely a remove/reinstall fixed that. The reinstall also fixed the fft input somehow which is really weird, but part of the reason for using the software in the first place.
So now I've got 450 clips over 3 layers, taking midi clock from a redsound micro through a nice new tascam 144, with audio feed through same & all clips DXV encoded.
Now I just have to set the bpm length of all those clips and should be ready for my first outing with R3 tomorrow for 12 hours...
This does happen on both laptop & desktop, although it is more noticeable on the laptop...
Basically switching to or loading decks causes the frame rate to slow, with the output screen flashing (as in vertical hold gone) with each new thumbnail that appears.
Looking at the processes with the SysInternals Process Monitor, viewiing thread details for Avenue, shows nvoglnt.dll taking quite a bit of cpu time.
This happens to be the Nvidia ICL Open GL driver, so is the rendering of thumbnails somehow GPU intensive?
If so, is there a technical explanation of why? or is it just down to thread priority?
I do understand code but I try not to write it.
I've got a 'temporary' workaround from having to switch decks - make a really big one that has all the clips I want to use. By big, I mean it has 150 columns...
This does take about 7 minutes to initialise (the memory usage is quite interesting, it starts about 23Mb and goes up to ~4/500Mb) and has of course fubar'ed using a keyboard to select clips, but it does let me use them all without interrupting the output, which is of course the most important thing.
Did have a bit of a problem with the bpm beat counter spazzing out and not being at all in sync, however strangely a remove/reinstall fixed that. The reinstall also fixed the fft input somehow which is really weird, but part of the reason for using the software in the first place.
So now I've got 450 clips over 3 layers, taking midi clock from a redsound micro through a nice new tascam 144, with audio feed through same & all clips DXV encoded.
Now I just have to set the bpm length of all those clips and should be ready for my first outing with R3 tomorrow for 12 hours...