NOTES and COMMENTS from DESIGN REVIEW Measurements Tab:
We need another button called "Get DSPR from DB" to load dispersion values from twiss parameters in the model DB, using Aida
BPM X and BPM Y rows in table should be selected individually by the user. They do not work together as a single 'device' here.
Matrix Tab
When chosen Measurement, Actuators, or States are changed, the matrix model object will update accordingly 'behind the scenes' by querying Aida again. How will this be done for a matrix that is loaded from file? (some additional design detail required here...)
Formatting the F and G matrices is somewhat complicated; the description in the document could be made clearer, and double-check the column and row labels of the Matrices to be sure they are correct. This should be done by Diane...
Include more details about how the MATLAB matrix file is read. Especially need to detail the expected format of the MATLAB file - so those who create the file (physicists) know how to make it.
Reference Orbit
Include a screen shot of the Ref. Orbit Collection Dialog. \
Could use a short description of why a reference orbit is needed by a feedback, just for the sake of clarity
Timing Patterns
We should have a specific design review for the timing pattern chooser module, in a few (couple?) weeks when Dayle is also ready to discuss it. We need to be sure we are not excluding other projects requirements for this module.
We should try to use the same kind of PVs to store INCL EXCL masks in our Controller IOC as other units. Let's see how it's done in EVR, Sheng's new PDU, how does Dayle plan to do it?...
It was decided to put the pattern data (<bit position, # of bits, name, category>) into EPICS PVs rather than in a file or RDB table. This way it will be directly available to IOCs as well as Apps. Mike has already moved the SLC PNBN database to a new soft IOC sioc-sys0-pn0.
Need to update the document and design to reflect reading pattern info from PVs rather than <file or database>
General Concepts, and some unrelated but important comments:
Will the Configuration App have an API and be callable from other Apps? It was generally agreed that the configuration app should not have a callable API.
The Activate Config button was much discussed. I think the consensus was it should not toggle to Start Feedback - we should let the user move to EDM to start the feedback. The button title itself should change, but I can't remember what the final conclusion was! Something long I think 'Activate Feedback on IOC'??? hopefully Partha remembers... or can make up something that will satisfy everyone. 
When a feedback is started the actuator FBCK PVs must be checked and verified that there is no other feedback already using the actuator. If there is, the feedback must stop (with message).
LCLS II - the description of Longitudinal feedback in this document seems to assume that there will only be ONE Longitudinal feedback. With LCLS II the Longitudinal feedback will be duplicated on a different time slot - be sure the design of longitudinal can accommodate that.