Skip to content
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

Design overhaul #58

Open
5 tasks
Cody-G opened this issue Oct 9, 2017 · 0 comments
Open
5 tasks

Design overhaul #58

Cody-G opened this issue Oct 9, 2017 · 0 comments

Comments

@Cody-G
Copy link
Contributor

Cody-G commented Oct 9, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant