Back to the main page.
Bug 1087 - replace simplefft in databrowser by a call to a browsefun
| Status | CLOSED FIXED |
| Reported | 2011-10-28 09:56:00 +0200 |
| Modified | 2011-11-02 11:13:12 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 normal |
| Assigned to: | Roemer van der Meij |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2011-10-28 09:56:09 +0200
Currently there is % implement devel 'simple fft'-button if strcmp(cfg.enablefftbutton,'yes') uicontrol('tag', 'simplefft', 'parent', h, 'units', 'normalized', 'style', 'togglebutton', 'string','simple fft','position', [0.91, 0.6 - ((iArt-1)*0.09), 0.08, 0.04],'callback',@simplefft_toggle_cb, 'value',0) end but that should be replaced by a call to a cfg.browsefun. Since you added it, I also suggest that you take out the simplefft code. Let me know if anything is unclear.
Roemer van der Meij - 2011-10-28 11:27:58 +0200
I think it is still very useful (and somewhat expected from my perspective) to have functionality like that available on the fly, always. From my perspective the same holds from things like a topoplot, and other functionality I haven't thought of yet. (I agree it should be done via specest-calls and plot_XXX calls of course, I was just lazy at that point ;)). Just basic stuff I expect to do when browsing through raw data for inspection. To me this makes a lot of sense. When I see a dataset for the first time, these are things I would do on an on-demand-basis, not-planned, but dependent on what I see in the raw traces. Are you really sure you wouldn't like functionality like that? Quitting the browsing, and putting in some cfg's, restart, flip to the trial I was interested in, and fft/topo-inspect the part of data that I want to inspect, quitting again, using a previous artifact selection config, flip to the same trial, and continue again is unpractical. And having multiple data-browsers with different cfg.browsefuns open also seems weird, this would in spirit be similar to having a ft_databrowserFFT, ft_databrowserART, ft_databrowserTOPO, etc. Anyway, if you really think it doesn't fit with the purpose of a databrowser, we should remove it of course. (I already copied the current version to use/expand myself). Since I was the last to edit it, could we simply do a rollback/reversal/rewind to a previous version? Which would be r4212, all my additions are done in 'uninterrupted' revisions after that.
Robert Oostenveld - 2011-10-28 13:32:06 +0200
(In reply to comment #1) > I think it is still very useful (and somewhat expected from my perspective) to > have functionality like that available on the fly, always. From my perspective > the same holds from things like a topoplot, and other functionality I haven't > thought of yet. (I agree it should be done via specest-calls and plot_XXX calls > of course, I was just lazy at that point ;)). Just basic stuff I expect to do > when browsing through raw data for inspection. To me this makes a lot of sense. > When I see a dataset for the first time, these are things I would do on an > on-demand-basis, not-planned, but dependent on what I see in the raw traces. > Are you really sure you wouldn't like functionality like that? Yes I also want it and Ingrid and I actually implemented functionality like that. It is just that you are re-implementing existing functionality in an other way. Why don't you take fieldtrip/private/browsefun_topoplotER as example and replace the call to timelockanalis into a call to freqanalysis and then do ft_singleplotER. The toggle button for lin/log power might be of interest for ft_singleplotER as well, just as the channelselection. > Quitting the > browsing, and putting in some cfg's, restart, flip to the trial I was > interested in, and fft/topo-inspect the part of data that I want to inspect, > quitting again, using a previous artifact selection config, flip to the same > trial, and continue again is unpractical. And having multiple data-browsers > with different cfg.browsefuns open also seems weird, this would in spirit be > similar to having a ft_databrowserFFT, ft_databrowserART, ft_databrowserTOPO, > etc. so you are suggesting that instead of the current cfg.selectmode, you want a GUI configurable behaviour of the click in the selected window? I don't see that as conflicting with the design. > Anyway, if you really think it doesn't fit with the purpose of a databrowser, > we should remove it of course. it is the purpose, but we should have a single consistent implementation instead of different implementations that seem to serve the same purpose. > (I already copied the current version to > use/expand myself). Since I was the last to edit it, could we simply do a > rollback/reversal/rewind to a previous version? I don't know whether other changes were made after your change. If so, then a rollback won't work. >Which would be r4212, all my > additions are done in 'uninterrupted' revisions after that. I leave that to you to figure out.
Robert Oostenveld - 2011-10-28 13:33:17 +0200
(In reply to comment #2) oops, I pressed enter with the wrong focus and suddenly the message was poster, whereas I was not yet completely done. Please wait a second, there is more to come...
Robert Oostenveld - 2011-10-28 13:36:39 +0200
Could you join the FT meeting and there present what it is that you want the function to do? About 4 months ago Jorn and I spend a lot of time in reimplementing the databrowser, because of the different users "improvements" to that function (read: hacks), it had become more or less impossible to maintain the function. The stability of the databrowser function is important for both internal and external users, that is why it needs special consideration in adding functionality. I am not opposing your improvements, but they should be done in a manner that is in line with the other developers plans for that function.