You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Essentially, all messages from a single device and GroupedBy Register and save in their respective binary file. The name of the binary file current follows the convention <DeviceName__RegisterName.bin>.
e.g.:
One thing that came to mind is why use the <DeviceName> to <UserGivenName>.harp / <DeviceName>_<RegisterNumber>.bin at all. It seems that it just introduces an extra dependency that is not necessary. Maybe a more general name, like Register is better? @glopesdev
@bruno-f-cruz This makes it easier when searching for chunks of the same device across epoch folders, as what happens in the Aeon data formats. I want to keep pushing for this, as I think it is an important use case to keep compatibility for, even though it may not be used in 90% of cases.
I guess my question is whether it should be part of the spec or not. From the Python interface point of view it doesn't appear to add much. I wonder if we can find a way that the interface works as long as the pattern is '*_' or if there is an advantage of introducing this dependency and locking the spec to it. To be clear: I am not against folding it in, just wonder if we really need to add it!
Summary
One of the goals of the harp-ecossytem is to define data format and specifications to allow users to log their data in a stable and shareable format.
Current Implementations
At the Allen
The current implementation at the Allen follows the following pattern: https://allenneuraldynamics.github.io/Bonsai.AllenNeuralDynamics/articles/core-logging.html#harp-data
Essentially, all messages from a single device and GroupedBy Register and save in their respective binary file. The name of the binary file current follows the convention <DeviceName__RegisterName.bin>.
e.g.:
This has a few problems:
Possible solutions
-
<UserGivenName>.harp / <DeviceName>_<RegisterNumber>.bin
The text was updated successfully, but these errors were encountered: