Debugging TestMode

Known Issues and Problems with BCI2000
Locked
Kalvin
Posts: 14
Joined: 02 Sep 2011, 05:06

Debugging TestMode

Post by Kalvin » 02 Feb 2012, 19:50

I have been using version 3684 (stable release, as far as I remember) for application development. It looks as if the P300Speller's TestMode (clicking on targets to select them) is not working in this version, or in my modified code version.

Some key settings:
* online free mode
* display text result
* TestMode

I included AppLog outputs in the click processing section of P3SpellerTask.cpp | OnClassResult() :

Code: Select all

  while( !Display().ObjectsClicked().empty() )
  {
    AppLog << "Clicks were detected. \n";
    Stimulus* pStimulus = dynamic_cast<Stimulus*>( Display().ObjectsClicked().front() );

    if( pStimulus != NULL ){
      pClickedStimulus = pStimulus;
	  AppLog << "Selected stimulus tag: " << pClickedStimulus->Tag() << "\n";
	} else {
	  AppLog << "pStimulus is NULL.\n";
	}
    Display().ObjectsClicked().pop();
  }
example output:
Clicks were detected.
pstimulus is NULL.
Clicks were detected.
pstimulus is NULL.
I would like to solve this issue in my local code version. How should I best go on from here?

mellinger
Posts: 1341
Joined: 12 Feb 2003, 11:06

Re: Debugging TestMode

Post by mellinger » 03 Feb 2012, 09:08

r3684 was not a stable release -- I assume you refer to r3604 which corresponds to the 3.0.3 release (see http://www.bci2000.org/wiki/index.php/B ... n_3_Builds for a list of releases, and their corresponding SVN revisions).

P3Speller test mode was actually broken in r3604, and has been fixed in r3616:
http://www.bci2000.org/tracproj/changeset/3616

A 3.0.4 patch release has just been built from r3798, I suggest that you update your source code to that version because it contains a number of additional bug fixes. It should also be easy to merge your changes with the minor modifications that occurred in the P3SpellerTask code. If you want to avoid that, you will also be able to use your old P3SpellerTask version with the updated framework.

In case you have modifications in framework code (which is generally not a good idea; one should rather derive one's own classes from framework classes, and implement modified behavior there, and if that's not possible, make a copy of the class in question and rename it), then you might use the command line SVN client to merge the changes from changeset 3616 into your local copy.

With a recent SVN command line client, you would go to your BCI2000 directory, and execute
svn diff -c 3616 http://www.bci2000.org/svn/trunk > r3616.diff
svn patch r3616.diff

With TortoiseSVN, the procedure is a bit more complicated:
*Right-click your desktop, and select "TortoiseSVN->Repo Browser" from the context menu.
*In the dialog window, enter http://www.bci2000.org/svn/trunk as the repository path.
*Once the repository browser displays the repository on the BCI2000 server, right-click somewhere in the browser window, and select "Show Log" from the context menu.
*In the log window, click the "Show next 100" button at the bottom, navigate to revision 3616, and right-click on it.
*From the context menu, choose "Show changes as unified diff".
*In the TortoiseDiff viewer, press ctrl-a ctrl-c to copy the contents into the clipboard. Start notepad, insert from the clipboard, and save as "r3616.diff".
*Right-click your BCI2000 source code directory, and choose "Apply Patch" from the context menu.
*In the file open dialog, select the previously save "r3616.diff" file.
*In the TortoiseMerge program, you will see a floating window containing the files to be modified. Right-click and choose "Patch all".
*Close the TortoiseMerge program.

Your source code will now contain the changes between r3615 and r3616.

Regards,
Juergen

Kalvin
Posts: 14
Joined: 02 Sep 2011, 05:06

Re: Debugging TestMode

Post by Kalvin » 03 Feb 2012, 21:39

Thanks a lot for the immediate (and helpful) response! It was indeed r3604 (sorry for the typo).

I applied the diff-ed changes. The application now detects clicks, but their tag() currently will always be 0:
Clicks were detected.
Clicked stimulus tag: 0
Clicks were detected.
Clicked stimulus tag: 0
Do you know what might have gone wrong here?

I will update to the latest stable release otherwise (if there is no good solution). There shouldn't be problems with a (copied) version of my P3Speller.cpp (where I had applied most changes).

Kalvin
Posts: 14
Joined: 02 Sep 2011, 05:06

Re: Debugging TestMode

Post by Kalvin » 05 Feb 2012, 06:27

I updated to the latest release yesterday.. This didn't solve the problem either, unfortunately. Still only 0 tags.

mellinger
Posts: 1341
Joined: 12 Feb 2003, 11:06

Re: Debugging TestMode

Post by mellinger » 06 Feb 2012, 07:33

Stimuli are not tagged by the P3Speller code, only targets are tagged. Stimuli are objects that know how to present themselves, and targets are objects that know how to react when being selected. The relation between stimuli and targets is established via "associations", which are containers that contain both stimuli and targets, and which associate both with a "stimulus code". In the P3Speller, each matrix element corresponds to a single stimulus, and to a single target; each association corresponds to a single row or column of that matrix.

When you want to read out tags from stimuli, you need to set these tags inside the LoadMenu() function.

Juergen

Kalvin
Posts: 14
Joined: 02 Sep 2011, 05:06

Re: Debugging TestMode

Post by Kalvin » 06 Feb 2012, 18:15

Ok, but this description sounds to me as if the TestMode of the P3Speller does not work "out of the box" in these new versions I updated the code to (..if I need to add more code to the LoadMenu() function to make it work). I am therefore not sure whether I described the new problem correctly:

I used the code in the initial message in this thread to produce the output contained the second message. The second part of this code section in OnClassResult(), where fake results are created for the click stimuli:

Code: Select all

  Target* pTarget = NULL;
  if( mTestMode && pClickedStimulus != NULL )
  { // Fake an ideal ERP result, i.e. a binary response to the clicked stimulus.
    // This allows for testing result processing as well.

    AppLog << "Creating fake ERP result \n";

    ClassResult fakeResult;
    GenericSignal fakeSignal( 1, 1 );
    for( AssociationMap::const_iterator i = Associations().begin();
                                        i != Associations().end(); ++i )
    {
      fakeSignal( 0, 0 ) =  i->second.Contains( pClickedStimulus );
      fakeResult[ i->first ].push_back( fakeSignal );
    }
    pTarget = Associations().ClassifyTargets( fakeResult ).MostLikelyTarget();
	if (pTarget != NULL) {
		AppLog << "Clicked target tag: " << pTarget->Tag() << "\n";
	} else {
		AppLog << "pTarget is NULL \n";
	}
  } else {
    pTarget = Associations().ClassifyTargets( inResult ).MostLikelyTarget();
  };
...will now produce this result (using the AppLog output of both code snippets I posted in this thread):
Clicks were detected.
Clicked stimulus tag: 0
Clicks were detected.
Clicked stimulus tag: 0Creating fake ERP result
pTarget is NULL
..so Clicks are detected, but the pTarget associations are NULL here. I hope that my P3Speller modifications didn't break anything here.

Kalvin
Posts: 14
Joined: 02 Sep 2011, 05:06

Re: Debugging TestMode

Post by Kalvin » 07 Feb 2012, 00:42

I forgot to include a part of the LoadMatrix()-Code into the function that changes my matrix (the 4 lines that create and attach the AudioSpellerTarget). TestMode ist working fine now again.

Locked

Who is online

Users browsing this forum: No registered users and 0 guests