[Eeglablist] EEGLAB ASR Question
Johnson, John T.
john.johnson at gatech.edu
Mon Apr 1 17:08:42 PDT 2019
Using -1 is the correct way to disable options.
Using the text off may cause undefined behavior. With the conversion from string to number in processing the GUI controls, using off for a parameter would result in that parameter being set to zero. This may be the source of the odd behavior Bennett was seeing.
Thanks for your reply,
John
On 18 Mar 2019, at 22:13, Makoto Miyakoshi wrote:
Dear Bennett and John,
Sorry to hear the trouble. I'm interested in replicating the problem.
Could you please tell me more details to replicate the issue? Let me see if
I can fix it. Please make sure you are using EEGLAB 14. Up to ver.13 there
was a quite serious bug that is related to handling events.
However, while manually running ASR in the GUI does not result in the
loss of events, running ASR from code does (and -1 vs. 'off' yield
different numbers of events lost). Is there any way to resolve this issue?
I'm not sure about 'event lost' unfortunately, but 'different number of
events lost' may be related to this: Every time ASR is performed, it first
obtains the available RAM. Try the following code on MATLAB.
freeRamInMB
= java.lang.management.ManagementFactory.getOperatingSystemMXBean().getFreePhysicalMemorySize()/(2^20);
This tells you how much RAM is available, seen from this command. ASR
determines how it divide the continuous data into chunks, which can
actually change the final data size (my colleague told me up to 0.3% of
jitter was confirmed.) If you are curious, change the code in asr_process
line 105 maxmem = XXX (this should be MB*2). This should fix the number of
'rejected events.'
Now, general discussion... If we want to obtain the complete
reproducibility, then we have to hard-code this value. ASR was originally
written for real-time BCI application, so this kind of solution was
necessary to prevent memory overflow. However, for the offline analysis we
may want to use a fixed value. However, the current plugin does not have a
structure to pass the value down to this function. I will modify the code
with my colleagues' help (hopefully including Christian himself) to address
the issue. It may take some time (I learned this thing in last November!),
but I want to address it by taking advantage of this momentum!
Makoto
On Thu, Mar 14, 2019 at 9:18 AM Alterman, Bennett L <balterman3 at gatech.edu>
wrote:
If using the GUI for ASR, using -1 to turn off an input field yields the
loss of event markers (and eventually epochs), but writing off in the
fields does not result in this loss. When using eegh to get the code, it
returns a line that uses off, but the code does not run unless 'off' is
used. However, while manually running ASR in the GUI does not result in the
loss of events, running ASR from code does (and -1 vs. 'off' yield
different numbers of events lost). Is there any way to resolve this issue?
Sincerely,
Bennett Alterman, M.S.
--
Ph.D. Student, Cognitive Motor Control Laboratory
School of Biological Sciences
Georgia Institute of Technology
bennett.alterman at gatech.edu
http://bennettalterman.wix.com/neuroimaging
<http://bennettalterman.wixsite.com/neuroimaging>
https://www.linkedin.com/in/bennettalterman/
678.485.6318
_______________________________________________
Eeglablist page: http://sccn.ucsd.edu/eeglab/eeglabmail.html
To unsubscribe, send an empty email to
eeglablist-unsubscribe at sccn.ucsd.edu
For digest mode, send an email with the subject "set digest mime" to
eeglablist-request at sccn.ucsd.edu
--
Makoto Miyakoshi
Assistant Project Scientist, Swartz Center for Computational Neuroscience
Institute for Neural Computation, University of California San Diego
John T. Johnson
PhD Candidate - Cognitive Motor Control Laboratory
Lab TA NEURO 2001 Principles
School of Biological Sciences
Georgia Institute of Technology
678-575-2093
john.johnson at gatech.edu<mailto:john.johnson at gatech.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sccn.ucsd.edu/pipermail/eeglablist/attachments/20190402/d2b7524f/attachment.html>
More information about the eeglablist
mailing list