You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'll give it more thought, but I haven't been able to come up with a clean fix for this particular bug. In the meantime, it might be a good idea to simply disable or hard code the non-functional inputs. I can do the latter if you'd like and pass it along. At least then the function will work for what I would guess is 98%+ of usage scenarios ... if anyone but me uses this function at all anymore ;).
would you mind to try to fix the function as you have done for the other issue you have reported.
Let us know when you think everything is fine and we can help with testing.
Thanks,
Arno [reply] [−]DescriptionChris Bishop 2014-01-15 11:48:12 PST
Hello again,
While using writecnt, I discovered that several of its optional inputs that change the start position of data writing result in errors.
With the commands below ...
% FILE IN AND OUT
IN=fullfile('C:\Users\cwbishop\Downloads', 'projq_G4_257_6day4.cnt');
OUT=fullfile('C:\Users\cwbishop\Downloads', 'TEST.cnt');
The resulting CNT file is completely invalid. This is due to an error with fseek in line 374 and a similar error in line 397. Fseek fails when attempting to move the pointer position beyond the end of file. Consequently, the event table begins in an improper location (the beginning of the file) and overwrites header and data information. The result is an unusable data file.
Unfortunately, this is not I don't possess the expertise to fix it at present without a significant rewrite of the function. Even then, I am not confident I know how to allow a non-zero start position (sample1 or t1) without writing a bunch of dummy bytes to file ... and that approach will almost certainly cause lots of problems downstream.
I don't expect a fix any time in the near future (or ever, really) since it does not seem that writecnt is used by any mission critical EEGLAB functions. Instead, my hope is to record the bug for posterity.
I will likely have to reorganize the function for my needs and would be happy to upload what I come up with if you feel this would be helpful to others.
Best,
-Chris
The text was updated successfully, but these errors were encountered:
Hi Arno,
I'll give it more thought, but I haven't been able to come up with a clean fix for this particular bug. In the meantime, it might be a good idea to simply disable or hard code the non-functional inputs. I can do the latter if you'd like and pass it along. At least then the function will work for what I would guess is 98%+ of usage scenarios ... if anyone but me uses this function at all anymore ;).
Let me know your thoughts and I'll do what I can.
Best,
-Chris
[reply] [−]Comment 2Arnaud Delorme 2014-02-19 14:35:50 PST
Hi Chris,
would you mind to try to fix the function as you have done for the other issue you have reported.
Let us know when you think everything is fine and we can help with testing.
Thanks,
Arno
[reply] [−]DescriptionChris Bishop 2014-01-15 11:48:12 PST
Hello again,
While using writecnt, I discovered that several of its optional inputs that change the start position of data writing result in errors.
With the commands below ...
% FILE IN AND OUT
IN=fullfile('C:\Users\cwbishop\Downloads', 'projq_G4_257_6day4.cnt');
OUT=fullfile('C:\Users\cwbishop\Downloads', 'TEST.cnt');
% Load CNT file
cnt=loadcnt(IN);
% Call writecnt
writecnt(OUT, cnt, 't1', 50, 'lddur', 1, 'dataformat', 'int32');
The resulting CNT file is completely invalid. This is due to an error with fseek in line 374 and a similar error in line 397. Fseek fails when attempting to move the pointer position beyond the end of file. Consequently, the event table begins in an improper location (the beginning of the file) and overwrites header and data information. The result is an unusable data file.
Unfortunately, this is not I don't possess the expertise to fix it at present without a significant rewrite of the function. Even then, I am not confident I know how to allow a non-zero start position (sample1 or t1) without writing a bunch of dummy bytes to file ... and that approach will almost certainly cause lots of problems downstream.
I don't expect a fix any time in the near future (or ever, really) since it does not seem that writecnt is used by any mission critical EEGLAB functions. Instead, my hope is to record the bug for posterity.
I will likely have to reorganize the function for my needs and would be happy to upload what I come up with if you feel this would be helpful to others.
Best,
-Chris
The text was updated successfully, but these errors were encountered: