Register Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 9 of 9     «   Prev   6   7   8   9
Jaewon

Administrator
Registered:
Posts: 577
Reply with quote  #201 
Interesting! I use the same code for both 32-bit and 64-bit, so there is no reason that one should be better than the other, although 64-bit can use larger system resource. I don't have a 32-bit Windows machine, but can you send me your code so that I can test it on my computer? You can email me or send a private message.
0
Jaewon

Administrator
Registered:
Posts: 577
Reply with quote  #202 
Hi Herrick,

I could replicate the problem you found. I used R2014a 32-bit on Win 10 64-bit. I guess it may happen on all 32-bit version MATLAB. It has been long since I used the 32-bit version last time, so I didn't catch it before. Thank you for reporting it!

I examined my code. As I mentioned, the mex files are compiled from the same source code, whether they are 32-bit or 64-bit. Since they call different MATLAB and Windows DLLs, it is possible that the memory usage is different between the architectures, but they are supposed to work in the same way.

Unfortunately I couldn't fix the problem yet. Both 32-bit and 64bit binaries did not show a sign of obvious memory leaks on Visual Studio and MATLAB profiler, but somehow the memory was not retrieved in the 32-bit version. One thing I noticed was that the 32-bit version required a lot more memory than 64-bit, although it was definitely not something that I intended. I will keep looking into this problem, but it may take a while.

If you can use 64-bit MATLAB and Windows, I don't see any reason not to move on. Mathworks does not release 32-bit MATLAB anymore.


0
Jaewon

Administrator
Registered:
Posts: 577
Reply with quote  #203 
* Changes in NIMH MonkeyLogic 2 (Apr 26, 2018)

 + Registering different editable variables from multiple timing scripts works
   okay now.

 + eyejoytrack has new options, 'acquirefunc' and 'holdfunc', which allow
   eyejoytrack to use an arbitrary function as a source of a tracking signal.
   
     eyejoytrack('acquirefunc', @function_handle, function_args, duration);
     eyejoytrack('holdfunc', @function_handle, function_args, duration);

   The function should return a logical scalar ('holdfunc') or a logical vector
   ('acquirefunc'). The 'acquirefunc' option makes eyejoytrack end when the
   function output changes from false to true and the 'holdfunc' option, from
   true to false.

0
Herrick

Junior Member
Registered:
Posts: 7
Reply with quote  #204 
Quote:
Originally Posted by Jaewon
Hi Herrick,

I could replicate the problem you found. I used R2014a 32-bit on Win 10 64-bit. I guess it may happen on all 32-bit version MATLAB. It has been long since I used the 32-bit version last time, so I didn't catch it before. Thank you for reporting it!

I examined my code. As I mentioned, the mex files are compiled from the same source code, whether they are 32-bit or 64-bit. Since they call different MATLAB and Windows DLLs, it is possible that the memory usage is different between the architectures, but they are supposed to work in the same way.

Unfortunately I couldn't fix the problem yet. Both 32-bit and 64bit binaries did not show a sign of obvious memory leaks on Visual Studio and MATLAB profiler, but somehow the memory was not retrieved in the 32-bit version. One thing I noticed was that the 32-bit version required a lot more memory than 64-bit, although it was definitely not something that I intended. I will keep looking into this problem, but it may take a while.

If you can use 64-bit MATLAB and Windows, I don't see any reason not to move on. Mathworks does not release 32-bit MATLAB anymore.




Thanks Jaewon! I have move on to 64-bit Matlab R2015b in 64-bit Win7ļ¼Œthings are working fine now. It's so great that the newest release fixed the editable variables registering problem. Really appreciate that!

And there's a little difference between ML1 and ML2 that pressing "C" is to center the eye poistion to current fixation point in ML1, but in ML2 it's to center eye position to the center of the screen. In ML1 I can manually choose the poisition when my fixation point isn's in the center of the screen, but now I have a trouble to do that and failed to modify line 1132 in trialholder_v1.m (hotkey('c', 'ML_prev_eye_position(end+1,:) = eye_position * EyeCal.rotation_rev_t; ML_EyeOffset = ML_EyeOffset + ML_prev_eye_position(end,:);'); % adjust eye offset)

