We are doing some product work on triggering and I was curious to know use cases for snapping the view to center of a trigger when that trigger is used to stop a capture. Are there use cases where you would not want it to snap to the trigger, if so why?
Thanks!
Snapping to the trigger point could be a default, but the general use case would be to snap to an offset from the trigger point.
The trigger could be the start of a sequence of operations that lead to an interesting feature, or the result of an earlier event that leads to the trigger event.
Providing a +/- offset value would cover these cases. Along with that capability would be recording data to include the offset value.
Is the trigger going to become something more complex than an edge on one signal, such as A*(B + /C)*EDGE(D) ???
Thanks for that use case. That makes sense. When you mention saving the offset would a visual indication work or is a capture setting suffice?
For the more complex triggering case, I’m wondering a few things:
How often do you need that type of complex trigger?
Would being able to use a python extension to create a complex trigger work for you?
It would be cool to know if you have a specific example that would lead to that complex trigger.
Thanks!
I vote for the Python extension option to handle complex trigger cases, especially if data from multiple inputs are available. Perfect would be having analog channels, digital channels and output data from other HLAs available to the trigger calculation.
Of course that mean near real time triggering won’t be available for some trigger configurations, but most of the time that isn’t a big problem.
It would also be nice to use the same technology to generate events used to navigate around a recording to that each place a trigger condition happened in a recording can be skipped to as edges in a channel can be skipped to.
Because of the speeds involved, I would expect that “advanced” trigger feature to be implemented in the FPGA in the Logic Pro.
Python could be used on a post-processed data capture that roughly found the trigger event, then with the python, home in on the particular portion of the data of interest for analysis.
I’ve used test code to generate the situation that a complex trigger expression would capture in the wild.
You don’t always have the option to change the code.
Thanks!
Thanks @P.Jaquiery and @chris.arena for your feedback. This is really helpful.
Neel,
In that “pseudo” expression, the operators were boolean, not arithmetic!
Thanks!