I think it's become clear that the current design makes some things harder than they should be. Here I'll keep a list of ideas for a (breaking) overhaul of the package coming within the next month or two:
[ ] Endow ImagineSignals with traits to allow dispatch. Traits include analog/digital, input/output, is_camera, is_laser, is_positioner. Currently the only one that we support is input/output via the single type parameter of ImagineSignal, and it's not as explicit as I would like, relying on the fact that output signals have compressed sample sequences and input signals do not. I'm not sure of the best way to do this. One way is to add a new type parameter for each of the new traits, but that seems a bit verbose. I'll look into using one of the packages offering Traits, or else decide on a clever way to reduce the number of type parameters (may interact with the next point)
[ ] Maybe add one more field (and type parameter?) to the ImagineSignal type that stores more information about the hardware (like camera settings for example). This new entry would hold either a properties dictionary or an instance of a type that I haven't designed yet.
[ ] Currently we rely on elaborate dictionaries to represent channel info for each rig. Instead design a Rig type with an interface for extracting these values. Each rig file then instantiates a Rig. Likewise we could also do this with new CMOSCamera, VolPiezo, and laser types, and split them into their own files. All of the new types and interfaces could actually go into another package, ImagineRigs.
[ ] Better incorporate camera ROI settings into our analysis and validation of command signals.
[ ] Reduce complexity and increase modularity of code that generates sample sequences. May split into another package.
The first 3 points above are very much related, just need to decide on the simplest design change that addresses them together.
I think it's become clear that the current design makes some things harder than they should be. Here I'll keep a list of ideas for a (breaking) overhaul of the package coming
within the next month or two:ImagineSignal, and it's not as explicit as I would like, relying on the fact that output signals have compressed sample sequences and input signals do not. I'm not sure of the best way to do this. One way is to add a new type parameter for each of the new traits, but that seems a bit verbose. I'll look into using one of the packages offering Traits, or else decide on a clever way to reduce the number of type parameters (may interact with the next point)Rigtype with an interface for extracting these values. Each rig file then instantiates aRig. Likewise we could also do this with newCMOSCamera,VolPiezo, and laser types, and split them into their own files. All of the new types and interfaces could actually go into another package,ImagineRigs.The first 3 points above are very much related, just need to decide on the simplest design change that addresses them together.