It’s probably it. Take the img above. Suppose I edit it and cut the channel 2 graph (spi clock) with the little arrows indicating the clock phase and paste it right below where’s written Channel 2, in a way that the graph overlaps with the channel name box. That’s the issue.
Technically none of the above. It happens when I maximize it, close and open Logic again. Apparently it remembers that the last time it was maximized, and it tries to open itself the same way, there you have it.
Please improve the way decoded data is displayed. Once I zoom out, they fade really quickly.
the 2x 4x etc zoom setting of current release is not even affecting the vertical size of the data.
please use more height for a narrower, higher font, and/or alternating positions like this:
Thanks for the reminder (and sorry about the delay)
Please provide icons (.png) so I can make great shortcuts.
Also; the white squircle is not very neat for linux, probably nor mac , because of expectation of transparent background.
I’ll ask our designer. It shouldn’t be a problem.
Please improve the way decoded data is displayed.
You’re right, but unfortunately, we’re currently using our old analyzers and there isn’t much we can do with their output. However, we are working on the next version of analyzers (and high-level analyzers) and that problem should be solved as part of it. By the way, if you hover over a result, it’ll open a tooltip with the decoded data. I know that it’s not what you want, but maybe it’s still helpful
Sorry for the late response. Interesting idea.
I’m not a fan of this design tbh, we should (and we will ) come up with a better solution for that.
I’d love to learn more about your use case. When and why do you want to view the trace in a zoomed-out mode but still be able to read the protocol results data? Why is it better than using the sidebar table for example?
My searches are now for I2C Write , (all I can predict is the Write and address), hence, I search for it, but to discover & verify, it is of no use to zoom inn all the way onto the request address I searched for.
What is needed then, (when clicking on such search result) are the following bytes and ACS/NACS.
I hope you better understand the use case.
Searches are most likely to be for a place in time, not to review this one byte. The following bytes are often most important.
I may need to search for this address 20 times, because I wish to verify response one particular (of the 20 possible) command-bytes after the address.
Of course, this could be accomplished by being able to search for two consecutive bytes, but still, even then, the main focus would be the following (or preceding) data, not close inspection of those two bytes.
Sounds great, especially the high-level analyzer, even I do not know how easy&powerful it will be
You asked for a screenshot, here is a screenrecording of the current workflow.
Another idea I had that would simplify search would be to still show all data, but change background color of matched lines. https://youtu.be/qOwChelMptI
If we’ll do our job well, they will be easy&powerful
Thanks for sharing the screen recording, it’s really helpful!
We’d love to have more of this, as it gives us a better understanding of your workflow. We’ll start asking our users to share similar videos with us.