adammorrissirrommada
commented
4 years ago I tried to run the simple gui demo and got an error:
It seems that it can't load the gui. I get this error when I try to open nsGui.mlapp:
Using Matlab 2019a.
Closed bartkrekelberg closed 4 years ago
adammorrissirrommada
commented
4 years ago I tried to run the simple gui demo and got an error:
It seems that it can't load the gui. I get this error when I try to open nsGui.mlapp:
Using Matlab 2019a.
bartkrekelberg
commented
4 years ago RTFM.
But given that you are likely not the last to not RTFM, pull and try again.
The error you were getting when opening the appdesigner is probably because the split function (in klab toolbox) is on your path and shadows an internal function that appdesigner uses. The eternal matlab namespace pollution problem. I've updated the klab split.m to avoid this problem.
To find this kind of problem you'd have to dbstop if all error and then back track out of the stack to find which function appdesigner is trying to call.
Bart Krekelberg, PhD
Professor, Rutgers University - Newark
Co-Director, Center for Molecular and Behavioral Neuroscience
Associate Director, Rutgers University Brain Imaging Center
197 University Avenue
Newark, NJ 07102
T: +1 551 285 9265
E: bart@rutgers.edu
W: vision.rutgers.edu
Skype: bartkrekelberg
From: Adam Morris notifications@github.com Sent: Monday, March 2, 2020 1:52 To: klabhub/neurostim-ptb neurostim-ptb@noreply.github.com Cc: Bart Krekelberg bart@vision.rutgers.edu; Author author@noreply.github.com Subject: Re: [klabhub/neurostim-ptb] Gui (#143)
I tried to run the simple gui demo and got an error:
It seems that it can't load the gui. I get this error when I try to open nsGui.mlapp:
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fklabhub%2Fneurostim-ptb%2Fpull%2F143%3Femail_source%3Dnotifications%26email_token%3DAC3MRU7RNVBTFWRGJRQJDCDRFL7NHA5CNFSM4K5R4DAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENNR7MI%23issuecomment-593174449&data=02%7C01%7Cbart%40rutgers.edu%7C0e81253cbcbf4090aa7a08d7be440273%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C637187071618578995&sdata=7S%2BP0T65WOhGxIWNHYORyAE5vqG4hvysTMUTQE%2FTPWA%3D&reserved=0, or unsubscribehttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAC3MRUZ6UAI6MCHTH3WUX3LRFL7NHANCNFSM4K5R4DAA&data=02%7C01%7Cbart%40rutgers.edu%7C0e81253cbcbf4090aa7a08d7be440273%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C637187071618578995&sdata=hmEhAh%2BPPBuQ5Ka3iJI%2FSWE6xvldlZQT4hW9qiVtGnA%3D&reserved=0.
adammorrissirrommada
commented
4 years ago That fixed the problem. The GUI looks really nice. Some observations:
A new class definition for a paradigm could perhaps be generated with a wizard that copies a template and renames it. This would probably make things more consistent with plugin.m, where custom panels etc. can be added just adding the class method. It might also fix the current issue in which there is a distinction between a gui-enabled experiment and one that isn’t (and that makes it harder to run scripts without the gui) – all would be enabled, but would have null panels, parsing etc. Is there any value in such an approach?
bartkrekelberg
commented
4 years ago
- Currently, the git repo/branch checkout stuff is coded within the gui app, rather than packed into CIC itself (as it is with versionTracker()), or separately as a util. Is that needed? I’d still want that functionality even if not using the GUI.
I've moved version tracking to neurostim.utils.git and added a gitTrackerDemo
Please have a look
- The gui-related code in runXXX.m scripts looks like you’re halfway to a new approach in which each paradigm/experiment is a class of its own:
Creating an "experiment" class could be an elegant solution but this was not my intention, mainly because I think most users will find the function approach a bit easier to use. It would be relatively easy to have both version exist side-by-side, but not a priority.
In my main use-scenario (a technician running the final version of an experiment that has multiple modes), the fact that some experiments are not gui-enabled is not a big deal; they are not supposed to be run by the technician....
There is a way to run gui-enabled experiments from the command line. See doc neurostim.
bartkrekelberg
commented
4 years ago Apart from the backward compatible changes (the nsGui and the version tracker), this branch also contains changes to myRig and cic.rig
In my view cic.rig is superfluous as those settings can be applied directly to the members of cic. Also it has a strange collection of settings, some that are very general , others that are only for one lab.
cic.myRig really should be a template for a user to copy and adjust for their own purpose.
@adammorrissirrommada and @cnuahs please have a look and see if you agree with this changed approach, as it may require some changes in your experiment files (or your "my Rig" function).
bartkrekelberg
commented
4 years ago I merged the diode branch, and made one further change to myCic; it really has to be outside the +neurostim package.
adammorrissirrommada
commented
4 years ago Some further comments:
VERSION TRACKER
But the people most likely to face problems with untracked code or incompatible class definitions (requiring a loadObj() patch), or be unable to solve them when they occur, are also the least likely to know they should add these lines. My feeling is that use of the tracker should be the default way a neurostim experiment is run, with switching it off an option but for experts only or with a warning. In most cases (I expect), the requested repo would also be the one currently in scope and there would be nothing or little to do. There is a steeper learning curve for new users of ns if we force (strongly encourage) people to use git in their code organisation and practices, but maybe that is still the safer option?
GUI
bartkrekelberg
commented
4 years ago VERSION TRACKER My feeling is that use of the tracker should be the default way a neurostim experiment is run, with switching it off an option but for experts only or with a warning. In most cases (I expect), the requested repo would also be the one currently in scope and there would be nothing or little to do.
I agree, but it feels like something that should be a decision per lab , so how about putting this as a section in the myRig template with the defaults to keep the current branch (whatever it is) and force the latest head version? Anyone setting up the template can then modify at will. OK?
- If ns switches to a different branch to run the experiment, should it switch back to the original git state once the experiment is finished?
Not in the scenario that I am thinking of: if the local checkout is on the wrong branch, then a developer forgot to switch back to the "run experiments" branch. So redoing at the end would just restore an error.
- I somehow found myself with the Experiments field empty, without knowingly changing it. This meant I was no longer able to load the gui. It read that field on load and tried to check the “” branch, which obviously fails. It probably should check that the branch exists before trying to switch to it, or prevent that field from ever being empty.
I cannot reproduce this. With an empty Experiments field it keeps whatever is there and when there is not git it issues a warning? Can you pull and then try to reproduce?
- have you profiled an experiment with and without the gui? In addition to the try-catch, does the gui remain active and potentially draw resources away from the main task? Perhaps you want to toggle(false)?
With the previous internal version of this gui we ran a bunch of EEG experiments with 120Hz monitor and found good performance (less than 1 ms jitter, few if any framedrops). Currently I don't have access to these devices to test again, but it looks as if the gui is not pulling resources away from the main experiment (presumably due to the Priority() calls in cic.run
adammorrissirrommada
commented
4 years ago I think this is where there is a difference between how you are running things and how we are. Your lab is very much a single lab head, directing the organisation of everything. So, all users there must use a single experiments repo, for example. Shaun switches between branches all the time, and possibly switches repos, to run his experiments. And Nic will approach it in his preferred way.
The repo branch/commit to use is really a paradigm-specific setting, so I don't think the suggestion to put the version-tracker in myRig would work. For example, if I want to run an experiment from one year ago, I might want to revert to the same code I used at the time. Later that day, I run a new, different experiment with all the latest commits on master. All in the same rig.
This is why I see "paradigm" (i.e. an experiment script) as something that could be a class, which, as one of its properties, is a set of repo versions to use, and, as I also mentioned, it could include custom panels for the gui.
bartkrekelberg
commented
4 years ago I understand.
But note that the checkout has to happen either in a myRig or in the experiment file, not in CIC.run as by that time all CIC codes is already JIT-compiled, so checkouts will be ignored.
In principle reverting to the previous branch could be done by CIC , but I don't think that would really be better (you'd still have to pass some information to CIC in the experiment file to tell it to revert).
So I think the best way to do this in your use scenario is to call checkout at the start of the experiment and then revert at the end of the script. This is now implemented in the gitTrackerDemo.
An experiment/paradigm class could be an elegant way to wrap around this functionality, but I am not sure it would be truly better or clearer.
B
Bart Krekelberg, PhD
Professor, Rutgers University - Newark
Co-Director, Center for Molecular and Behavioral Neuroscience
Associate Director, Rutgers University Brain Imaging Center
197 University Avenue
Newark, NJ 07102
T: +1 551 285 9265
E: bart@rutgers.edu
W: vision.rutgers.edu
Skype: bartkrekelberg
From: Adam Morris notifications@github.com Sent: Wednesday, March 18, 2020 6:35 To: klabhub/neurostim-ptb neurostim-ptb@noreply.github.com Cc: Bart Krekelberg bart@vision.rutgers.edu; Author author@noreply.github.com Subject: Re: [klabhub/neurostim-ptb] Gui (#143)
I think this is where there is a difference between how you are running things and how we are. Your lab is very much a single lab head, directing the organisation of everything. So, all users there must use a single experiments repo, for example. Shaun switches between branches all the time, and possibly switches repos, to run his experiments. And Nic will approach it in his preferred way.
The repo branch/commit to use is really a paradigm-specific setting, so I don't think the suggestion to put the version-tracker in myRig would work. For example, if I want to run an experiment from one year ago, I might want to revert to the same code I used at the time. Later that day, I run a new, different experiment with all the latest commits on master. All in the same rig.
This is why I see "paradigm" (i.e. an experiment script) as something that could be a class, which, as one of its properties, is a set of repo versions to use, and, as I also mentioned, it could include custom panels for the gui.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fklabhub%2Fneurostim-ptb%2Fpull%2F143%23issuecomment-600433962&data=02%7C01%7Cbart%40rutgers.edu%7C1986a29619f342fe1db308d7cafe39b5%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C637201065570899806&sdata=1QAz49v7vxEVZ%2FeJ0xeF4FM%2FIMn4IXKUVMLVZjcRqH4%3D&reserved=0, or unsubscribehttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAC3MRUYNGYO76Z63C65WDE3RIBMTJANCNFSM4K5R4DAA&data=02%7C01%7Cbart%40rutgers.edu%7C1986a29619f342fe1db308d7cafe39b5%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C637201065570909772&sdata=VTgCfqDUsOY6pyWm0Cu4DYCHkeWSjVBLIt4AipkQPgg%3D&reserved=0.
cnuahs
commented
4 years ago I must apologise, I haven't followed this thread closely but this seems right to me. I think the version tracker should be outside of cic...
Shaun
On Wed, Mar 18, 2020 at 8:59 PM Bart Krekelberg notifications@github.com wrote:
I understand.
But note that the checkout has to happen either in a myRig or in the experiment file, not in CIC.run as by that time all CIC codes is already JIT-compiled, so checkouts will be ignored.
In principle reverting to the previous branch could be done by CIC , but I don't think that would really be better (you'd still have to pass some information to CIC in the experiment file to tell it to revert).
So I think the best way to do this in your use scenario is to call checkout at the start of the experiment and then revert at the end of the script. This is now implemented in the gitTrackerDemo.
An experiment/paradigm class could be an elegant way to wrap around this functionality, but I am not sure it would be truly better or clearer.
B
Bart Krekelberg, PhD
Professor, Rutgers University - Newark
Co-Director, Center for Molecular and Behavioral Neuroscience
Associate Director, Rutgers University Brain Imaging Center
197 University Avenue
Newark, NJ 07102
T: +1 551 285 9265
E: bart@rutgers.edu
W: vision.rutgers.edu
Skype: bartkrekelberg
From: Adam Morris notifications@github.com Sent: Wednesday, March 18, 2020 6:35 To: klabhub/neurostim-ptb neurostim-ptb@noreply.github.com Cc: Bart Krekelberg bart@vision.rutgers.edu; Author < author@noreply.github.com> Subject: Re: [klabhub/neurostim-ptb] Gui (#143)
I think this is where there is a difference between how you are running things and how we are. Your lab is very much a single lab head, directing the organisation of everything. So, all users there must use a single experiments repo, for example. Shaun switches between branches all the time, and possibly switches repos, to run his experiments. And Nic will approach it in his preferred way.
The repo branch/commit to use is really a paradigm-specific setting, so I don't think the suggestion to put the version-tracker in myRig would work. For example, if I want to run an experiment from one year ago, I might want to revert to the same code I used at the time. Later that day, I run a new, different experiment with all the latest commits on master. All in the same rig.
This is why I see "paradigm" (i.e. an experiment script) as something that could be a class, which, as one of its properties, is a set of repo versions to use, and, as I also mentioned, it could include custom panels for the gui.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub< https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fklabhub%2Fneurostim-ptb%2Fpull%2F143%23issuecomment-600433962&data=02%7C01%7Cbart%40rutgers.edu%7C1986a29619f342fe1db308d7cafe39b5%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C637201065570899806&sdata=1QAz49v7vxEVZ%2FeJ0xeF4FM%2FIMn4IXKUVMLVZjcRqH4%3D&reserved=0>, or unsubscribe< https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAC3MRUYNGYO76Z63C65WDE3RIBMTJANCNFSM4K5R4DAA&data=02%7C01%7Cbart%40rutgers.edu%7C1986a29619f342fe1db308d7cafe39b5%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C637201065570909772&sdata=VTgCfqDUsOY6pyWm0Cu4DYCHkeWSjVBLIt4AipkQPgg%3D&reserved=0
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/klabhub/neurostim-ptb/pull/143#issuecomment-600528605, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCTL6NYTJ2IUN23R3UAALLRICLQ5ANCNFSM4K5R4DAA .
adammorrissirrommada
commented
4 years ago Yep, we all agree on that. Version tracking has to be the first cab off the rank.
--
Adam Morris, PhD Group Leader, Computational and Sensorimotor Neuroscience lab. Biomedicine Discovery Institute Department of Physiology, Monash University 26 Innovation Walk Clayton VIC 3800 Australia
On Wed, 18 Mar. 2020, 21:07 Shaun Cloherty, notifications@github.com wrote:
I must apologise, I haven't followed this thread closely but this seems right to me. I think the version tracker should be outside of cic...
Shaun
On Wed, Mar 18, 2020 at 8:59 PM Bart Krekelberg notifications@github.com wrote:
I understand.
But note that the checkout has to happen either in a myRig or in the experiment file, not in CIC.run as by that time all CIC codes is already JIT-compiled, so checkouts will be ignored.
In principle reverting to the previous branch could be done by CIC , but I don't think that would really be better (you'd still have to pass some information to CIC in the experiment file to tell it to revert).
So I think the best way to do this in your use scenario is to call checkout at the start of the experiment and then revert at the end of the script. This is now implemented in the gitTrackerDemo.
An experiment/paradigm class could be an elegant way to wrap around this functionality, but I am not sure it would be truly better or clearer.
B
Bart Krekelberg, PhD
Professor, Rutgers University - Newark
Co-Director, Center for Molecular and Behavioral Neuroscience
Associate Director, Rutgers University Brain Imaging Center
197 University Avenue
Newark, NJ 07102
T: +1 551 285 9265
E: bart@rutgers.edu
W: vision.rutgers.edu
Skype: bartkrekelberg
From: Adam Morris notifications@github.com Sent: Wednesday, March 18, 2020 6:35 To: klabhub/neurostim-ptb neurostim-ptb@noreply.github.com Cc: Bart Krekelberg bart@vision.rutgers.edu; Author < author@noreply.github.com> Subject: Re: [klabhub/neurostim-ptb] Gui (#143)
I think this is where there is a difference between how you are running things and how we are. Your lab is very much a single lab head, directing the organisation of everything. So, all users there must use a single experiments repo, for example. Shaun switches between branches all the time, and possibly switches repos, to run his experiments. And Nic will approach it in his preferred way.
The repo branch/commit to use is really a paradigm-specific setting, so I don't think the suggestion to put the version-tracker in myRig would work. For example, if I want to run an experiment from one year ago, I might want to revert to the same code I used at the time. Later that day, I run a new, different experiment with all the latest commits on master. All in the same rig.
This is why I see "paradigm" (i.e. an experiment script) as something that could be a class, which, as one of its properties, is a set of repo versions to use, and, as I also mentioned, it could include custom panels for the gui.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/klabhub/neurostim-ptb/pull/143#issuecomment-600528605>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ACCTL6NYTJ2IUN23R3UAALLRICLQ5ANCNFSM4K5R4DAA
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/klabhub/neurostim-ptb/pull/143#issuecomment-600532587, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3SMT4K5ILRS6GA46EIA63RICMO7ANCNFSM4K5R4DAA .
adammorrissirrommada
commented
4 years ago Of course, unless we put the version tracker in its own repo, it will always be whichever version of it happens to be in the local branch. Is that an argument for it being independent, always up to date?
--
Adam Morris, PhD Group Leader, Computational and Sensorimotor Neuroscience lab. Biomedicine Discovery Institute Department of Physiology, Monash University 26 Innovation Walk Clayton VIC 3800 Australia
On Wed, 18 Mar. 2020, 21:07 Shaun Cloherty, notifications@github.com wrote:
I must apologise, I haven't followed this thread closely but this seems right to me. I think the version tracker should be outside of cic...
Shaun
On Wed, Mar 18, 2020 at 8:59 PM Bart Krekelberg notifications@github.com wrote:
I understand.
But note that the checkout has to happen either in a myRig or in the experiment file, not in CIC.run as by that time all CIC codes is already JIT-compiled, so checkouts will be ignored.
In principle reverting to the previous branch could be done by CIC , but I don't think that would really be better (you'd still have to pass some information to CIC in the experiment file to tell it to revert).
So I think the best way to do this in your use scenario is to call checkout at the start of the experiment and then revert at the end of the script. This is now implemented in the gitTrackerDemo.
An experiment/paradigm class could be an elegant way to wrap around this functionality, but I am not sure it would be truly better or clearer.
B
Bart Krekelberg, PhD
Professor, Rutgers University - Newark
Co-Director, Center for Molecular and Behavioral Neuroscience
Associate Director, Rutgers University Brain Imaging Center
197 University Avenue
Newark, NJ 07102
T: +1 551 285 9265
E: bart@rutgers.edu
W: vision.rutgers.edu
Skype: bartkrekelberg
From: Adam Morris notifications@github.com Sent: Wednesday, March 18, 2020 6:35 To: klabhub/neurostim-ptb neurostim-ptb@noreply.github.com Cc: Bart Krekelberg bart@vision.rutgers.edu; Author < author@noreply.github.com> Subject: Re: [klabhub/neurostim-ptb] Gui (#143)
I think this is where there is a difference between how you are running things and how we are. Your lab is very much a single lab head, directing the organisation of everything. So, all users there must use a single experiments repo, for example. Shaun switches between branches all the time, and possibly switches repos, to run his experiments. And Nic will approach it in his preferred way.
The repo branch/commit to use is really a paradigm-specific setting, so I don't think the suggestion to put the version-tracker in myRig would work. For example, if I want to run an experiment from one year ago, I might want to revert to the same code I used at the time. Later that day, I run a new, different experiment with all the latest commits on master. All in the same rig.
This is why I see "paradigm" (i.e. an experiment script) as something that could be a class, which, as one of its properties, is a set of repo versions to use, and, as I also mentioned, it could include custom panels for the gui.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/klabhub/neurostim-ptb/pull/143#issuecomment-600528605>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ACCTL6NYTJ2IUN23R3UAALLRICLQ5ANCNFSM4K5R4DAA
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/klabhub/neurostim-ptb/pull/143#issuecomment-600532587, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3SMT4K5ILRS6GA46EIA63RICMO7ANCNFSM4K5R4DAA .
bartkrekelberg
commented
4 years ago I don;t think that is necessary (or even advisable, given the added installation/maintenance overhead). Surely once it is in place changes to versionTracker code will be rare?
From: Adam Morris notifications@github.com Sent: Wednesday, March 18, 2020 11:13 To: klabhub/neurostim-ptb neurostim-ptb@noreply.github.com Cc: Bart Krekelberg bart@vision.rutgers.edu; Author author@noreply.github.com Subject: Re: [klabhub/neurostim-ptb] Gui (#143)
Of course, unless we put the version tracker in its own repo, it will always be whichever version of it happens to be in the local branch. Is that an argument for it being independent, always up to date?
--
Adam Morris, PhD Group Leader, Computational and Sensorimotor Neuroscience lab. Biomedicine Discovery Institute Department of Physiology, Monash University 26 Innovation Walk Clayton VIC 3800 Australia
On Wed, 18 Mar. 2020, 21:07 Shaun Cloherty, notifications@github.com wrote:
I must apologise, I haven't followed this thread closely but this seems right to me. I think the version tracker should be outside of cic...
Shaun
On Wed, Mar 18, 2020 at 8:59 PM Bart Krekelberg notifications@github.com wrote:
I understand.
But note that the checkout has to happen either in a myRig or in the experiment file, not in CIC.run as by that time all CIC codes is already JIT-compiled, so checkouts will be ignored.
In principle reverting to the previous branch could be done by CIC , but I don't think that would really be better (you'd still have to pass some information to CIC in the experiment file to tell it to revert).
So I think the best way to do this in your use scenario is to call checkout at the start of the experiment and then revert at the end of the script. This is now implemented in the gitTrackerDemo.
An experiment/paradigm class could be an elegant way to wrap around this functionality, but I am not sure it would be truly better or clearer.
B
Bart Krekelberg, PhD
Professor, Rutgers University - Newark
Co-Director, Center for Molecular and Behavioral Neuroscience
Associate Director, Rutgers University Brain Imaging Center
197 University Avenue
Newark, NJ 07102
T: +1 551 285 9265
E: bart@rutgers.edu
W: vision.rutgers.edu
Skype: bartkrekelberg
From: Adam Morris notifications@github.com Sent: Wednesday, March 18, 2020 6:35 To: klabhub/neurostim-ptb neurostim-ptb@noreply.github.com Cc: Bart Krekelberg bart@vision.rutgers.edu; Author < author@noreply.github.com> Subject: Re: [klabhub/neurostim-ptb] Gui (#143)
I think this is where there is a difference between how you are running things and how we are. Your lab is very much a single lab head, directing the organisation of everything. So, all users there must use a single experiments repo, for example. Shaun switches between branches all the time, and possibly switches repos, to run his experiments. And Nic will approach it in his preferred way.
The repo branch/commit to use is really a paradigm-specific setting, so I don't think the suggestion to put the version-tracker in myRig would work. For example, if I want to run an experiment from one year ago, I might want to revert to the same code I used at the time. Later that day, I run a new, different experiment with all the latest commits on master. All in the same rig.
This is why I see "paradigm" (i.e. an experiment script) as something that could be a class, which, as one of its properties, is a set of repo versions to use, and, as I also mentioned, it could include custom panels for the gui.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/klabhub/neurostim-ptb/pull/143#issuecomment-600528605>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ACCTL6NYTJ2IUN23R3UAALLRICLQ5ANCNFSM4K5R4DAA
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/klabhub/neurostim-ptb/pull/143#issuecomment-600532587, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3SMT4K5ILRS6GA46EIA63RICMO7ANCNFSM4K5R4DAA .
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fklabhub%2Fneurostim-ptb%2Fpull%2F143%23issuecomment-600535165&data=02%7C01%7Cbart%40rutgers.edu%7C757b6a2e513a4f3dd10c08d7cb24fc56%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C637201232021728651&sdata=iCOF0ojyUnV9MMi2Mp6qw0%2BzQDMolxzZenHXkDnsGUw%3D&reserved=0, or unsubscribehttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAC3MRU5ZIZ4U2CR4ALYHO4LRICNDTANCNFSM4K5R4DAA&data=02%7C01%7Cbart%40rutgers.edu%7C757b6a2e513a4f3dd10c08d7cb24fc56%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C637201232021728651&sdata=Y2iScZSYAyZVGUGzYRtLqsO7Y3brtakkj4Q4wMOMgLg%3D&reserved=0.
I created a GUI that helps to start experiments (and different "modes" of experiments) without changing any files. We have been using something like this for a while and it makes interaction with technicians running the experiments a lot easier (and less error prone than changing experiment files).
The GUI changes are fully backward compatible as this is all optional code for certain use scenarios. Please have a look and let me know what you think. I wrote some guidance in a help file that you can view with doc neurostim: please start there. (We should probably add other things that are in the wiki now there too).
I also updated the versionTracker; it is integrated in the nsGui, but a user can also call it from their experiment file (with options to force commits or not). This too is backward compatible (because versionTracker wasn't actively being used...)
Finally , I also changed the myRig and removed cic.rig function. I think the myRig function should be copied /renamed by a user to somewhere outside the neurostim repo and then adjusted to their liking. The current mix of idiosyncratic options (why can MCC be added in my rig but other plugins cannot? Perfectly sensible for a specific lab, but not something that needs to be in the core toolbox).
This is the only non backward compatible change at this point (and only because some demos may rely on neurostim.myRig. If we agree that the current template is the way forward I'll test the demos and update if needed.