-
Notifications
You must be signed in to change notification settings - Fork 5
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
protocol preset queue #30
Comments
I considered a protocol queue originally but decided against it for simplicity's sake. I also didn't want to confuse people in to thinking that the queue would run continuously (i.e. no gap in recording between protocols) because that's not currently possible. This is a fairly large change I probably won't be able to implement because I need to turn attention to Encore. However, it wouldn't be too hard to make a "Protocol Queue" module. Not as nice as an integrated solution, but it'd work... |
Okay, thanks for the info Mark. I'll look into doing it as a module. Could you point me to how I can access protocol presets from the module domain? |
You have access to all the "services" Symphony is built on in a Module (see https://cafarm.gitbooks.io/symphony/content/Write-a-Module.html#step-3-use-services ). Protocols presets are accessible through the AcquisitionService. Let me know if you make any progress on this. I was thinking about taking a stab at it for 2.4 after I finish some other things. |
Thanks for the info. I probably won't make further progress until SfN has passed. |
Just a heads up: I haven't found much interest in our lab for the protocol queue so it's gone on my backburner. I'm not likely to include anything with 2.4. |
We'd like our actions during the course of the experiment to be less tied to the durations of procol epoch sets, always waiting on the rig to pick the next protocol's parameters. Typically, I know the first several things I'm going to do to a cell, once I'm attached well. Some cells have 30 minutes of pre-determined protocol sets, and I don't need to watch all the results as they come in.
So I propose a new feature, which is an experiment session queue, in which protocols, with params encapsulated as presets, chosen from the list, are added and ordered and executed one after the other, in a visual queue GUI. The queue can be reordered and modified (drag and drop?).
The play/pause/stop controls are then moved to this queue window. The protocol browser, as it is now, is used to create and modify the presets. That is, its behavior is not connected to the run state. The buttons at the bottom of this are then "add as preset" "add to queue" "add to queue and as preset". The preset browser has buttons "add as next" "add as last", and context menus to "add as preset".
-sam
The text was updated successfully, but these errors were encountered: