Back to the main page.
Bug 143 - rename the rda2ft directory to brainamp
| Status | CLOSED FIXED |
| Reported | 2010-09-02 11:50:00 +0200 |
| Modified | 2011-01-12 13:09:31 +0100 |
| Product: | FieldTrip |
| Component: | realtime |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 trivial |
| Assigned to: | Stefan Klanke |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2010-09-02 11:50:47 +0200
I suggest that the directory names contain the acquisition system name and that inside the directory the executable is located, i.e. neuralynx/nlx2tf and hence also brainamp/rda2ft. Furthermore, should we keep the matlab datasources and the command-line datasources in a similar directory structure? Here I should note that datasource is not a clear name. (it was copied from BCI2000). Perhaps fieldtrip/realtime/acquisition/*.m fieldtrip/realtime/acquisition/ctf/.. fieldtrip/realtime/acquisition/neuralynx/.. fieldtrip/realtime/acquisition/brainamp/rda2ft.exe or fieldtrip/realtime/acquisition/matlab/ft_realtime_xxxproxy*.m fieldtrip/realtime/acquisition/ctf/.. fieldtrip/realtime/acquisition/neuralynx/.. fieldtrip/realtime/acquisition/brainamp/rda2ft.exe Automatic managing of the path settings/directories (through fieldtripdefs) should be kept in mind with all changes.
Stefan Klanke - 2010-09-02 12:47:33 +0200
I'm not sure whether "datasource" is so much worse than "acquisition" that it justifies renaming the directory (again), but I'm fine with moving the C-based acquisition tools into that directory. I would then leave the .m-files directly on that level, such that you have fieldtrip/realtime/datasource/ft_realtime_brainampproxy.m fieldtrip/realtime/datasource/ft_realtime_neuralynxproxy.m fieldtrip/realtime/datasource/brainamp/rda2ft.exe fieldtrip/realtime/datasource/neuralynx/nlx2ft.exe With this (as opposed to having an additional datasource/matlab directory) at least users immediately have an overview of the different sources, and see that sometimes there are alternative implementations (matlab + C).
Robert Oostenveld - 2010-09-02 13:48:36 +0200
Ok. And what do you think about removing the "proxy" part of the Matlab function name? What do you think is more attractive to the end users: ft_realtime_asaproxy.m ft_realtime_brainampproxy.m ft_realtime_ctfproxy.m ft_realtime_fileproxy.m ft_realtime_fmriproxy.m ft_realtime_micromedproxy.p ft_realtime_neuralynxproxy.m ft_realtime_pooraudioproxy.m ft_realtime_signalproxy.m or ft_realtime_asa.m ft_realtime_brainamp.m ft_realtime_ctf.m ft_realtime_file.m ft_realtime_fmri.m ft_realtime_micromed.p ft_realtime_neuralynx.m ft_realtime_pooraudio.m ft_realtime_signal.m
Robert Oostenveld - 2010-09-02 13:49:22 +0200
or perhaps ft_realtime_asa2ft.m ft_realtime_brainamp2ft.m ft_realtime_ctf2ft.m ft_realtime_file2ft.m ft_realtime_fmri2ft.m ft_realtime_micromed2ft.p ft_realtime_neuralynx2ft.m ft_realtime_pooraudio2ft.m ft_realtime_signal2ft.m
Stefan Klanke - 2010-09-03 10:00:40 +0200
I would just stick to the ***proxy names, even if they don't look too sexy. The "___2ft" scheme looks a bit redundant because the functions already have a "ft_" prefix, and just ft_realtime_ctf might be confusing, because that could also refer to some realtime process function based on CTF data. Sure, it's in the "datasource" directory, but if it's on the path that extra distinction isn't so obvious anymore.