-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[REQ] EventMessage class for generic events #64
Comments
SampleTriggerMessage was pretty purpose-made for that and only that unit, but I'm very on board with making a base-event class. ez.Flag is also an Could possibly support some number of base-classes? Current ezmsg-event
To bring this into ezmsg.util, I could see making it much more general. Existing The |
At the moment, most of my |
Currently ezmsg-sigproc has
SampleTriggerMessage
.I think we need something different to represent signal events, especially signal spikes like neural firing, heart beats, etc. The reason I don't like
SampleTriggerMessage
is because it has a pair of floats that are optional, and it has avalue
payload that can be anything (incl. None), thus it is difficult / slow to convert many instances of this struct to e.g. a sparse array.I haven't put too much thought into it, but I'm thinking something like the following:
When a graph has a source that generates events like this, the next step might be a node to accumulate a bunch of events in a given window and convert it to a sparse matrix (e.g., scipy.sparse.csr) with a given sampling rate. Then, assuming we have nodes compatible with sparse matrices, we can convolve with some kernel to get event rate.
As support for event processing develops, I think there will be some mix of making ezmsg-sigproc nodes compatible with sparse matrices, and making custom nodes.
I guess my first question for the team is where do we want to define
EventMessage
? Here? ezmsg-sigproc? Or a new package calledezmsg-event
that will contain other utilities for dealing with events and sparse matrices?My only objection to putting the message structure in
ezmsg-event
is that data source modules that can provide events (e.g., ezmsg-blackrock) shouldn't have scipy as a transient dependency.The text was updated successfully, but these errors were encountered: