Jai Bhagat

> that way the link paths in the scripts are short. ok sure, that makes sense for the Rigbox documentation. I guess another question is do we want to have...

I agree that any approach needs better documentation. Regarding this: > Would there be a way to implement your suggested improvement without making the code more bulky? It would be...

what were Chris' tweaks to `exp.SignalsExp` and how did they improve performance? I gather one was having `srv.expServer` create the PTB Screen rather than `exp.SignalsExp`?

I can easily imagine a situation where a lab would want this. E.g., having different servers devoted to different experiment types, different types of subjects, different users, etc... It's not...

I don't know how you're classifying "[things] that users actually want." There are a bunch of issues related to both enhancements and small bug fixes that you or I (or...

Along these lines, I've been thinking about ways to do package/file re-organization so *Signals* can be completely standalone (e.g. moving some files from Rigbox +exp to *Signals* ?)

add tests for the `dat.paths` for paths as strings

How about a case in which an origin signal sometimes posts a struct that makes the dependent signal update, and sometimes posts something else? I don't think there is currently...

> In the past you have suggested we simply throw an error if the data type of a Signal changes (it would be a solution of sorts to this issue)....

do we definitely want to do this? I'm not against this, but gui layout toolbox serves us well currently, and this would require a lot of work and updating our...