I can't find target position variable to replace eye_position * EyeCal.rotation_rev_t, is that correct? could you help me with that?

What's more, I notice that new value defined under "User" field like (TrialRecord.User.Var1 = 200[wink] can't be saved to bhv2 file. I haven't found a way to quick fix it.
0
Jaewon

Administrator
Registered:
Posts: 577
Reply with quote  #205 

How did you choose the position "manually"? I guess we can make NIMH ML2 does the correction to the current fixation point, if there is only one stimulus to fixate, but it won't be a manually selection of the fixation point.

In NIMH ML2, the "C" key works anytime during trials and calibration, whether there is a fixation point on the screen or not, and you can undo the correction with the "U" key. Since NIMH ML2 remembers the history of the changes, you can do and undo the correction multiple times.

Do you expect the "User" field automatically to be saved in the data file? Or you tried to save the variable in the "User" field but didn't work somehow? The original ML didn't save the custom field of TrialRecord either, so I don't understand what you think needs to be fixed.

0
Herrick

Junior Member
Registered:
Posts: 7
Reply with quote  #206 
Quote:
Originally Posted by Jaewon

How did you choose the position "manually"? I guess we can make NIMH ML2 does the correction to the current fixation point, if there is only one stimulus to fixate, but it won't be a manually selection of the fixation point.

In NIMH ML2, the "C" key works anytime during trials and calibration, whether there is a fixation point on the screen or not, and you can undo the correction with the "U" key. Since NIMH ML2 remembers the history of the changes, you can do and undo the correction multiple times.

Do you expect the "User" field automatically saved in the data file? Or you tried to save the variable in the "User" field but didn't work somehow? The original ML didn't save the custom field of TrialRecord either, so I don't understand what you think needs to be fixed.



Yes,actually, what I want to do is just let ML2 do the correction to the current fixation point. My task needs the monkey to fixate a point locates at (10,10) from screen center (+ up & right) when a trial starts. Auto correction works fine in several trials at first. But after a while, eye signal slowly drifts away from the fixation point even if the monkey is fixating it. If "C" is pressed in ML2, the eye position is corrected to the center of the screen. At that time, pressing "U" seems helpless, since it's not the auto correction causing the problem. So I have to stop and return to menu to recalibrate eye signal. But in ML1 it is to correct the eye position to the current position at the moment "C" is pressed. Can we make ML2 to realize that like ML1? Because it's crucial to my experiment to make monkey fixate in a relatively small window and quickly correct the drift.

And as to the "User" field, I made some modificaition to trialholder.m and bhv_read.m of ML1 that some variables can be added in TrialRecord and saved in the .bhv file. I mistakenly thought variables added to "User" field can be saved to struct UserVars like SkippedFrameInfo. Is it possible to do that?
0
Jaewon

Administrator
Registered:
Posts: 577
Reply with quote  #207 
Hi Herrick,

I changed how the "C" key works a little. See if the attached package works for you.

If you want to save any variable to the data file, call bhv_variable.

bhv_variable(var_name,var_value);

ex) bhv_variable('test',TrialRecord.User.test);
0
Jaewon

Administrator
Registered:
Posts: 577
Reply with quote  #208 
* Changes in NIMH MonkeyLogic 2 (May 3, 2018)

 + Now users can determine the origin of the forced eye drift correction ("C"
   key), which previously occurred to the center of the visual space ([0 0])
   only.

   To change the origin, define a hotkey like the following in the timing
   script. If the coordinates are not provided, the position of the currently
   presented visual stimulus (the one closest to the current eye position) will
   be used as the origin.

   hotkey('c', 'forced_eye_drift_correction([x y]);'); % x & y in visual angles
   hotkey('c', 'forced_eye_drift_correction;');    % to current visual stimulus
   hotkey('c', 'forced_eye_drift_correction([0 0]);');          % default setup
   
   In the calibration tools, the origin of the correction is alway [0 0].

 + New example tasks & minor fixes

 - The time during which the message loop is called is adjusted, to fix a
   problem that touch was not smoothly detected under a certain condition.

0
Herrick

Junior Member
Registered:
Posts: 7
Reply with quote  #209 
Quote:
Originally Posted by Jaewon
Hi Herrick,

I changed how the "C" key works a little. See if the attached package works for you.

If you want to save any variable to the data file, call bhv_variable.

bhv_variable(var_name,var_value);

ex) bhv_variable('test',TrialRecord.User.test);


Hi Jaewon,

Thanks for the modified version of ML2, it helps me a lot!
0
Herrick

Junior Member
Registered:
Posts: 7
Reply with quote  #210 
Hi Jaewon,

I noticed that the cycle rate droped below 1KHz when using eye signal, but in simulation mode, the rate is near 2KHz. The experiment files I have send you includes avi files to present visual stimuli. Do you know how to improve that?

BTW, these days I tried to make avi with alpha channel so that the grating's backgroud won't overlap when they're getting close? Does ML2 support transparent video stimuli?
0
Jaewon

Administrator
Registered:
Posts: 577
Reply with quote  #211 
Your task runs at 2kHz on my computer (Intel i5) and at 5.2kHz in the simulation mode. Maybe getting a faster computer can be a solution.

It is possible if the format and the decoder support the alpha channel, but I don't know which format and decoder do so.
0
Jaewon

Administrator
Registered:
Posts: 577
Reply with quote  #212 
* Changes in NIMH MonkeyLogic 2 (May 9, 2018)

 + NIMH ML can create movies from a set of image files or from frame data
   generated from scripts. This is not a new feature, but there was a bug that
   prevented it from working. A new example task is added to show how this
   works. See the "task\runtime v1\6 sine grating" directory.

 + The GEN script can take a second argument, MLConfig, now.
0
Jaewon

Administrator
Registered:
Posts: 577
Reply with quote  #213 
* Changes in NIMH MonkeyLogic 2 (May 14, 2018)

 - A memory leak problem of the movie object is fixed.
0
Jaewon

Administrator
Registered:
Posts: 577
Reply with quote  #214 
* Changes in NIMH MonkeyLogic 2 (May 21, 2018)

 + The manuals entirely re-written for NIMH ML (HTML & PDF) are included in the
   distribution packages.  The HTML files explain the usage of TaskObject in
   the conditions file and the syntax of runtime functions and adapters.  They
   can be brought up from the main menu with a button click.  The PDF file
   covers all other topics of NIMH ML in general.

help_menu.jpg 

 + When the block switched manually and the error logic was "repeat
   immediately", a new condition was not selected from the new block until the
   current trial was correctly finished. This is fixed now. (Thanks to Herrick)

 + bhv_variable can take multiple name/value pairs.

     bhv_variable('name1', value1, 'name2', value2, ...);

 + The idle command can send out eventcode(s) to notice external devices the
   timing of the background color change.

     idle(1000, [1 0 0], 10);  % red screen for 1 sec, marked with 10

     idle(1000, [], 10);       % mark the code in sync with the next frame
                               % the color change is not necessary

 + The FrameCounter adapter used to run for N+1 frames.  The one additional
   frame was necessary to turn off stimuli.  This behavior is changed.  Now the
   FrameCounter runs exactly N frames and finishes the scene without turning
   off the stimuli.  Actually the stimuli are off at the end of the scene but
   the last (N+1) frame in which they are removed is not presented, to give
   users a chance to start a new scene without a gap.  Users need to call the
   idle command (the duration can be 0) to turn off the stimuli (by present a
   blank screen), if they don't need to run another scene after a FrameCounter
   scene.

 - AndAdapter, OrAdapter and NotAdapter are modified, to make them act as
   described in the manual.

----------

The packages are updated without changing the version number, to include the PDF manual.

ftp://helix.nih.gov/lsn/monkeylogic/NIMH_MonkeyLogic_2_(May-21-2018).mlappinstall

ftp://helix.nih.gov/lsn/monkeylogic/NIMH_MonkeyLogic_2_(May-21-2018).zip

 
Attached Files
zip NIMH_MonkeyLogic_2_(May-21-2018).zip (29.86 MB, 0 views)

0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.