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?
Alpha 11
1 Like
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
Here’s a video of the latter two bugs: https://youtu.be/szLkp1FrM7w
1 Like
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
Thanks a lot for the feedback!
We’re going to hunt down this bug
In regards to the timing markers - was it a one time thing or is it reproducible?
I have not been able to reproduce the timing marker bug sonce it happened.
1 Like
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!
1 Like
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!
Thanks a lot for the feedback. Keep at it 
Alpha 11 started fine on macOS 10.15 Catalina, after the now-normal multiple security warnings.
[Solved] How to remove a timing marker? The + is very engaging. After a while, I found the x on the right pane to remove it.
I played with the demo trace. Hovering the cursor on Channel 0 provides many measures. But not on Channel 1. Is there a reason?
The right pane takes a huge chunk on the screen real estate. Could it be possible to make it collapsable?
I hope to perform a real life test with some I²C device.
Thanks again for the feedback, this helps a lot!
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.
1 Like
Thanks for the answers and good luck with the development!
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.
I have an ASRock Z270 Gaming K4 motherboard.
Thanks for the details Brian.
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.
Marc, no, I didn’t do any saving of captures. I was running the I2C analyzer though.
I’ll do more testing to see if I can reproduce it on my system.
Hi Brian,
how long do you usually record for? If you had to guess, how many I2C bytes do you think you record in the typical recording?
We have some pretty serious performance problems with protocol analyzers in the Alpha, this release is a lot slower than the production software. I’m working on it right now.
In testing, it looks like the Analyzer performance problem affects other parts of the application too, like rendering.
I’d like to try replicating some of your capture details - capture length and number of bytes - to see if I can uncover what’s happening.
My near term goal is to get I2C to decode in real time - e.g. 400 KHz I2C with near 100% bus utilization.
Mark, thanks so much for working with me on this issue. In the case where I had the above mentioned problem, I had probably captured several thousand bytes of I2C (not a whole lot). The total capture was probably 30 seconds long.
I have been working for awhile this morning to reproduce the problem as described above, and of course I can’t. 
However, I had a different type of crash which left my system in the same state. Same setup as above, but after I clicked “Start”, the button changed to “Stop”, said something about calibration, and then nothing happened. No data was captured, and clicking “stop” didn’t do anything. I had to close the app (with the normal X ), but then I’m left with the same four Logic processes (no Java.exe) with one consuming 30% of my CPU, and unable to connect to my Logic hardware with either version of the Logic app.
I’m not sure how much that helps you, I guess it’s good that we have to work hard to make it crash? (Rather than crashing all the time on its own)
OK, it feels easier to get bad things to happen now that I’m getting good at it. I got the crash to happen on the first try!
So I just killed the four Logic processes from Task Manager, fired up 2.0.8, no analog, all 16 digitals, I2C analyzer on channel 0 (SCL) and channel 1 (SDA), 20 MS/s, 3.3V, click Start. I captured probably 15 seconds of data (which looked like it worked fine) then I clicked Stop, and the ‘back end’ seemed to hang up. UI is fully responsive but no matter what I do with zooming in and out, all I get is this tiny chunk of data, which doesn’t change size even as I zoom in and out with the mouse wheel.
Closing the Logic window then gives me the four zombie processes and no access to my Logic hardware until I kill them.