Traktor Pro 3.8 still has flashing browser when you load tracks
Comments
-
I know this is not very helpful but i just have to say that you have a big f***ing collection. I started culling mine when i hit the 20K mark to prevent such extensive loading times. ^^
0 -
Is there a fast way to switch back and forth between collections if I separate it out into multiple collections?
0 -
Nothing elegant. Close Traktor, switch out the file 'collection.nml', start Traktor. You can also use the 'import collection' function, but i don't like it, personally, and it feels as if it takes even longer that way.
0 -
Can I use different collection file names? for example, popcollection.nml, latincollection.nml, dancecollection.nml etc.
0 -
Traktor only uses the one name for it's collection. Instead of giving each collection-file a name, place them inside a subfolder or zip-archive with a different name each.
Or you can give each collection file a different name, but after copying it to the Traktor folder you rename it to collection.nml.
0 -
Workarounds:
- Don't filter / search
- Don't sort playlist. Or if you need to sort a playlist, sort it, then do the thing where it saves the new order (Consolidate playlist or something like that?)
Yes, I know this might break a few workflows. But it is what we have available :(
Some also say that with Traktor
3.53.4 it's less.I though about renting an advertisement billboard that you can see from the NI office. So they have to be confronted by it every day, just like their users :)))) Probably quite expensive though.
3 -
3.4 was the last one with less flashing, not 3.5
2 -
I though about renting an advertisement billboard that you can see from the NI office. So they have to be confronted by it every day, just like their users :)))) Probably quite expensive though.
I will pay also. 🤘🙏👀
2 -
1) 400k tracks is way too much.... As suggested by others, splitting to smaller parts, if possible, would help.
2) Someone stated that if one ticks that fields in playlist are not editable speeds things a lot.
3) Your PC is way, way too weak even for smaller databases....
0 -
I was able to fix the flashing by turning off the inline editing, the search is slower in 3.90 than in 1.27 even with the same 400k collection but I can make it work since I prep all my dj sets in advance and have a written playlist I work from for each gig so I can load 4 tracks at a time and stay ahead.
If any knows any hacks to speed up the search with a large database that would be great.
Would creating a playlist in Traktor of the 100-200 songs I plan to play at a gig help lower that search time? How many playlists can be created? I never used playlists in 1.27
I didn't get a high end laptop because I won't be djing too much longer (1-2 yrs maybe) and I have other high end computers in my recording studio (where I spent most of my time these days)
0 -
Browser Flickering is now a dedicated item on the roadmap: https://community.native-instruments.com/discussion/5305/
With current speeds I estime it will be in a release around Q2 20024. I, for one, am exited.
0 -
Hey!
It is Q2 2024… so what's the deal?
I have been annoyed by this "feature" for over 2 years now. I believe you don't understand how serious this problem is. It is absolutely ridiculous that NI have not been cooperative for so many years. Are you kidding me?I NEED to tell you some important things about this issue:
1. It is not only a visual issue. While the screen is black during "one flicker" the browser UI is unresponsive.
As the flickering is random and (or course) not foreseeable what happens is: You start to interact with an element in the browser UI (e.g. start to drag / click on an element), a flicker occurs meanwhile. As a result your interaction had no impact on the UI and you have to do it again with no guarantee that it won't happen again.
Also: when using the hardware to navigate through your library (as I do of course) the browser UI is unresponsive during a flicker as well. The result is that browsing through your playlist via Browse Knob frequently SKIPS items if a flickering occurred during that operation. This is not only unpleasant. This is a severe impediment of your basic operation with the tool.2. As I am a professional SW developer myself I have to tell you that all of the excuses I have read here are completely unacceptable. I DO understand that probably this issue is a lot of work for the NI SW team as the code of the browser UI probably has to be restructured at many points. I assume that the code of the browser UI has kind of degenerated over years as new features and device compatibility had to be implemented. BUT: We're in the year 2024. If your UI has a behaviour like this it's implemented really badly! I mean… how in the world does a modern UI element achieve a behaviour like this? It seems like the whole browser UI element is reloaded in some way whenever an update from the DB is loaded / applied. This is BAD DESIGN. Each row element / entry of the browser should lazily load/receive their updates themself or at least NOT restart rendering the whole browser whenever an update occurs. Just display everything the way it is until the update is fully applied in the view model and the re-render each element that's affected. I really do NOT understand what's the problem here to avoid screen flickering as in most situations each element would simply have to update their few textfields or some icons. A UI should NEVER be unresponsive while a view model change is applied in the back! An update of re-rendering should never have such impact. The I/O should ALWAYS WORK correctly while both of these things happen. As I said… there is no excuse for this! If a device has low RAM or a weak CPU or a slow drive the proper result should be that updates are applied with a small delay after submitting a change AND NOT screen flickering.
I'll give you a brief comparison: You don't reload a whole page in your web browser just to apply a change at some point in a form. Do you? Even PHP is able to reload parts of the website independently.
Some keywords that may guide you to the right direction: Virtual Scroll, lazy loading, decoupling of view model and view, chaching optimizations.
Two simple words: Fix it!
And please let me know if you need any more information or help like videos but I guess there is enough footage out there already and I HOPE that you already figured out what's causing the issue by now. We're reasonably impacient!
If I have to accept this for any longer than half a year I'll start using other software and hardware. Because this one is not the only issue I am sick of. The whole browser needs a rework anyway. Look at the features that even open source software like Mixxx provides…
What about adding completely custom TAG fields?
What about highlighting in which playlists a track is already contained in while having it selected in the browser?
And they DON'T have screen flickering!2 -
IS it fixt wit 4.0?
0 -
yessss !!! had tested it already with my 50k Collection. No flickering anymore. its a wonder :-)
1 -
You see it is not bug, but behaviour.
I do wonder why the developers changed the behavior? Really makes you think.
Maybe the behavior was unwanted. What could be a good word for an unwanted behavior in a computer program? 🤔
1
Categories
- All Categories
- 18 Welcome
- 1.6K Hangout
- 66 NI News
- 864 Tech Talks
- 4.4K Native Access
- 17.2K Komplete
- 2.1K Komplete General
- 4.7K Komplete Kontrol
- 6.1K Kontakt
- 1.1K Reaktor
- 399 Battery 4
- 896 Guitar Rig & FX
- 457 Massive X & Synths
- 1.4K Other Software & Hardware
- 6.2K Maschine
- 7.9K Traktor
- 7.9K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators