This is not a new issue with 2.3.23, but I noticed that it’s too easy to inadvertently create and delete sessions. The former is relatively innocuous—it’s easy to delete a spurious session. The second is a big deal, as it discards the data collected in that session.
I am working on a laptop with a touchpad (Linux/Fedora). I havent quite figured out how I trigger the first issue: ther must be some shortcut or action I inadvertently do to create new empty Sessions. As mentioned above, this is not a big problem—I just delete those that I don’t need.
The inadvertent deletion is more of a problem—it happens to me when I try to go back to earlier session, and accidentally click on the 'X" instead of on the rest of the tab which would select that session.
I suggest following the UI in the browsers like Firefox: the tabs not currently selected do NOT have the delete ('X") button; you can only delete the currently open tab…
@przemek.klosowski Thanks for letting us know about this. Accidentally deleting a tab would certainly cause headaches. I could see how you might unintentionally mouse over the “X” too.
I have a meeting with the team next week regarding some potential changes around tab management. One other user also noted something similar, whereas Ctrl+R starts a recording, while Ctrl+T creates a timing marker. Sometimes, a user might want to create a timing marker but might accidentally hit Ctrl+R instead, which would start a new recording and delete the previously captured data.
For our somewhat similar product (recording life sciences data) we have a single session which may capture multiple recordings. Users can mark and delete sections of the recording and they can create multiple documents, but as a general thing it is easy to add new data to a session and needs deliberate work to delete data.
Accustomed to the way we do something similar, sessions feel “heavy” and I often wish I could just concatenate data on to the end of the current session.
Under the hood most of our data is stored in a memory mapped disk buffer with some smarts around skipping around the data. There are interesting challenging in getting such a system to work well. It does provide almost automatic data recovery if the system crashes though which is a big win!
@P.Jaquiery Thanks for chiming in! I agree with your points. I’ve added these to our internal discussion list.
Having a robust recover system
Needing deliberate work to delete data
Can you elaborate a bit on the idea below and provide some context on your need for it? Also, would you prefer an option to concatenate two completely separate captures. Or, would you prefer to have brand new captures simply link themselves to the end of a current capture tab?
I often wish I could just concatenate data on to the end of the current session.
With our software a document is a collection of multiple recordings. A user will typically set up an experiment, record some data, make some changes, record more data, rinse and repeat. In a life sciences context that will often start out with calibration data that is used to calibrate later data, then collect a series of experimental data records making changes so some set of parameters for each recording.
That isn’t quite the use case for a logic analyzer, but the idea that a set of recordings is what comprises a session rather than a single recording/capture is still applicable.
Fundamentally I’m lazy so creating a new “session” tab for each capture is too much effort so I just use the same session window all the time until I have something I know I want to keep. But it’s really easy to click start in the wrong session or at the wrong time and wipe out data that may have been important.
So, what I’d like is to treat a session as a work session where I can make multiple captures concatenated together end to end with a “record break” between each capture. Each capture should by default show time relative to the trigger/start point for that capture, but being able to show time of day for the whole session would be a really useful option. In our software we can show time since the start of the first capture, but I don’t see much need for that with Logic.
Thanks for the thorough explanation! I may have to get all three added to our ideas page (in case these aren’t already posted). Before I do so, I’ll chat with the team here about these.
Having a robust recover system
Needing deliberate work to delete data
A fundamentally new approach to session management that better encompasses and improves data visualization for multiple captures made within a single test session
Feel free to add any comments to it, and feel free to add your votes in! We’ll track interest and need for the feature there in the meantime.
@P.Jaquiery with regards to your approach on session management, we’ve got some internal notes written up about it (just talked about it with the team). We don’t have the bandwidth to make any drastic changes to how we handle sessions. This would require a fairly large rework of the software, but your ideas on how sessions should be visualized was quite unique and helpful!
is cool, but I would be worried about the memory usage… a long/fast capture might use gigabytes of memory, so there should be a way to delete it for good.
Gmail has a good workflow: for a few seconds after a destructive operation it displays a popup with Undo. Even after the popup is gone, the deleted content is in the Trash folder for few weeks.
Maybe Logic could have a popup with two buttons:
UNDO
DELETE FOR REAL
and if you don’t click either of them the deleted data goes to the undelete buffer if you decide to implement it.
A fallback from that could be just CONFIRM DELETE (no undelete buffer)
but I would be worried about the memory usage… a long/fast capture might use gigabytes of memory
Captures can easily be GB in size. We could perhaps have a Preferences setting that allows the user to set the maximum memory usage limit that the Logic 2 software is allowed to use (separate from the capture buffer setting). Not sure if this would be the best solution, but it could be similar to how Windows users can limit the disk space that Windows Restore uses when automatically creating restore points.
In any case, I added your comment to the idea post. I think it brings up some great points.
The trick is to use a virtual memory system, blocks of real memory for “current” data, that are flushed out to disk as a background task when it’s not being actively used. There is a lot of interesting machinery under the hood to make that work well, but you get data recovery after abnormal termination almost for free.
It does provide almost automatic data recovery if the system crashes though which is a big win!