As always, we would love to hear your feedback on every release! Reply here or create another thread.
Here’s the 11th Alpha release, Logic version 2.0.8!
What’s new?
Analyzer settings are saved and are used as defaults when adding another analyzer of the same type later.
Improved application stability - better error handling and reporting.
Instantaneous measurements - new design + better control (right-click menu)
Improvements
Re-write of timing markers - faster, simpler and easier to use + new keyboard shortcut and auto creation of pairs
More analytics data (based on user permission) to better understand real-world usage
Analog scope trigger UI improvements
Scope settings are persisted between captures
Fixes
I2C analyzer actually works now
Windows scrollbars were de-uglified
Protocol search query is properly persisted between tabs
Notes
There is a known bug that may cause crashes for MacOS users running captures for more than 30 seconds at a time. We’re having trouble reproducing this here in a debuggable way and the debug data isn’t great - if you see a hard crash of the app (the application just disappears), please let us know! Also please do send the crash reports when the app asks you on the following launch.
There are other known issues of course, but none as severe as this crash.
We should have that tackled in the next release. We also have just about wrapped up the fixes for supporting saving and loading large files (over 1 GB) which will also go out in the next release.
We hope to get the next release out in two weeks, which will focus on improving the pain points involved in I2C debugging. Suggestions welcome!
Hello
I like the improvements of the timing marker but I have a suggestion.
Wouldn’t it be better if you only click once on the “+” button and then you can set as many markers as you want instead of clicking on the “+” button over an over again?
To get out of this state (placing markers) you could use for example the Escape button.
Thanks for the feedback!
Interesting idea, when you add markers, do you usually add more than two?
We’re thinking of allowing you to add a pair and present the distance between them while you’re setting the 2nd marker. Would that be useful for you?
HI – I like the new timing markers. I can’t find the new mechanism to restrict protocol analysis to just within the markers (before it was on the gear menu for the protocol analyzer).
Mostly I use markers to measure the time difference (delta) between these two.
Your idea would be great!
But what is when the user does want to set a second single marker after the first and not a 2nd marker to present the distance between them?
You’d be able to do both, by selecting between two options - add a single marker or add a pair (we’ll make it simple to use, no worries ).
By the way, using the keyboard shortcut (Ctrl+T) you can easily add as many markers as you want.
Thanks again for the feedback, it’s really helpful!
Hi, I’ve noticed three bugs. I’m on a Mac, MacOS 10.14.6 (18G103), MacBook Pro (Retina, 15-inch, Mid 2015) on an external monitor (1080p) with a Logic Pro 16
The crash after 30s on MacOS, this only occurred on a fresh install, and was not repeatable on subsequent loads
I can’t place markers on exactly the right half of the waveform view, fixed on restart
The start button will get locked occasionally during looping mode, and will cancel eventually but never change, fixed on restart
I can semi-repeatedly replicated the crash, it appears to occur whenever the device is replugged at any point, then start is pressed with the default settings with the only adjustment being the analog channels being deselected. I’ve sent a few crash reports.
Edit: I’ve now been able to replicate this 5+ times
One of my frustrations with this version of Logic is that the analog and/or digital channels can not be made “thin” (i.e. taking up very little vertical space). Many times I want the most horizontal data so I span the Logic window horizontally across my 3 monitors. But I also want to see lots of other stuff on my computer at the same time, so I want Logic to take up as little vertical room as possible. But when I start to make the window shorter, instead of scaling (so that all enabled channels are always visible, no matter how short they have to get) it simply allows the very tall channels to scroll off the bottom of the window, so I can’t see them all at the same time! This is very frustrating.
At least with the older 1x Logic software the channels could be made pretty short, although they also scrolled off the bottom of the window if you made the window too short.
I’ll also put in another plug for having some way of seriously minimizing the width of the information on the right and left of the window. Once I have things set up, I don’t need to see the full channel names, or the huge “START” button. I want maximum horizontal space so I can see more of my waveform at once.
Keep at it - the progress in these recent 2.x Logic versions is fantastic. I’m very excited for the future of Saleae!
Brian,
You’re absolutely right. We’ll fix it and allow resizing the vertical height of each channel to ~50 pixels (compared to 100). It should be enough to squeeze most channels on screen.
The sidebar will receive a significant face lift in the next release and will be collapsible. It’s going to be a huge improvement for the way we use analyzers!
First, totally on top of the sidebar panel. Rani has already implemented the support for collapsing it as well as making it user resizable, which helps a ton for the protocol search results table. The new implementation looks a little bit like the sidebar in visual studio code and atom text editors, except ours is still on the right side of the app.
The organization of the sidebar has also been refactored to match the visual studio code style organization. analyzers, annotations, and device settings each get their own sidebar icon now.
What you’re seeing with the measurement over the simulated analog square wave is essentially a bug - the measurement algorithm doesn’t handle an ideal square wave where only two analog values are present. We’ll fix that by both improving the analog measurement and we’ll improve the analog simulation.
Perhaps we should make it easy to remove a timing marker by some kind of interaction with the marker itself - either a right-click menu or an “x” button that appears while holding the mouse over the marker.
We’ll be working mainly on improving the experience for digital captures and protocol analysis for the next few months, so we won’t actually improve the analog measurement or simulation for a while though.
What’s next:
Rani is about to start working on a “console” view of protocol analyzer results, which will basically allow the application to work as a serial terminal, which we’re really excited about. We also want to implement the feature that allows you to navigate to a protocol result by clicking an element in the protocol results list (a feature in our old software). We also want to support the reverse, and add a way to easily zoom in on a protocol bubble or region of bubbles on the graph just by clicking. It’s quite a pain to zoom in on a packet right now. We also want to add a feature to jump to the next or previous protocol result, which helps a lot when navigating between packets that are quite far apart. We also noticed some problems with the “multi-bubble” display which we’re going to improve.
I’m working on protocol analyzer performance next. Right now, if you record 1 second of 1 MHz SPI traffic, it will take forever just to get the results on the screen - it’s dramatically slower than the old software. This will probably take a while but should be ready for the next release, currently scheduled for mid next week.
Another strange bug - this is on Windows 10, 2.0.8. If I run 2.0.8 then close it, then try to run 1.2.29, I get “A Logic device was found, but there was a problem connecting to it. Another application may be using it. Please let us know if the issue persists.” If I close 1.2.29, unplug the replug the device, then try to start 1.2.29 again, I still get the same message. I need to reboot in order to use 1.2.29.
This would be a nice one to fix, as 2.0.8 isn’t usable for me yet, but I want to test it out to help you guys out, but switching back to 1.2.29 is kinda painful right now . . .
This is Odd… I wasn’t able to reproduce this over here on Windows 10 with a Logic Pro 8 device - I’m able to switch between versions and capture in both without error. I’m only running one version at a time of course.
Perhaps the alpha software isn’t exiting fully and is holding exclusive access to the device. Can you open the task manager, go to the details tab, and check for any instances of Logic.exe, after closing the alpha software? (When running, there are a handful of instances of Logic.exe, that’s just how Electron rolls).
While you’re in there check for java.exe and let me know if that’s running. I think on windows our application is failing to kill the elastic search application we use for indexing protocol search results, but that’s likely unrelated.
I’m really surprised that you still see the error after disconnecting and reconnecting the device. Could you send me the make and model of your PC or motherboard?
Mark - so yes, looking at TaskManager Processes tab, I actually have 4 “Logic” processes running (even though there are NO Logic windows currently open on my system) and one of them is taking up 30% of my CPU even! Wow. (In the Power Usage column of Task Manager, it says “Very high” even.) Nowhere in the Processes or Details tab is java.exe.
When I end the Logic task that was taking up so much CPU time, the other 3 went away too. I can now run 1.2.29 just fine, and after I exit that, I can run 2.0.8 just fine too. And now, exiting from 2.0.8 removes all Logic processes and I can run 1.2.29 just fine.
So it must have been the strange behavior I was seeing while running 2.0.8 (which caused me to want to bail and run 1.2.29 so I could continue working) that prevented the processes from exiting when I closed the window.
I’ll try to describe the problem I was having : I had my capture rate set at 20MS/s, all 16 digital channels on, no analog channels on. I sampled for maybe 20 seconds, then stopped. I zoomed way out to see where my interesting data was, then started zooming in to the place where I needed to look. As I zoomed, each vertical edge in the logic traces would get wide (white bar) and then ‘fill in’ with the data at the new zoom level. Until it didn’t - at a certain point, I’d zoom in and the white bar would just stay white - no filling in with new data (even though, at 20MS/s, there is plenty more data to show). I could zoom out, and back in, but at that particular zoom level it would not show any more data - just the white boxes. At that point I closed 2.0.8 and tried to use 1.2.29, and that’s when I ran into trouble. I rebooted, did some debugging in 1.2.29, then later on repeated the whole thing and got the same behavior a second time.
Sounds like the C++ back-end hung up. Normally if the back-end crashes, the entire app exits, and at the next launch, you should be asked to send an error report.
However, it’s clear that the back-end stopped responding to render requests. There is a bug in all current alpha releases where this can happen when trying to save a moderately large capture to disk (fixed internally, will be in the next alpha release). Did you save any captures before the hangup occured?
What happens is that the digital and analog channels try to re-render whatever data they have on hand while waiting for new render data from the C++ side. For Digital, this results in a very ugly effect on transitions, where the vertical line will grow or shrink while you’re zooming. I have a good idea how to fix it but it’s not on the high priority list yet.
If the back-end stops responding to render requests, then the last successful render request is still used and scaled to the new zoom level, which is why if you keep zooming in it just gets uglier and uglier.
Besides the file save/load issue, there are no situations we know of where the back-end could freeze up without crashing. If you can reproduce the issue let me know.
We also just found and fixed an issue with the back-end that would cause a crash during log file rotation. This was responsible for the crash on MacOS during captures due to exceptionally fast log file growth. We were able to fix the underlying issue. However, this issue usually results in a hard crash.
).
