Traktor analysis lock issue

[djjatoro]

Hi. Another issue of great importance that I just observed.

The truth is that I had never noticed in Engine, much less in Traktor, that there was the possibility of blocking the analysis of the tracks. In Engine I understood it immediately, due to its low precision in the analysis, to prevent the system with a new analysis from destroying the one carried out by the other application. But, the case now is Traktor:
https://support.native-instruments.com/hc/es/articles/209576209-C%C3%B3mo-funciona-la-protecci%C3%B3n-de-Analisis-en-TRAKTOR-PRO-#:~:text=Abra%20el%20panel%20avanzado%20GRID,ilumina%20cuando%20se%20encuentra%20activa.
(Sorry, i didn´t found english link)

When LXC syncs/exports Traktor, it automatically, by default, locks analysis. Let’s see a screenshot of the playlist export from LXC to Traktor:

Logically, with the padlock symbol, when doing an analysis, the result remains the same.

However, if we right-click and disable parsing blocking, this is the output:

Changes can be seen in the Key column. There are apparently no changes in the other columns (not to be overlooked though, they are invisible), but BPM, for example, on the visible tracks does not change. I do not know if it has been or could affect something else in other tracks, such as the beatgrid and other fields.

This to me is, with all due respect, a huge mistake. For 3 reasons:

1. Users might miss that this lock exists, like I did at first, when trying to reanalyze with Traktor,
   and when they press analyze again (since it doesn’t notice that it’s blocked), they would think that the result of the analysis by Traktor is correct.
2. Traktor is the application that currently, in my opinion, has the highest analysis accuracy and we are removing this trust point.
3. Analogous to the export with Engine, I think a dropdown should appear to offer us the possibility to export with blocking or without it.

[Christiaan]

The reason it is locked is that it is assumed the beatgrid in LXC is the one you want to keep. So the beatgrid in LXC was either analyzed in LXC or maybe imported from RB or another app.

If you want to use the Traktor beatgrids, then you can change your workflow by either adding tracks to Traktor, analyzing and importing that into LXC. Or add tracks to LXC, do not analyze, export to Traktor and analyze there.

[djjatoro]

With all my respect. For the same reason, why don’t you let locked by default exporting to Engine?

[Christiaan]

For Traktor you have more analysis settings, you can choose to skip the beatgrid. For Engine there is no such option, so locking the grid is the only way we can make sure to keep the LXC grid in Engine.

[djjatoro]

@Christiaan

so locking the grid is the only way we can make sure to keep the LXC grid in Engine

Therefore, you are in tune with me and you are agreeing with me in my approach: either you remove the dropdown with the options “default”, “locked grid”…, in the export to Engine or add it in the export to Traktor.

In any case, and from my perspective or situation, it is impossible for me to change the workflow.

I know very well that I do not represent the community of DJs. How was I going to do it?
Perhaps I have the problem of understanding regarding the philosophy and approach of how music collections are maintained, both in LXC and in other applications. Humbly, I am an old school DJ, currently home DJ.

Still, I think my opinion here might honestly represent a small collective of DJs, especially some Engine users, but perhaps significant. Let me explain why it is impossible for me to change my workflow with LXC:

1. My equipment is made up of 2 Denon SC5000M units and I depend, yes or yes, on Engine.

2. Engine is the only application that is capable of creating a tree structure in the playlists, in such a way that when importing a folder it creates a replica of that folder structure with subfolders.

3. The Engine analysis algorithm, we cannot ignore that it is mediocre, disastrous. Therefore, I have to rely on an external application.

At this point, no further explanations would be needed to justify my operation ( impossible to change the workflow), since the starting system must necessarily be Engine and the destination system, obviously, too.

Even so, I will provide more information.

4. As I said before, having to rely on an application with more efficient analysis, I export to Traktor, to make a more precise analysis, and then re-import to LXC. Therefore, for me, Traktor’s default analysis lock is inconvenient.

5. Another issue of vital importance, which I do not know if I have reported in other posts, is that I have found an issue (¿bug?) in the export to Engine and it is the following:

If the database has not been created and analyzed before in Engine, when exporting to Engine the waveforms do not appear visually created, even though they are (internally in the db), in each of the tracks. This implies that they must be loaded, at least once, so that Engine recognizes them.
What is the point, therefore, of doing all this preparation work on the desktop of the computer, if then when you go to the unit it takes about 5-10 seconds for it to recognize the beatgrid the first time (even if it is the correct one created in Traktor ). It is a time that in the middle of a session, in addition to despair and nerves, can lead to error.
Please, I suggest you check this point.

These are other reasons why others users/Djs have to start first, yes or yes, in Engine (users of this system) if people want to use LXC like me, as a conversion tool and bridge between some applications and others, and not only as maintenance of the music collection.

[Christiaan]

So if I get this right, if the analysis lock is gone in Traktor then it would be okay?
I explained why the lock exists. I don’t remember if the lock also appears if there is no beatgrid (I suspect it always there). So if I change it that I remove the lock only if there is no beatgrid, then it would be okay for you.

Then it means you need to sync tracks to Traktor without a beatgrid. Since you don’t like the analysis Engine does, you can skip that step?

And even better would be to remove Engine completely. Why is it essential to create this folder tree structure?

[djjatoro]

Let’s see, I wouldn’t want to be the person it depended on to make these decisions.

I only expose my context and my difficulties.

If you ask me for my opinion, with all humility and based on my personal experience, it would be the following:

1. In the export to Traktor I would add a dropdown, as well as with Engine, to decide if I want to run the process with analysis lock or not.
2. I will never be able to do without Engine. Moreover, the grid will always be exported to Traktor (Or, is there an option or checkbox to not export the grid?). I don’t know if I didn’t explain myself well (It is very complicated for me, being Spanish and with little knowledge of the English language, to rely on the Google translator to explain these very technical issues) in the section where I tell:

@djjatoro

If the database has not been created and analyzed before in Engine, when exporting to Engine the waveforms do not appear visually created, even though they are (internally in the db), in each of the tracks. This implies that they must be loaded, at least once, so that Engine recognizes them.
What is the point, therefore, of doing all this preparation work on the desktop of the computer, if then when you go to the unit it takes about 5-10 seconds for it to recognize the beatgrid the first time (even if it is the correct one created in Traktor ). It is a time that in the middle of a session, in addition to despair and nerves, can lead to error.
Please, I suggest you check this point.

a) I need the Playlist structure because everything is much more organized (like a normal folder and file structure). It is the one that Denon has chosen from its version 2.0 and replaced the crates. You might wonder why I don’t use the browse folders option in Engine OS then. The answer is because from this navigation the tracks played are not marked in color.

On the other hand, let’s forget about the tree structure of playlists for a moment.
Isn’t it enough to know that when you export to the Engine, as I explain above in quotes, you need to analyze the tracks again, otherwise the load is slow? Try to reproduce it please.

Thanks.

[Christiaan]

You have to understand that I do check all these things and I do want it to be 100% perfect but Engine is not my software so sometimes we have to accept that things are the way they are.