events getting dropped from the log file

[Scott]

Hello XBAT developers,

Do any of you have any idea as to why a detector would drop events
during its scan? I have a sound that is 45 seconds long, and when it
is scanned for events it is broken into consecutive 6 second chunks.
When I set a break point at the end of the compute code in the
detector, I can see how many events it found within each 6 second
window. If I compare this to what is actually stored in the log file,
I see that I am loosing a great number of these events:

Time number of events in this window number of events stored to
log file in this time frame
0-6 sec 115 22
6-12 sec 152 10
12-18 sec 154 3
18-24 sec 153 6
24-30 sec 151 8
30-36 sec 152 1
36-42 sec 79 8
42-45 sec 0 0

I did not include any code that would evaluate the events and delete
them. Additionally, when I run the code within each 6 second window
with the "Active" "On" option, I get the larger set of events
displayed on the screen, as opposed to the smaller number stored in
the log file. Any thoughts would be appreciated.

Thank you,

Scott Brandes

[Harold Figueroa]

Hello Scott,

I have not looked into this in much detail yet, but events are 'validated' before being stored in the log. It may be that this concept is not quite right as of yet, or adequate in your case. Look at 'validate_events.m', this is the function that can mark events as not-valid, and let us know what you find out.

Harold

[Scott Brandes]

Hello Harold,

Thanks for your reply.  I found no problem with your code; I just did not understand that events had to undergo a validation step and what validation was required.  Some of my events were not being validated for 2 reasons which were simple to fix:

1)  I did not realize that event(i).freq(1) and event(i).freq(2) had to be set in a min/max order.  I treated event(i).freq(1) as the starting freq of the call and event(i).freq(2) as the ending freq.  The events I was testing were nearly flat (and short in duration), so it was hard to tell that down-slope calls were not being validated. 

2)  If events had a band width of 1 pixel, I had set event(i).freq(1) the same value as event(i).freq(2).

Cheers,
Scott

[Harold Figueroa]

Hello again,

I am glad you resolved your problem. Clearly the problem was one of missing documentation. So to perhaps we make the most of the opportunity, here are some comments:

1. The choice for the event frequency store order reveals that often we are interested in the min and max frequency of an event. When they are sorted in the store these values are immediately accessible.

2. The current failure to handle flat events (in time or frequency comes from a desire to have the graphical representation of the event be easily and effectively editable in the typical time-frequency display. We currently think of events as rectangles.

3. We are considering the development of flat time events, these will be called 'markers' before they are logged, and 'cues' when they are ... but this is still in the future. We have not thought about perfectly flat events in frequency, I find it harder to think about cases where these might be useful, so any thoughts on this would be interesting.

Harold