Hi Dave, Chris,
While running an experiment that contains a custom-built stimulus plugin, I ran into a weird anomaly. My stimulus plugin creates random apertures placed on an image. When I tried to reconstruct the apertures from streamed data files, I observed that the reconstructed ones differ drastically from screen snapshots of corresponding trials!
The issue persists even when I set always_display_mirror_window in the variable set. Oddly enough, the appearance on two screens differed: The stimulus that was shown on the small mirror window matched the reconstructed stimuli, whereas the stimulus on the external monitor (full screen) did not.
This problem arises only with the recent versions of MW (0.45 nightly build). In the previous version (0.44), this issue did not exist.
The issue is not specific to our plugin: in our lab, we experienced a similar issue when we ran an experiment having DisplayBitCodeStimulus plugin.
I wonder why we experience such an issue and how I may fix it. Any help is highly appreciated.
Best,
Alireza
Hi Alireza,
I’d like to help, but you haven’t provided much information. Can you explain how the stimuli “differ drastically” between MWorks versions?
Also, are you really using a 0.4.5 nightly build? MWorks 0.4.5 was released over a year ago, so a 0.4.5 nightly would be quite old at this point. Or are you using a recent (0.5) nightly?
Thanks,
Chris
Could you also tell us where/when the DisplayBitCodeStimulus plugin came from? As far as I know, that isn’t part of the “main” distribution, so it probably came from my lab… but the version you have is likely out of date / incompatible.
If I were guessing in the dark, I’d say that you’re probably doing random draws on stimulus draw, so you’re getting different draws for the main display and the mirror display.
Hi Chris, Dave,
I appreciate a lot your replies and sorry for not being clear enough.
Our plugin creates occluding masks containing transparent circular apertures.
The centers of these apertures are chosen randomly each time the mask is created. The mask makes the stimulus behind it partially visible. By “differing drastically” I mean the center of apertures are totally different in two screens when the mirror_screen is set. In the case of using just one monitor, this difference is between the reconstructed masks and the snapshot of the mask during running the experiment. Again the configurations of the apertures are totally different.
Regarding the version, I am using the version which is a Nightly build of 21Mar2012 (I thought it is still v0.45).
Regarding the DisplayBitCodeStimulus, yes it is from your lab, Dave. The version we have is cloned from your lab about 2 years ago. But it is still working with MW v0.45. Though we have not tested it with the recent Nightly build versions.
About your guess, Dave: I did not seem to understand what you mean by “random draws”. It does not seem to explain the reason why even when we have just one monitor, the the reconstructed masks differ from the screen snapshots.
My guess, given the fact that the plugins used to work fine under the 0.4.4 versions (not having this issue at all), is that the problem must stems from the changes in the transition from version 0.4.4 to 0.4.5 (or 0.5) for example elimination of frozen or changes in the constructor model.
Thanks again,
Alireza
Hi Dave,
let me add some more details about the DisplayBitCodeStimulus plugin. We cloned it from your rep last year, probably in March 2011. When we run it we saw that, if the mirror monitor was on, the bits displayed in the main (external) monitor were different from the bits displayed in the mirror monitor. The actual BitCode variable (the decimal number corresponding to the bits) was consistent with the bits shown on the mirror monitor.
When we shut off the mirror monitor, the BitCode became consistent with the external monitor. We did not perform any more tests, since we switched to a different way to sync MW with the TDT acquisition system.
But, when Alireza reported to me his problem with his bubbles mask plugin, this reminded me of what we observed with the DisplayBitCodeStimulus plugin. Two different masks are shown in the main monitor and in the mirror monitor. The fact is that the problem with our plugin is even more severe. Even if Alireza turns off the mirror monitor, the masks shown in the main monitor keeps being inconsistent with the mask parameters saved in the MW data file (it is like if a ghost mirror monitor was actually on and the recorded mask parameters referred to this ghost monitor rather than to what is displayed on the real monitor).
We did not try any new version of your DisplayBitCodeStimulus plugin. Since I assume that you must have fixed the problem there, would it be a good strategy for Alireza to look into your more recent DisplayBitCodeStimulus code to figure out how to change his bubble mask plugin? Otherwise, do you have any other suggestion?
Thanks
davide
PS: You still have access to Alireza’s plugin (https://github.com/zoccolan/bubble_plugin_MW4.5). Perhaps you may give it a look if you have some time.
Davide,
Yes, you should look at what changed in the DisplayBitcode stimulus to see what you might need to change in your own plugin.
Let me know if you don’t have access to the relevant repo.
Dave
Hi Dave,
I am trying to compile the most recent version of DisplayBitcode plugin to see if the issue we had exists in this version of the plugin.
There are some errors: two header files Zmq.hpp & Pixel_clock_info.pb.h cannot be found.
I wonder where I can find those header files.
Thanks in advance,
Alireza
Alireza,
Zmq.hpp comes from the zeromq library, and the .pb.h file would be auto-generated by the protobuf (Google Protocol Buffers) package, if you had it installed.
There are a variety of ways to get each, but the easiest is with homebrew:
brew install zmq
brew install protobuf
Hi Dave,
Thanks for your reply. There are no errors regarding zmq, protobuf anymore.
But I got a very strange error:
/opt/local/include/gcc43/c++/gcj/javaprims.h:19:0 Gcj/libgcj-config.h: No such file or directory in /opt/local/include/gcc43/c++/gcj/javaprims.h
I added manually the the path “/opt/local/lib/gcc43/gcc/x86_64-apple-darwin10/4.3.6/include/” and fixed the problem.
But now I have got thousands of errors of the kind :/opt/local/include/gcc43/c++/tr1_impl/cstdint:43:0 /opt/local/include/gcc43/c++/tr1_impl/cstdint:43: error: ‘::int8_t’ has not been declared
also “‘::int16_t’ not being declared” , so on so foth…
I have the feeling it might be related to gcc version I am using. I wonder if you could give me a hint.
Thanks,
Alireza
Alireza,
Hmm… gcj and your first errors have to do with Java stuff, and I have no idea why these would be there. Also, the /opt path suggests macports… how is that getting into the project?
Dave,
Sorry about previous confusing errors! I think the problem was the version of MWorks. I downloaded the recent version nightly build (‘MWorks-NIGHTLY-no_gl_fence.dmg’ 22May) and now those errors are gone!
But I see now new errors of this form:
/Library/Application Support/MWorks/Developer/include/boost/fusion/container/list/cons_fwd.hpp:13:0 /Library/Application Support/MWorks/Developer/include/boost/fusion/container/list/cons_fwd.hpp:13: error: expected identifier before ‘__null’
Seems related to the boost. Any idea what might be the cause?
Another thing is about the nightly build of 22May. I do not seem to be able to download it (it is size is zero on the website!). I instead downloaded ‘MWorks-NIGHTLY-no_gl_fence.dmg’. I am not sure if this version is suitable for my purpose.
About Davide’s comment: I installed protobuf & zmq using macport instead of homebrew. I do not think that is a problem since those errors are gone. If that is not the case, please let me know.
Alireza
Another thing is about the nightly build of 22May. I do not seem to be able to download it (it is size is zero on the website!). I instead downloaded ‘MWorks-NIGHTLY-no_gl_fence.dmg’. I am not sure if this version is suitable for my purpose.
Sorry about that. The nightly build failed last night, and the previous night’s installer package was overwritten with an empty one. I just kicked off a new build. Assuming it doesn’t also fail, it should be ready in about 40 minutes.
The no_gl_fence package was for a user testing some features that aren’t yet in the nightly. I don’t recommend using it.
Chris
Sorry about that. The nightly build failed last night, and the previous night’s installer package was overwritten with an empty one. I just kicked off a new build. Assuming it doesn’t also fail, it should be ready in about 40 minutes.
Thanks Chris,
I installed that version but I still have the same errors related to Boost of this type:
/Library/Application Support/MWorks/Developer/include/boost/fusion/container/list/cons_fwd.hpp:13:0 /Library/Application Support/MWorks/Developer/include/boost/fusion/container/list/cons_fwd.hpp:13: error: expected identifier before ‘__null’
Dave, I was wondering if you could send me the bundle of the Bitcode plugin. That might be an easier way to test wether the current version of the plugin has the same issue (observing different things on two monitors) or not.
Alireza
Hey,
The issue is with the version of boost included with the latest
nightly. The boost developers have a penchant for using variables
called things like “nil”, which is a keyword in ObjC/ObjC++. That’s an
esp. big problem these days because of the popularity of iOS
I’m guessing you’re seeing this because you’re using boost.random,
which now depends on boost.fusion, I believe, which has “nil” in it.
The simplest fix is to downgrade your boost version. Chris: was there
some compelling feature that led to the upgrade?
Dave
Sent from my iPhone
Hi Dave,
would it be possible for you to send to Alireza the BitCode plugin itself (I mean the compiled .bundle file)? So he can at least try to see how it works.
Also, can you confirm that the up-to-date source code for the plugin is here: coxlab_mwcore_plugins/DisplayBitCodeStimulus at master · coxlab/coxlab_mwcore_plugins · GitHub
Thanks
davide
The simplest fix is to downgrade your boost version.
Thanks Dave. Following your suggestion, I managed to compile the plugin.
Alireza
Hi Dave,
Yes, you should look at what changed in the DisplayBitcode stimulus to see what you might need to change in your own plugin.
I examined the DisplayBitCodeStimulus plugin but I do not seem to find what exactly would be the fix for the dual monitor discrepancy issue. I have the suspicion that one change might be relevant. But not sure what in fact it means.
The use of ClockSync class and the following code:
shared_ptr<VariableRegistry> registry = global_variable_registry;
shared_ptr<Variable> display_update_variable = registry->getVariable("#stimDisplayUpdate");
if(clock_offset_variable != NULL){
clock_sync = shared_ptr<ClockSync>(new ClockSync((long)n_markers_variable->getValue(),
"tcp://127.0.0.1",
code_variable,
display_update_variable,
clock_offset_variable) );
Could you please comment on that?
Alireza