It seems like the main view shows hex values with correct width but Data Table always shows 128 bit.
This makes less information visible (same goes for csv export).
Could be possibly be related to implementation of AnalyzerHelpers::GetNumberString() ?
In my TDM analyzer case (but seems to apply to built-in analyzers like I2S/PCM too):
AnalyzerHelpers::GetNumberString( frame.mData1, display_base, mSettings->mDataBitsPerSlot, number_str, 128 )
Also the Terminal view could maybe show hex values also when selected?
ch 1: \x10 \0
ch 2: \x01\x11!\0
ch 3: \x02\x12"\0
ch 4: \x03\x13#\0
ch 5: \x04\x14$\0
This is a limitation of our software, when showing FrameV2 data in the sidebar.
When displaying in Hex Mode, we render integer data with all leading zeros shown, due a design problem with the system. The system has no idea how many bits are relevent, and it needs to render every integer for that column the same way in order for our search indexing system to function properly. (There is a lot more going on under the hood there that I’m not explaining.) We would like to solve this by adding support for optional metadata to C++ LLAs using FrameV2, as well as HLAs, so the author can control the display of every data type with more detail.
With FrameV1 analyzers, the analyzer source code is responsible for generating the exact text shown in the data table, with the downside of there only being 1 column of results. That’s were GetNumberString is actually used. It’s not involved in the generation of FrameV2 data. If you look at the signature of GetNumberString, you can control the number of bits displayed, which when in Hex mode, will control the number of hex characters displayed.
If you don’t mind disabling HLA support, and you’re OK with only using 1 column, you can disable FrameV2 support in your analyzer. Details on FrameV2 support can be found here:
Simply un-do the changes for FrameV2 in order for the data table to revert back to FrameV1.
Another solution would be to use a byte array instead of a integer in your FrameV2s. This changes the HEX display to only show the bytes recorded. However the precise display of these bytes is more suited for an array than an integer, and I’m not sure how well that will display for audio samples. It’s worth checking though.
Thanks for replying. I thought it was a simple bug but then I will live with it (not using it much currently).
Another comment from a collegue was that Analyzer is very slow (he was using TDM but I guess it applys to all). I understand that to make it searchable you need to index all of the data.
If it was only to visualize the current data it would be more efficient if the analyzer only translated the visible data and updated when scrolling in either the Main view or the Data Table. Likely not a small change though.
@bli For dense data captures, indexing such that analyzer results can be available for search could take some time. You should still be able to perform other functions during this time, including exporting data. Upon completing a capture, can you confirm what kind of actions you wanted to immediately perform? If you can share your .sal capture file here as well, we can check this behavior on our end.
Upon completing a capture, can you confirm what kind of actions you wanted to immediately perform?
Often just scrolling and zooming out/in in the main view.
Capture is either stopped manually or I guess using a trigger.
I never searched a lot in the captured data and if I did I mostly searched in exported data (but this might not be typical usecase).
Maybe it is “just” that the current analyzer gives priority to the data visible in the main view (like the TDM channel data on the left side of my initial screenshot above). If user scrolls or zooms the analyzer should restart with the now visible data. After the visible data have been annotated by analyzer it can continue with the hidden data (like it does now).
The Data Table could also change to sync with the left of the main view after scrolling / zooming.
Beware browsing data without using search could be a rare usecase, I am not using this analyzer a lot.
As a workaround I will try to capture less of repeated data (e.g. start/stop quickly).
Sounds good. In case you wanted us to investigate the slow scrolling/zooming behavior during indexing, feel free to attach your capture file and TDM analyzer lib file and we can see if we can reproduce it here, at least to see if that behavior is expected, or isolated to your PC.
