7/10 Meeting Notes

[clewis7]

Just wanted to put some meeting notes from today. Feel free to edit/comment :D @kushalkolar @BalzaniEdoardo @gviejo

Notes

The current structure I have in my mind for how to structure the API is as follows:

1. The class that users will instantiate to create a visual. This class will house things like the fpl.Figure(), store models that are responsible for synchronizing along different axes (time, components, etc.), and other high-level relevant information.

The exact arguments that users will need to provide is still a little TBD I think. Would maybe look something like this:

class Visual:
    def __init__(
        self,
        shape: Tuple = (1,1),
        data: List(pynapple.TsdTensors),
        metadata: Optional[dict] = None
):
          
        # create fpl.Figure
        self.figure = fpl.Figure(shape=shape)
        # create store models
        self.time_store = pynaviz.TimeStore()
        self.component_store = pynaviz.ComponentStore()
        self.sync_store = pynaviz.SyncStore()
        # create store model components
        # subscribe store model components to appropriate stores
        # etc.

     def _create_model_components():
         """Uses the user provided data and metadata to create components to subscribe to stores"""
         pass

     def show():
         """Wraps the fpl.show() method to actually render the plot."""
        return self.figure.show()

2. The store models that will exist within each visual for synchronizing time, components, controllers, etc.

I think we can have a BaseStoreModel that all the other models can inherit from. Here is general outline of attributes and methods:

class BaseStoreModel:
     """
     Base class for all store models to inherit from.
     
     Attributes
     ----------
     subscribers: List[StoreModelComp]
          List of components subscribed in the store, can be a pynaviz.BaseVisual or pynaviz.UIElement
     """
     def __init__(self):
         # initialize empty list for subscribers to be added 
         self.subscribers = list()

     @property
     def subscribers() -> List[StoreModelComponents]:
         return self.subscribers 

     def subscribe(subscriber: StoreModelComponent):
         """Adds the subscriber to the list of subscribers and hooks up relevant events"""
         pass
    
     def unsubscribe():
         """Removes a subscriber from the list of subscribers and removed events"""
         # TODO: need to think about if a graphic is deleted how this triggers removing the visual from a store
         pass
     
     def _update(ev):
         """Receives an event, parses it, and calls update to components in the store"""
         for subscriber in self.subscribers:
             subscriber.update()

3. The StoreModelComponent that will make up the subscribers of the store models

class StoreModelComponent:

    def __init__(self,):
        # depending on the type of component (UI or BaseVisual) will determine the attributes
        pass

    def set_time():
        pass
   
    def set_component():
        pass 

TODO

After I lay out the structure as mentioned above I will work on implementing the line example we talked about today.

• 4 Subplots (2x2)
  • top two suplots large line data with associating pynapple tensor of the same framerate, LinearRegionSelector for both
  • two bottom suplots will have the zoomed-in version of the data given by the LinearRegionSelector
  • we want things to be synchronized in time as well as the cameras/controllers

[kushalkolar]

idea for when displaying timeseries lines that span the same time range, i.e. t_1 - t_2, but have a different sampling rate:

Setting the Graphic.world_object.world.scale_x is probably much easier than setting the camera. This will also help them both align on the axes tick text etc.

[kushalkolar]

StoreModelItem subclasses each have a class attribute with a set that defines the supported store models. So that if you try to register a StoreItem to a model that doesn't make sense it raises an exception, ex. trying to register SpatialConponentsVisual with a TimeStore instance doesn't make sense.

[kushalkolar]

Idea: I think you can use pause_events, when that's merged, in all store models when setting the state for all graphics.