Custom Low level Analyzer parsing gets stuck at 50%

Logic 2 Software
1

Hi there,

I am trying to port TDM audio Custom Low level analyzer from Logic 1.x to 2.4.2
This analyzer works well with Logic 1.x . It sometimes works well on Logic 2.4.2 too. But sometimes, it’s gets stuck at 50% parsing. Any idea what’s going wrong ? I am not sure which VS version I had used while building for Logic 1.x. I am currently building with VS2017
I can reproduce this issue 100% times if I add the analyzer using automation APIs

image
image1775×382 25.2 KB

2

@rohit.walavalkar Sorry for the late reply! Our offices were closed for the holidays by the time your message came in.

It looks like your code is getting stuck in some kind of a loop. I don’t suspect it to be a build issue, however. Are you using the TDM analyzer below, or a different one?

Feel free to share your capture file (.sal format) with us and we can try and reproduce it here as a first step.

3

I am not using the one you pointed above. I am using a different analyzer we developed.
Anyway, I modified the TDMAnalyzer to extend Analyzer2 class instead of Analyzer.(As this source was being used for Logic 1.x) With this, the situation seems to have improved and it doesn’t get stuck at 50% percent anymore. However, I am noticing an issue pointed in this thread

Although, @markgarrison mentioned that “Steam to terminal” doesn’t impact the Analyzer performance, my observation is contrary to this. If I add the Analyzer manually and disable these options, Analyzer parsing is fast.

4

@rohit.walavalkar Glad to hear you’ve gotten around getting stuck at 50% processing.

For the above comment, while manually adding analyzers after a capture has completed:

  • Does enabling/disabling only “Steam to terminal” affect performance (while “show in protocol results table” is disabled)?
  • Does enabling/disabling only “Show in protocol results table” affect performance (while “Steam to terminal” is disabled)?
  • Can you describe the difference in performance noted in both situations above?
5

@timreyes

  1. If the “Stream to terminal” is enabled there is no impact on the performance.
  2. If the “Show in protocol results table” is enabled, It affects the performance
  3. Analyzer progress % starts out quick and slows down after about 40%. By this time the “Data” progress % starts appearing and both progress very slowly afterwards.Takes a lot of time to complete(~10 mins at least)
6

@rohit.walavalkar Thanks for confirming your observations on that. I’ll share these notes with the team here to see if we can come up with what might be causing this.

7

Thanks @timreyes . Keeping fingers crossed :slight_smile:

8

Hi @rohit.walavalkar,

Sorry for the trouble with this! This is very odd. The option to “show in protocol results table” disables table display for the analyzer, but it does not disable indexing. Usually we consider indexing where all the work is, because when there is no search query, the data table just displays the first few dozen results.

We do have controlling this in the feedback for the automation API, however we’re a tiny team (3 people on the software) and we’re currently neck deep in another project at the moment.

However, I suspect that if you don’t need the data table results, there might be a quick fix here.

First, if you’re not using the data table, you could stop producing data table results from the API, thus eliminating all that work.

If you’re using the new UseFrameV2() API, you will need to turn that back off and stop committing new FrameV2s.

Then, in your GenerateFrameTabularText method inside of your AnalyzerResults class, you can simply call ClearTabularText(); then return. This should prevent data table items from being produced, thus preventing them from being indexed later.

Note, if you’re exporting the data table from the automation, this won’t work anymore because there will be nothing to export. However if you’re using the legacy export function, that will still work as it calls your implementation if GenerateExportFile

Does that help?

Also I’d love try and reproduce the performance issues over here if you could share us a copy of your analyzer and sample capture.

9

Thanks @markgarrison
Sounds like a good work around. I will give this a try