faster-eeg-list Mailing List for FASTER (Page 2)
Brought to you by:
hughperman,
whelanrob
You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(8) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
(11) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Brian R. <bri...@nc...> - 2011-10-19 22:52:08
|
Hello, I'm interested in potentially applying steps from the FASTER routine to continuous EEG data (like resting state data). The first step if applied to continuous data, and then I am wondering if skipping step 2 but still applying step 3 would work. Specifically, how important would it be to have epochs vs continuous data passed to ICA? Since EEGlab's ICA is spatial and the outlier IC detection steps examine spatial, spectral, and timecourse components of ICs without respect to trials, I think this would work OK. However, has anyone tried it? Are there potential issues with the EOG correlations that I should consider? I appreciate that a large block of continuous data means more input to ICA and potentially greater computation time, but that is OK with me as long as it seems like a valid approach. Without applying steps 2 and 4, there are potentially bad blocks of data that wouldn't be rejected. Perhaps a better alternative is to cut continuous data into 1s "epochs" for step 4. If I used that same approach and applied step 2, I would probably cut out chunks of the continuous EEG. If anyone has tested anything like this and has advice, I would appreciate it! Thanks, Brian |
From: Hugh N. <no...@tc...> - 2011-05-12 19:02:07
|
Hi all, just a small update, I have included the new version of the firfilt plugin kindly supplied by Andreas Widmann, and a couple of bug fixes, including the "invalid channel location". Sorry about that one! Enjoy, Hugh -- Hugh Nolan, Trinity Centre for Bioengineering, Printing House, Trinity College Dublin. Tel: +353861297722 |
From: Robert W. <whe...@gm...> - 2011-05-12 17:08:14
|
Hi --what operating system are you using (Windows, Linux etc.)? All the best, Rob On 12/05/2011 17:37, JOAN PAUL POZUELOS LOPEZ wrote: > Hello everyone, > > Im new using the matlab for analyzing ERP´s. I have been using the FASTER program and i have encounter a problem with some files contained in the filedtrip toolbox. The problem its that when it is computing the ICA the process is not finished because theres an error that says: "error - invalid MEX_file 'c: Users\....\Matlab\external\fieldtrip-20110320\realtime\buffer\matlab\buffer.mexw32': could not find the specified module. > > When i check the folder containing the Buffer.mexw32 file, it is in the folder that the Filepath looks. Any suggestions on how to solve this problem?. > > Thank you very much for your help > > > JOAN PAUL POZUELOS LOPEZ > Departamento de Psicología Experimental y Fisiología del Comportamiento > Universidad de Granada > jp...@ug... > > > > > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Faster-eeg-list mailing list > Fas...@li... > https://lists.sourceforge.net/lists/listinfo/faster-eeg-list > > -- Robert Whelan, PhD Senior Research Scientist Trinity Centre for Bioengineering Trinity College Dublin Department of Neurology St. Vincent's University Hospital Elm Park, Dublin 4 webpage: http://www.mee.tcd.ie/neuraleng/People/Robert |
From: JOAN P. P. L. <jp...@ug...> - 2011-05-12 16:53:14
|
Hello everyone, Im new using the matlab for analyzing ERP´s. I have been using the FASTER program and i have encounter a problem with some files contained in the filedtrip toolbox. The problem its that when it is computing the ICA the process is not finished because theres an error that says: "error - invalid MEX_file 'c: Users\....\Matlab\external\fieldtrip-20110320\realtime\buffer\matlab\buffer.mexw32': could not find the specified module. When i check the folder containing the Buffer.mexw32 file, it is in the folder that the Filepath looks. Any suggestions on how to solve this problem?. Thank you very much for your help JOAN PAUL POZUELOS LOPEZ Departamento de Psicología Experimental y Fisiología del Comportamiento Universidad de Granada jp...@ug... |
From: Hugh N. <no...@tc...> - 2011-02-21 16:11:20
|
Hi all, after a longer-than-expected break in releases, FASTER v1.2b has been released. A number of key features have been added, along with bug fixes. Summary of main features: * Integration with EEGLAB – process datasets that are open in EEGLAB, with options to save them * Distributed processing added (still beta!) – allows a number of computers to share an EEG job which is processing files on a network drive. This feature can also be used to simultaneously process files using multiple instances of MATLAB, taking advantage of multiple processors. * Number of smaller tweaks, including the option to select an output directory * Bug fixes, including the bug with channel properties when using external channels which are numerically mixed in with EEG channels (i.e. they are not all at the end) FASTER v1.2b is available for download at https://sourceforge.net/projects/faster/ Note that this is a beta distribution - it has been tested in our lab, but there may be errors due to particular set ups / processing conditions which we have not come across. Please let us know if you come across an error! Also note that for existing users, the installation process has changed to enable use with EEGLAB. Follow the instructions in the manual. Best, Hugh and Rob -- Hugh Nolan, Trinity Centre for Bioengineering, Printing House, Trinity College Dublin. Tel: +353861297722 |
From: Hugh N. <no...@tc...> - 2010-11-17 12:12:57
|
Hi all, just a thought: this separating of conditions is only a consideration on grand averages, and not raw EEG. In the unaveraged files containing multiple conditions, the background EEG will swamp the ERPs (which may have different properties) and so artifact rejection is mainly applied to the background EEG content, which is assumed to be constant throughout the run. All the best, Hugh On 17 November 2010 12:06, Robert Whelan <whe...@gm...> wrote: > Hi Brian, > > yes, I think it would be better to run the outlier detection on the > conditions separately. As you say, the deviant ERP should have larger > amplitude in comparison to the standard ERP. > > All the best, > Rob > > > On 16/11/2010 21:49, Brian Roach wrote: > > Hi Rob, > > Thanks for the quick response. By extension then, you might also recommend > running the outlier test separately on two different conditions if you > expected differences in amplitude range of variation between conditions? > For example, it probably wouldn't make sense to put deviant ERPs and > standard ERPs from an oddball paradigm into the same outlier analysis, > right? > > Thanks, > Brian > > On 11/16/2010 6:46 AM, Robert Whelan wrote: > > Hi Brian, > > My feeling would be to look for outliers separately in each group, as you > would do for ERP peak analysis because amplitude range & variation may be > different between groups. We have run FASTER on data from multiple sclerosis > patients. The MS patients' data have low amplitude relative to controls. If > MS and control data were mixed then an outlier in the MS groups (e.g., > someone with a large amplitude range, relative to other MS patients) would > not get detected because it would be masked by the control data. > > It is possible that some parameters, such as EOG data, would not differ > across groups. In that case all data could be combined. However, that > presupposes that EOG does not differ across groups (perhaps it could because > of medication effects, etc.). > > I think the safer approach would be treat the groups as separate for the > purposes of artifact rejection on a group level. > > All the best, > Rob > > On 15/11/2010 19:09, Brian Roach wrote: > > Hi All, > > We're using FASTER to analyze data from control participants and patients > with schizophrenia. We have two auditory N1 conditions. I read about the > application of FASTER to mmn data from Parkinson's subjects. I am > interested in recommendations for running the grand average outlier test in > multi-condition, multi-group studies. Would you put all subjects and > conditions in one test, run a separate test for each condition, or run > separate tests for every condition and group? In a normal ERP peak > analysis, we would look for outliers separately in each group, but in that > case we expect group differences. With measures such as amplitude range, > variance, and channel deviation, I don't really know what to expect yet. I > am interested in what others think or have tried. > > Thanks, > Brian > > > -- > Robert Whelan, PhD > Senior Research Scientist > > Trinity Centre for Bioengineering > Trinity College Dublin > > Department of Neurology > St. Vincent's University Hospital > Elm Park, Dublin 4 > > webpage: http://www.mee.tcd.ie/~neuraleng/People/Robert <http://www.mee.tcd.ie/%7Eneuraleng/People/Robert> > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta todayhttp://p.sf.net/sfu/msIE9-sfdev2dev > > > _______________________________________________ > Faster-eeg-list mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/faster-eeg-list > > > > -- > Robert Whelan, PhD > Senior Research Scientist > > Trinity Centre for Bioengineering > Trinity College Dublin > > Department of Neurology > St. Vincent's University Hospital > Elm Park, Dublin 4 > > webpage: http://www.mee.tcd.ie/~neuraleng/People/Robert <http://www.mee.tcd.ie/%7Eneuraleng/People/Robert> > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > Faster-eeg-list mailing list > Fas...@li... > https://lists.sourceforge.net/lists/listinfo/faster-eeg-list > > -- Hugh Nolan, Trinity Centre for Bioengineering, Printing House, Trinity College Dublin. Tel: +353861297722 |
From: Robert W. <whe...@gm...> - 2010-11-17 12:04:46
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hi Brian, <br> <br> yes, I think it would be better to run the outlier detection on the conditions separately. As you say, the deviant ERP should have larger amplitude in comparison to the standard ERP. <br> <br> All the best, <br> Rob<br> <br> On 16/11/2010 21:49, Brian Roach wrote: <blockquote cite="mid:4CE...@nc..." type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> Hi Rob,<br> <br> Thanks for the quick response. By extension then, you might also recommend running the outlier test separately on two different conditions if you expected differences in amplitude range of variation between conditions? For example, it probably wouldn't make sense to put deviant ERPs and standard ERPs from an oddball paradigm into the same outlier analysis, right?<br> <br> Thanks,<br> Brian<br> <br> On 11/16/2010 6:46 AM, Robert Whelan wrote: <blockquote cite="mid:4CE...@tc..." type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> Hi Brian, <br> <br> My feeling would be to look for outliers separately in each group, as you would do for ERP peak analysis because amplitude range & variation may be different between groups. We have run FASTER on data from multiple sclerosis patients. The MS patients' data have low amplitude relative to controls. If MS and control data were mixed then an outlier in the MS groups (e.g., someone with a large amplitude range, relative to other MS patients) would not get detected because it would be masked by the control data.<br> <br> It is possible that some parameters, such as EOG data, would not differ across groups. In that case all data could be combined. However, that presupposes that EOG does not differ across groups (perhaps it could because of medication effects, etc.).<br> <br> I think the safer approach would be treat the groups as separate for the purposes of artifact rejection on a group level.<br> <br> All the best, <br> Rob<br> <br> On 15/11/2010 19:09, Brian Roach wrote: <blockquote cite="mid:4CE...@nc..." type="cite"> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <font size="-1"><font face="Helvetica, Arial, sans-serif">Hi All,<br> <br> We're using FASTER to analyze data from control participants and patients with schizophrenia. We have two auditory N1 conditions. I read about the application of FASTER to mmn data from Parkinson's subjects. I am interested in recommendations for running the grand average outlier test in multi-condition, multi-group studies. Would you put all subjects and conditions in one test, run a separate test for each condition, or run separate tests for every condition and group? In a normal ERP peak analysis, we would look for outliers separately in each group, but in that case we expect group differences. With measures such as amplitude range, variance, and channel deviation, I don't really know what to expect yet. I am interested in what others think or have tried.<br> <br> Thanks,<br> Brian<br> </font></font></blockquote> <br> <pre class="moz-signature" cols="72">-- Robert Whelan, PhD Senior Research Scientist Trinity Centre for Bioengineering Trinity College Dublin Department of Neurology St. Vincent's University Hospital Elm Park, Dublin 4 webpage: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.mee.tcd.ie/%7Eneuraleng/People/Robert">http://www.mee.tcd.ie/~neuraleng/People/Robert</a> </pre> <pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset> ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://p.sf.net/sfu/msIE9-sfdev2dev">http://p.sf.net/sfu/msIE9-sfdev2dev</a></pre> <pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ Faster-eeg-list mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Fas...@li...">Fas...@li...</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/faster-eeg-list">https://lists.sourceforge.net/lists/listinfo/faster-eeg-list</a> </pre> </blockquote> <br> </blockquote> <br> <pre class="moz-signature" cols="72">-- Robert Whelan, PhD Senior Research Scientist Trinity Centre for Bioengineering Trinity College Dublin Department of Neurology St. Vincent's University Hospital Elm Park, Dublin 4 webpage: <a class="moz-txt-link-freetext" href="http://www.mee.tcd.ie/~neuraleng/People/Robert">http://www.mee.tcd.ie/~neuraleng/People/Robert</a> </pre> </body> </html> |
From: Brian R. <bri...@nc...> - 2010-11-16 21:49:23
|
Hi Rob, Thanks for the quick response. By extension then, you might also recommend running the outlier test separately on two different conditions if you expected differences in amplitude range of variation between conditions? For example, it probably wouldn't make sense to put deviant ERPs and standard ERPs from an oddball paradigm into the same outlier analysis, right? Thanks, Brian On 11/16/2010 6:46 AM, Robert Whelan wrote: > Hi Brian, > > My feeling would be to look for outliers separately in each group, as > you would do for ERP peak analysis because amplitude range & variation > may be different between groups. We have run FASTER on data from > multiple sclerosis patients. The MS patients' data have low amplitude > relative to controls. If MS and control data were mixed then an > outlier in the MS groups (e.g., someone with a large amplitude range, > relative to other MS patients) would not get detected because it would > be masked by the control data. > > It is possible that some parameters, such as EOG data, would not > differ across groups. In that case all data could be combined. > However, that presupposes that EOG does not differ across groups > (perhaps it could because of medication effects, etc.). > > I think the safer approach would be treat the groups as separate for > the purposes of artifact rejection on a group level. > > All the best, > Rob > > On 15/11/2010 19:09, Brian Roach wrote: >> Hi All, >> >> We're using FASTER to analyze data from control participants and >> patients with schizophrenia. We have two auditory N1 conditions. I >> read about the application of FASTER to mmn data from Parkinson's >> subjects. I am interested in recommendations for running the grand >> average outlier test in multi-condition, multi-group studies. Would >> you put all subjects and conditions in one test, run a separate test >> for each condition, or run separate tests for every condition and >> group? In a normal ERP peak analysis, we would look for outliers >> separately in each group, but in that case we expect group >> differences. With measures such as amplitude range, variance, and >> channel deviation, I don't really know what to expect yet. I am >> interested in what others think or have tried. >> >> Thanks, >> Brian > > -- > Robert Whelan, PhD > Senior Research Scientist > > Trinity Centre for Bioengineering > Trinity College Dublin > > Department of Neurology > St. Vincent's University Hospital > Elm Park, Dublin 4 > > webpage:http://www.mee.tcd.ie/~neuraleng/People/Robert > > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > > > _______________________________________________ > Faster-eeg-list mailing list > Fas...@li... > https://lists.sourceforge.net/lists/listinfo/faster-eeg-list > |
From: Robert W. <whe...@gm...> - 2010-11-16 14:44:54
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Brian, <br> <br> My feeling would be to look for outliers separately in each group, as you would do for ERP peak analysis because amplitude range & variation may be different between groups. We have run FASTER on data from multiple sclerosis patients. The MS patients' data have low amplitude relative to controls. If MS and control data were mixed then an outlier in the MS groups (e.g., someone with a large amplitude range, relative to other MS patients) would not get detected because it would be masked by the control data.<br> <br> It is possible that some parameters, such as EOG data, would not differ across groups. In that case all data could be combined. However, that presupposes that EOG does not differ across groups (perhaps it could because of medication effects, etc.).<br> <br> I think the safer approach would be treat the groups as separate for the purposes of artifact rejection on a group level.<br> <br> All the best, <br> Rob<br> <br> On 15/11/2010 19:09, Brian Roach wrote: <blockquote cite="mid:4CE...@nc..." type="cite"> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <font size="-1"><font face="Helvetica, Arial, sans-serif">Hi All,<br> <br> We're using FASTER to analyze data from control participants and patients with schizophrenia. We have two auditory N1 conditions. I read about the application of FASTER to mmn data from Parkinson's subjects. I am interested in recommendations for running the grand average outlier test in multi-condition, multi-group studies. Would you put all subjects and conditions in one test, run a separate test for each condition, or run separate tests for every condition and group? In a normal ERP peak analysis, we would look for outliers separately in each group, but in that case we expect group differences. With measures such as amplitude range, variance, and channel deviation, I don't really know what to expect yet. I am interested in what others think or have tried.<br> <br> Thanks,<br> Brian<br> </font></font> </blockquote> <br> <pre class="moz-signature" cols="72">-- Robert Whelan, PhD Senior Research Scientist Trinity Centre for Bioengineering Trinity College Dublin Department of Neurology St. Vincent's University Hospital Elm Park, Dublin 4 webpage: <a class="moz-txt-link-freetext" href="http://www.mee.tcd.ie/~neuraleng/People/Robert">http://www.mee.tcd.ie/~neuraleng/People/Robert</a> </pre> </body> </html> |
From: Brian R. <bri...@nc...> - 2010-11-15 19:43:50
|
Hi All, We're using FASTER to analyze data from control participants and patients with schizophrenia. We have two auditory N1 conditions. I read about the application of FASTER to mmn data from Parkinson's subjects. I am interested in recommendations for running the grand average outlier test in multi-condition, multi-group studies. Would you put all subjects and conditions in one test, run a separate test for each condition, or run separate tests for every condition and group? In a normal ERP peak analysis, we would look for outliers separately in each group, but in that case we expect group differences. With measures such as amplitude range, variance, and channel deviation, I don't really know what to expect yet. I am interested in what others think or have tried. Thanks, Brian |
From: Hugh N. <no...@tc...> - 2010-11-08 17:30:45
|
Hi Brian, sorry I should have specified: the bugs were only present if you had a channel setup with external / EOG channels before or mixed in with the EEG channels - if your setup is such that any external channels are after the EEG channels, you should be fine. Thanks, Hugh On 8 November 2010 17:19, Brian Roach <bri...@nc...> wrote: > What were the interpolation function bugs? If we have run a data set > through a previous version of FASTER, should we update the scripts and redo > that analysis? > > Thanks, > Brian > > > On 11/5/2010 10:34 AM, Hugh Nolan wrote: > > Dear all, > FASTER v1.1.3 is now available. Thank you all for your invaluable work > reporting bugs, and special thanks to Grega Repovs for his work identifying > bugs in the interpolation functions. > > This version consists of a number of bug fixes, which should allow for > smoother operation of FASTER. > > There have been a number of new features suggested, and we will be working > on these next week. If anyone has further feature suggestions, we will try > and include them in the next version. > > Best, > Hugh and Rob > > -- > Hugh Nolan, > Trinity Centre for Bioengineering, > Printing House, > Trinity College Dublin. > > Tel: +353861297722 > > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now!http://p.sf.net/sfu/SAP-dev2dev > > > _______________________________________________ > Faster-eeg-list mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/faster-eeg-list > > > > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Faster-eeg-list mailing list > Fas...@li... > https://lists.sourceforge.net/lists/listinfo/faster-eeg-list > > -- Hugh Nolan, Trinity Centre for Bioengineering, Printing House, Trinity College Dublin. Tel: +353861297722 |
From: Brian R. <bri...@nc...> - 2010-11-08 17:19:38
|
What were the interpolation function bugs? If we have run a data set through a previous version of FASTER, should we update the scripts and redo that analysis? Thanks, Brian On 11/5/2010 10:34 AM, Hugh Nolan wrote: > Dear all, > FASTER v1.1.3 is now available. Thank you all for your invaluable work > reporting bugs, and special thanks to Grega Repovs for his work > identifying bugs in the interpolation functions. > > This version consists of a number of bug fixes, which should allow for > smoother operation of FASTER. > > There have been a number of new features suggested, and we will be > working on these next week. If anyone has further feature suggestions, > we will try and include them in the next version. > > Best, > Hugh and Rob > > -- > Hugh Nolan, > Trinity Centre for Bioengineering, > Printing House, > Trinity College Dublin. > > Tel: +353861297722 > > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > > > _______________________________________________ > Faster-eeg-list mailing list > Fas...@li... > https://lists.sourceforge.net/lists/listinfo/faster-eeg-list > |
From: Hugh N. <no...@tc...> - 2010-11-05 17:34:54
|
Dear all, FASTER v1.1.3 is now available. Thank you all for your invaluable work reporting bugs, and special thanks to Grega Repovs for his work identifying bugs in the interpolation functions. This version consists of a number of bug fixes, which should allow for smoother operation of FASTER. There have been a number of new features suggested, and we will be working on these next week. If anyone has further feature suggestions, we will try and include them in the next version. Best, Hugh and Rob -- Hugh Nolan, Trinity Centre for Bioengineering, Printing House, Trinity College Dublin. Tel: +353861297722 |
From: Hugh N. <no...@tc...> - 2010-10-22 18:34:59
|
Hi all, a couple of errors slipped through the net in v1.1.1 so I've updated to v1.1.2 today. It's available as usual at https://sourceforge.net/projects/faster/ Hugh -- Hugh Nolan, Trinity Centre for Bioengineering, Printing House, Trinity College Dublin. Tel: +353861297722 |
From: Hugh N. <no...@tc...> - 2010-10-21 21:19:08
|
Hi all, after fixing a few more bugs than I had realised, I've got the new version of FASTER ready. A short list of the bug fixes and features: Fixed some bugs between different MATLAB versions Added ability to save ICA topographic images Added explicit option to turn on or off markered epoching Added option to change referencing of output file Fixed some grand averaging issues Expanded error-catching system to help catch any further bugs. It is now turned on by default so users experiencing bugs don’t have to rerun data files again Enabled binica, if it is setup as per the instructions in EEGLAB Enabled the use of text-based markers as well as numerical markers (be sure to read to “markered epoching” section for the correct syntax) Clarified an issue using ICA component rejection without using the built-in lowpass filter (see the new option in the ICA rejection options) Fixed a small bug with external channels which have no locations A few other miscellaneous bug fixes Do let me know if there's any bugs introduced, or that aren't fixed, as well as any features that you would like to see included in the next version. All the best, Hugh -- Hugh Nolan, Trinity Centre for Bioengineering, Printing House, Trinity College Dublin. Tel: +353861297722 |
From: Robert W. <whe...@gm...> - 2010-10-19 07:24:33
|
Hi Jordan, It is no problem to change the reference to Cz (you can do that in the FASTER GUI). EEGLAB can be used to re-reference the data to Cz (or any other channel(s) )after processing, again thru a GUI. Hope that helps, Rob On 18/10/2010 23:41, Jordan Silberman wrote: > Hi Hugh and Grega, > > Again, I'm grateful for the fabulous tool you've developed--thank you! > > I have one more question about referencing in FASTER. > > Some suggest that average referencing is suboptimal for source localization. Is it possible to a) input a .set file into FASTER that is referenced to Cz, and b) have FASTER output data that remains referenced to Cz? > > Or, if it is necessary to undo the average referencing that is present in the output, how exactly would you do this? I assume that the correct un-referencing process will depend on when in the FASTER process the data are average referenced. > > Many thanks, > Jordan > > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > Faster-eeg-list mailing list > Fas...@li... > https://lists.sourceforge.net/lists/listinfo/faster-eeg-list > > -- Robert Whelan, PhD Senior Research Scientist Trinity Centre for Bioengineering Trinity College Dublin Department of Neurology St. Vincent's University Hospital Elm Park, Dublin 4 webpage: http://www.mee.tcd.ie/~neuraleng/People/Robert |
From: Jordan S. <jsi...@gm...> - 2010-10-18 22:41:43
|
Hi Hugh and Grega, Again, I'm grateful for the fabulous tool you've developed--thank you! I have one more question about referencing in FASTER. Some suggest that average referencing is suboptimal for source localization. Is it possible to a) input a .set file into FASTER that is referenced to Cz, and b) have FASTER output data that remains referenced to Cz? Or, if it is necessary to undo the average referencing that is present in the output, how exactly would you do this? I assume that the correct un-referencing process will depend on when in the FASTER process the data are average referenced. Many thanks, Jordan |
From: Hugh N. <no...@tc...> - 2010-10-18 09:57:08
|
Dear all, a few interesting questions have been sent to us, so we thought we would share them along with our answers. Question 1: > Hi Hugh and Rob, > I've recently read through your FASTER manuscript in the journal of neuroscience methods and downloaded the code. The report makes a lot of sense, and I appreciate a less subjective approach that moves away from the "expert inspection" method of ICA component removal. I work in a schizophrenia EEG/fMRI lab, and am working on applying this tool to one of our data sets. While it was easy to set something up in the GUI, we have data from many different systems in the lab, and I'd like to get some things scripted. Looking at your FASTER_process.m function, it looks like *_properties.m functions do most of the number crunching in steps 1-5 of your figure 2, and min_z.m identifies the trouble makers. Does that sound about right? I'll obviously spend a lot more time with the code and trying to figure things out, but I wanted to be able to cite your method and would like to be confident that in moving away from the gui, I do not butcher the FASTER process. > Will you have an e-mail list for questions about the tool? Is there any way I could be added to a list of those you'll inform about updates (if you're keeping one)? > Thank you, > Brian Answer 1: > Hi Brian, > apologies for the late reply, we have been testing the new version of FASTER (v1.1) which has a nember of new features added and bugs fixed. We moved to a new host at https://sourceforge.net/projects/faster/ if you'd like to take a look. > You are correct that the main functions used are the *_properties functions and the min_z function. The *_properties functions are somewhat idiocratic in that they each take different arguments, but their output is a standard format fed into min_z. > The general approach for artifact identification is: > (replace X with channel, epoch, component, etc) > 1) list_properties = X_properties(EEG, further, inputs); % The further inputs can be seen in each file, they > 2) exceeded_threshold = min_z(list_properties); % min_z also takes further arguments to allow you to turn on or off specific testing properties or use a Z-score threshold other than 3 > 3) bad_X = find(exceeded_threshold); % Exceeded threshold also details how many properties of each channel, epoch, component, etc exceeded the threshold, so you could use "bad_X = find(exceeded_threshold >= 2)" to tighten the rejection conditions to only reject Xs that are considered artifact-contaminated by 2 tests, if desired. > Scripting shouldn't be too difficult, although we didn't write the code with easy scripting in mind, sorry about that! If you follow the faster_process.m file, you will be able to see what occurs between each processing stage (for example, re-referencing before channel rejection). As you say, the meat is in the _properties and min_z files; the rest is mostly bookkeeping, logging, GUI interface stuff, and tests for specific cases. If you use them, you should be following the process pretty well. > We have just started a mailing list for FASTER discussion and updates; would you mind if we posted your question and my response onto the list? You can sign up at https://lists.sourceforge.net/lists/listinfo/faster-eeg-list if you want. > Thanks, > Hugh Question 2: > Dear Robert, > i am reading your paper on FASTER and and I am so impressed that i would like to use it immediately with my data sets within an oddball auditory experiment. > I have 3 EEG data sets (each with 20 subjects) from three groups: younger controls, older controls, and parkinsonian patients. Especially with the latest, a manual eog rejection through templates does not yield good results. We cannot apply the Schloegl method since we did not collect separate data files on eye movements. > However, I used a 25 scalp-electrode (+ 4 eye, 2 mastoids and 1 nose reference), so I wonder whether in your opinion/experience this is going to be a major hindrance wrt the use of FASTER. > My very best regards, > Alessandro Answer 2: > Hi Alessandro, > thank you for your kind comments about FASTER. > I think -- in theory -- it should be ok to run FASTER on your data. However, you should check the data after running the default settings. All of the parameters in FASTER are modifiable, so you may want to change the default settings to achieve a better results. I'm not really sure what settings might need to be changed for 25 electrodes, but in particular you should check that the EOG is being removed. If not, you could change some of the EOG settings. > By the way, FASTER v1.1. is available on http://sourceforge.net/projects/faster/files/ - this version has some extra features, such as use of a trimmed mean in the Grand Averaging, which might be better for your data. > Hope that helps, > Rob > Hi Alessandro, > further to Robert's comments, I would recommend that you turn off the "Channel rejection" and the "Epoch interpolation" options if only using 25 channels, as the effectiveness of the bad channel detection measure dropped a lot when we tested on 32 channels. I don't know how effective the ICA decomposition will be, so do check with a few test datasets that good data isn't being removed! > All the best, > Hugh In other news, hopefully FASTER 1.1.1 will be up later today. Hugh |
From: Hugh N. <no...@tc...> - 2010-10-17 14:51:24
|
Dear Jordan - the data will be temporarily referenced to a site specified by you during FASTER processing, and then converted to average reference for the output stage. Before this, your data can be in any reference configuration you wish. Thanks for you kind words, Hugh and Rob On 16 October 2010 21:08, Jordan Silberman <jsi...@gm...> wrote: > FASTER is extremely useful--many thanks to Hugh Nolan for creating this. > > Is it correct that the raw data processed by FASTER should initially be unreferenced? Or should it be referenced to Cz or something similar? > > Thanks, > Jordan > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > Faster-eeg-list mailing list > Fas...@li... > https://lists.sourceforge.net/lists/listinfo/faster-eeg-list > > -- Hugh Nolan, Trinity Centre for Bioengineering, Printing House, Trinity College Dublin. Tel: +353861297722 |
From: Jordan S. <jsi...@gm...> - 2010-10-16 20:08:43
|
FASTER is extremely useful--many thanks to Hugh Nolan for creating this. Is it correct that the raw data processed by FASTER should initially be unreferenced? Or should it be referenced to Cz or something similar? Thanks, Jordan |
From: Grega R. <gre...@ps...> - 2010-10-14 17:39:08
|
Dear Hugh, I do find FASTER useful, I especially like the simplicity of use and one step preprocessing it affords. I would however like to know how it compares to other preprocessing options. For that reason, we're running data that we have collected in an oddball paradigm (128 channels) and preprocessed "by hand" through both FASTER and EP toolbox. I'd like to see how data preprocessed by an expert differs from fully automatic preprocessing. Previously working primarily with the fMRI, I'm used to the latter and it would be great to have reliable fully automatic preprocessing available for EEG as well. In regards to binica, I'm running analyses on an Apple Mac Server (with Mac OS X Leopard and the latest version of MATLAB). I have: 1/ installed the version of binica compiled for 32/64 bit Intel Apple hardware, 2/ set the path to binica folder in Matlab, 3/ set ICABINARY in eeglab/functions/sigprocfunc/icadefs.m to the correct path 4/ changed the lines following % Do ICA % in FASTER_process.m to specify 'icatype', 'binica' in calls to pop_runica I did no other changes. I am assuming it might even work if 'icatype', 'binica' is omitted from the call as pop_runica should call binica by default and then switch to runica if it can not find / run binica. Additionally, there was a conflict with fieldrip so I removed fieldtrip paths when running FASTER and it all runs fine now. All the best, Grega On Oct 14, 2010, at 6:55 PM, Hugh Nolan wrote: > Dear Grega, > thank you very much for your comments! > > In response to your points: > >>> Bugs >>> - When running a job on a folder with multiple .set and .fdt files for a study, FASTER creates a folder for each of the subjects, however it only copies .set files and not the corresponding .fdt files, which leads to an error when .fdt files are not found in the next step, but have to be moved there manually before restarting the job. > Thank you for this, there are unfortunately 2 versions of a particular > file due to a MATLAB version oddity - I forgot to copy the changes > from one into the other! A new version of FASTER will be available in > the next day or two with this and a few other bug fixes, as well as a > couple of new features. If you wish to try the in-progress version > (with the bug fixes, but not all the new features), email me > personally (no...@tc...). > >>> - When saving job, the job is always saved to the existing file and there is no option for a "Save As" operation. > There is a "Save As" option in the "More Options" menu (top left of > the GUI). Maybe it would be a good idea to rename this "File Options" > to make it more obvious? > >>> Questions >>> - It is not entirely clear what happens when the .set files are already epoched. Is the existing epoching used, or is the whole recording considered a single epoch? > Existing epoching is used, and epoch removal / rejection can be > performed on these datasets. If markers are entered into the "Epoching > markers" box, further epoching based on these markers will take place. > I think I will add an explicit "Do Markered Epoching" option to try > and clear up any ambiguity. > >>> Suggestions >>> - At this time the use of runica is "hard coded" into the script. To use binica instead I had to change the script itself. It would be nice to have that as an option under ICA options. > Would you so kind as to send me (no...@tc...) or Rob > (rob...@tc...) this change? I haven't had much success with > binica myself, but if you have got it working with FASTER, I would be > happy to integrate it! > >>> - It would be great if one had the opportunity to review, which were the ICA components found and which of them were rejected. One possibility would be to save the mixing matrices in the "Intermediate" folder. An even user-friendlier option would be to generate component topography images and save them as a PNG image or a PDF document > This is a very good idea - I'll include it in the update. > > I hope you are finding FASTER useful. > > Hugh > > -- > Hugh Nolan, > Trinity Centre for Bioengineering, > Printing House, > Trinity College Dublin. > > Tel: +353861297722 > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Faster-eeg-list mailing list > Fas...@li... > https://lists.sourceforge.net/lists/listinfo/faster-eeg-list > -- Asist. Prof. Grega Repovš, Ph.D. Department of Psychology University of Ljubljana Aškerčeva 2 SI-1000 Ljubljana tel: +386 1 241 1175 email: gre...@ps... |
From: Hugh N. <no...@tc...> - 2010-10-14 16:55:54
|
Dear Grega, thank you very much for your comments! In response to your points: >> Bugs >> - When running a job on a folder with multiple .set and .fdt files for a study, FASTER creates a folder for each of the subjects, however it only copies .set files and not the corresponding .fdt files, which leads to an error when .fdt files are not found in the next step, but have to be moved there manually before restarting the job. Thank you for this, there are unfortunately 2 versions of a particular file due to a MATLAB version oddity - I forgot to copy the changes from one into the other! A new version of FASTER will be available in the next day or two with this and a few other bug fixes, as well as a couple of new features. If you wish to try the in-progress version (with the bug fixes, but not all the new features), email me personally (no...@tc...). >> - When saving job, the job is always saved to the existing file and there is no option for a "Save As" operation. There is a "Save As" option in the "More Options" menu (top left of the GUI). Maybe it would be a good idea to rename this "File Options" to make it more obvious? >> Questions >> - It is not entirely clear what happens when the .set files are already epoched. Is the existing epoching used, or is the whole recording considered a single epoch? Existing epoching is used, and epoch removal / rejection can be performed on these datasets. If markers are entered into the "Epoching markers" box, further epoching based on these markers will take place. I think I will add an explicit "Do Markered Epoching" option to try and clear up any ambiguity. >> Suggestions >> - At this time the use of runica is "hard coded" into the script. To use binica instead I had to change the script itself. It would be nice to have that as an option under ICA options. Would you so kind as to send me (no...@tc...) or Rob (rob...@tc...) this change? I haven't had much success with binica myself, but if you have got it working with FASTER, I would be happy to integrate it! >> - It would be great if one had the opportunity to review, which were the ICA components found and which of them were rejected. One possibility would be to save the mixing matrices in the "Intermediate" folder. An even user-friendlier option would be to generate component topography images and save them as a PNG image or a PDF document This is a very good idea - I'll include it in the update. I hope you are finding FASTER useful. Hugh -- Hugh Nolan, Trinity Centre for Bioengineering, Printing House, Trinity College Dublin. Tel: +353861297722 |
From: Grega R. <gre...@ps...> - 2010-10-14 14:07:55
|
Hello, As the owners of the list are encouraging the use of the mailinglist for questions, suggestions and bug reports, here are a few. Bugs - When running a job on a folder with multiple .set and .fdt files for a study, FASTER creates a folder for each of the subjects, however it only copies .set files and not the corresponding .fdt files, which leads to an error when .fdt files are not found in the next step, but have to be moved there manually before restarting the job. - When saving job, the job is always saved to the existing file and there is no option for a "Save As" operation. Questions - It is not entirely clear what happens when the .set files are already epoched. Is the existing epoching used, or is the whole recording considered a single epoch? Suggestions - At this time the use of runica is "hard coded" into the script. To use binica instead I had to change the script itself. It would be nice to have that as an option under ICA options. - It would be great if one had the opportunity to review, which were the ICA components found and which of them were rejected. One possibility would be to save the mixing matrices in the "Intermediate" folder. An even user-friendlier option would be to generate component topography images and save them as a PNG image or a PDF document. Otherwise, congratulations on a good software package and thanks for sharing it with others! With best regards, Grega Repovs -- Asist. Prof. Grega Repovš, Ph.D. Department of Psychology University of Ljubljana Aškerčeva 2 SI-1000 Ljubljana tel: +386 1 241 1175 email: gre...@ps... |
From: Hugh N. <no...@tc...> - 2010-10-08 15:24:47
|
Dear all, This mailing list hosts information and discussion about the FASTER plugin for EEGLAB, which is used for automatic processing of EEG data. We hope you find our software useful, and welcome any questions, discussion, or bug reports here. Regards, Hugh -- Hugh Nolan, Trinity Centre for Bioengineering, Printing House, Trinity College Dublin. Tel: +353861297722 |