installation probs

1
new computer. matlab 2012b. 64-bit mac running mountain lion. tried
running the latest DownloadPsychToolbox.m
got this:

>> DownloadPsychtoolbox
DownloadPsychtoolbox('/Applications','beta','')
Requested flavor is: beta
Requested location for the Psychtoolbox folder is inside: /Applications

Will use the svn client which is located in this folder: /usr/local/bin/
Good. Your privileges suffice for the requested installation into folder
/Applications.

I will now download the latest Psychtoolbox for OSX.
Requested flavor is: beta
Target folder for installation: /Applications
The following CHECKOUT command asks the Subversion client to
download the Psychtoolbox:
/usr/local/bin/svn checkout
https://github.com/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox
/ "/Applications/Psychtoolbox"
Downloading. It's nearly 100 MB, which can take many minutes.
Alas there may be no output to this window to indicate progress until the
download is complete.
Please be patient ...
If you see some message asking something like "accept certificate
(p)ermanently, (t)emporarily? etc."
then please press the p key on your keyboard, possibly followed by
pressing the ENTER key.

Error validating server certificate for 'https://github.com:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: github.com
- Valid: from May 27 00:00:00 2011 GMT until Jul 29 12:00:00 2013 GMT
- Issuer: www.digicert.com, DigiCert Inc, US
- Fingerprint: ce:67:99:25:2c:ac:78:12:7d:94:b5:62:2c:31:c5:16:a6:34:73:53
(R)eject, accept (t)emporarily or accept (p)ermanently? p
subversion/libsvn_ra_dav/util.c:826: (apr_err=175002)
svn: PROPFIND request failed on
'/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox'
subversion/libsvn_ra_dav/util.c:296: (apr_err=175002)
svn: PROPFIND of
'/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox': Could not
read status line: Secure connection truncated (https://github.com)
Sorry, the download command "CHECKOUT" failed with error code 1:
For reason, see output above.
The download failure might be due to temporary network or server problems.
You may want to try again in a
few minutes. It could also be that the subversion client was not
(properly) installed. On Microsoft
Windows you will need to exit and restart Matlab or Octave after
installation of the Subversion client. If that
does not help, you will need to reboot your machine before proceeding.
Another reason for download failure could be if an old working copy - a
Psychtoolbox folder - still exists.
In that case, it may help to manually delete that folder. Or maybe you do
not have write permissions for the target folder?

Error using DownloadPsychtoolbox (line 765)
Download failed.

ideas?

--
Joshua A. Solomon
http://www.staff.city.ac.uk/~solomon
2
> The download failure might be due to temporary network or server problems.
> You may want to try again in a
> few minutes.

https://status.github.com/messages


--- In psychtoolbox@yahoogroups.com, "Solomon, Joshua" <J.A.Solomon@...> wrote:
>
> new computer. matlab 2012b. 64-bit mac running mountain lion. tried
> running the latest DownloadPsychToolbox.m
> got this:
>
> >> DownloadPsychtoolbox
> DownloadPsychtoolbox('/Applications','beta','')
> Requested flavor is: beta
> Requested location for the Psychtoolbox folder is inside: /Applications
>
> Will use the svn client which is located in this folder: /usr/local/bin/
> Good. Your privileges suffice for the requested installation into folder
> /Applications.
>
> I will now download the latest Psychtoolbox for OSX.
> Requested flavor is: beta
> Target folder for installation: /Applications
> The following CHECKOUT command asks the Subversion client to
> download the Psychtoolbox:
> /usr/local/bin/svn checkout
> https://github.com/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox
> / "/Applications/Psychtoolbox"
> Downloading. It's nearly 100 MB, which can take many minutes.
> Alas there may be no output to this window to indicate progress until the
> download is complete.
> Please be patient ...
> If you see some message asking something like "accept certificate
> (p)ermanently, (t)emporarily? etc."
> then please press the p key on your keyboard, possibly followed by
> pressing the ENTER key.
>
> Error validating server certificate for 'https://github.com:443':
> - The certificate is not issued by a trusted authority. Use the
> fingerprint to validate the certificate manually!
> Certificate information:
> - Hostname: github.com
> - Valid: from May 27 00:00:00 2011 GMT until Jul 29 12:00:00 2013 GMT
> - Issuer: www.digicert.com, DigiCert Inc, US
> - Fingerprint: ce:67:99:25:2c:ac:78:12:7d:94:b5:62:2c:31:c5:16:a6:34:73:53
> (R)eject, accept (t)emporarily or accept (p)ermanently? p
> subversion/libsvn_ra_dav/util.c:826: (apr_err=175002)
> svn: PROPFIND request failed on
> '/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox'
> subversion/libsvn_ra_dav/util.c:296: (apr_err=175002)
> svn: PROPFIND of
> '/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox': Could not
> read status line: Secure connection truncated (https://github.com)
> Sorry, the download command "CHECKOUT" failed with error code 1:
> For reason, see output above.
> The download failure might be due to temporary network or server problems.
> You may want to try again in a
> few minutes. It could also be that the subversion client was not
> (properly) installed. On Microsoft
> Windows you will need to exit and restart Matlab or Octave after
> installation of the Subversion client. If that
> does not help, you will need to reboot your machine before proceeding.
> Another reason for download failure could be if an old working copy - a
> Psychtoolbox folder - still exists.
> In that case, it may help to manually delete that folder. Or maybe you do
> not have write permissions for the target folder?
>
> Error using DownloadPsychtoolbox (line 765)
> Download failed.
>
> ideas?
>
> --
> Joshua A. Solomon
> http://www.staff.city.ac.uk/~solomon
>
3
On 30/12/2012 22:11, "Mario" <mario.kleiner@...> wrote:


>You can also get it directly from GitHub

that worked, thanks. problems persist, however:

>> DriftDemo6


PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit
(Version 3.0.10 - Build date: Oct 29 2012).
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you
under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox
root folder for the exact licensing conditions.

PTB-INFO: Broken Apple OS/X 10.7 or later detected: Using CoreVideo
timestamping instead of precise vbl-irq timestamping.

PTB-WARNING: Querying rasterbeam-position doesn't work on your setup!
(Returns a constant value 1800)
PTB-WARNING: This can happen if Psychtoolbox gets the mapping of connected
displays to graphics card
PTB-WARNING: outputs wrong. See 'help DisplayOutputMappings' for tips on
how to resolve this problem.



PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA GeForce GT 650M
OpenGL Engine :: 2.1 NVIDIA-8.6.22
PTB-INFO: Renderer has 1024 MB of VRAM and a maximum 991 MB of texture
memory.
PTB-INFO: VBL startline = 900 , VBL Endline = -1
PTB-INFO: Beamposition queries unsupported on this system. Will try to use
kernel-level vbl interrupts as fallback.
PTB-INFO: Measured monitor refresh interval from VBLsync = 16.683959 ms
[59.937813 Hz]. (299 valid samples taken, stddev=0.712099 ms.)
PTB-INFO: Small deviations between reported values are normal and no
reason to worry.


----- ! PTB - WARNING: SYNCHRONIZATION TROUBLE ! ----

One or more internal checks (see Warnings above) indicate that
queries of rasterbeam position are not properly working for your setup.

Psychtoolbox will work around this by using a different timing algorithm,
but it will cause Screen('Flip') to report less accurate/robust timestamps
for stimulus timing.
Read 'help BeampositionQueries' for more info and troubleshooting tips.


PTB-INFO: Support for fast OffscreenWindows enabled.
Building a fragment shader:Reading shader from file
/Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur
eShader.frag.txt ...
Building a vertex shader:Reading shader from file
/Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur
eShader.vert.txt ...


INFO: PTB's Screen('Flip', 10) command seems to have missed the requested
stimulus presentation deadline
INFO: a total of 297 times out of a total of 297 flips during this session.

INFO: This number is fairly accurate (and indicative of real timing
problems in your own code or your system)
INFO: if you provided requested stimulus onset times with the 'when'
argument of Screen('Flip', window [, when]);
INFO: If you called Screen('Flip', window); without the 'when' argument,
this count is more of a ''mild'' indicator
INFO: of timing behaviour than a hard reliable measurement. Large numbers
may indicate problems and should at least
INFO: deserve your closer attention. Cfe. 'help SyncTrouble', the FAQ
section at www.psychtoolbox.org and the
INFO: examples in the PDF presentation in
PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips.

(end of DriftDemo6 output)


note that after the exclamation point, which i assume accompanies the "PTB
- WARNING," i saw DriftDemo6's two gratings and they looked OK.
nonetheless, as suggested, i tried

>> help DisplayOutputMappings
DisplayOutputMappings -- How they work, how to resolve problems.

You probably read this text, because Screen() gave you some error or
warning message about problems with beamposition queries or other
low-level functions and directed you to this document for
troubleshooting.

So, what happened here?

For various low-level operations, e.g., beamposition queries for
timestamping, control of high precision framebuffers and high precision
display devices, and for certain stereo display modes, Screen() needs to
know which video output connector on your graphics card is connected to
which electronic display scanout engine (a so called "crtc") in the
graphics card, because it needs to exercise low-level control over the
crtc associated with a specific display. The actual wiring between crtc's
and display connectors however is not fixed on modern graphics cards, but
it is flexible. The wiring is controlled by electronic programmable
switches, so called multiplexers ("MUXers"), which are configured by the
operating system and graphics card driver. Depending on the specific
hardware, operating system and display setup, the wiring can change
dynamically.

You can find more technical details at the following links if you are
interested: <http://www.botchco.com/agd5f/?p=51> for AMD/ATI hardware,
and <http://virtuousgeek.org/blog/index.php/jbarnes/2011/01/> for Intel
hardware.


Sometimes, due to operating system or graphics driver bugs, or system
misconfiguration, the operating system "lies" to Screen() about the true
wiring. On some systems, the operating system can't tell Screen() about
the
wiring and Screen() has to make an educated guess based on some
heuristics - a guess which can go wrong.

Long story short, Screen() can be wrong about which crtc to access for a
given display, causing the kind of malfunctions, warnings and errors
messages that brought you to this help text. To fix such problems you
need to help Screen() in one of multiple different ways:

1. On MS-Windows, try to update your graphics driver in the hope that
this fixes the problem. Don't forget to reboot!

2. If this doesn't help, or if you are on Linux or OS/X, try to replug
the displays into different video output connectors on your computer.
E.g., on a single monitor setup, plug the monitor into the other video
output connector. On a dual-display setup, exchange which monitor is
plugged into which connector etc. This replugging will make reality
match the expectations of Screen(). Don't forget to restart Matlab or
Octave after the change.

3. If 2. doesn't help or is infeasible or problematic, you can also tell
Screen() about the true wiring by adding the command
Screen('Preference', 'ScreenToHead', screen, head, crtc[, rank]); to
the
top of your script, before other Screen() commmands:

On OS/X or Windows, Screen('Preference', 'ScreenToHead', 0, 1, 1);
would tell Screen() that the Psychtoolbox screen with screenid 0 is
not connected to video output 0 and crtc 0 (as would be the default),
but to video output 1 and crtc 1.

On Linux the same logic applies. However, on Linux, multiple video
outputs (and thereby display monitors) can be connected to one single
Psychtoolbox screenid (aka X-Window system X-Screen) to allow for more
flexibility than on the other systems. For this reason an additional
'rank' parameter controls which of multiple possible outputs per
screen is remapped. The default 'rank' of 0 refers to the primary
display output, the one which is used for stimulus onset timestamping
or framerate queries. It may therefore be neccessary to play with the
'rank' parameter as well on multi-display setups with multiple
monitors per Psychtoolbox screen.

4. If you have a multi-GPU setup, ie., multiple graphics cards installed
and active at the same time, then Screen() low-level functions may
not work. More precisely, they will not work at all on MS-Windows or
Apple OS/X. On Linux you can make them work on exactly one GPU, the
other GPU's will be ignored. By default, the first GPU in the system
is chosen. You can override the choice by setting a Unix environment
variable PSYCH_USE_GPUIDX, e.g., the command...
export PSYCH_USE_GPUIDX=1 ; matlab
... would start Matlab and instruct Screen() to use the GPU with index
1, which is the 2nd GPU in the system, as numbering starts with zero
for the 1st GPU.


Good luck with troubleshooting!

(end of help DisplayOutputMappings output)


note that neither 1, 2, nor 3 (above) seem to apply, because i'm using a
MacBook Pro that isn't connected to anything else. 4 (above) says it
doesn't work on OS/X. so i then tried

>> help BeampositionQueries
BeampositionQueries -- What they are used for, and what can go wrong.

MacOS-X and M$-Windows provide a mechanism that allows to query the
scanline which is currently updated by the scanning beam of a CRT
display or by the equivalent mechanism in a video beamer or flat
panel display, the so called "beamposition".

We use this mechanism for two purposes:

1. Independent measurement of the monitor refresh interval: Psychtoolbox
executes a measurement loop during Screen('OpenWindow') where it
determines
the monitor refresh interval. It takes a timestamp whenever the
beamposition
resets to zero at the start of a new display refresh cycle. The
difference
between consecutive timestamps is a sample of refresh duration. The
samples
of 50 consecutive refresh cycles are averaged. The "length" of the VBL
is also computed as the difference between screen height (e.g., 1024 at a
display resolution of 1280 x 1024 pixels) and the highest scanline value
encountered during the 50 refresh cycles.

This measurement is used to cross-check the results of the
synchronization tests
(see 'help SyncTrouble') and the value provided by the operating system
to
make the sync tests and display calibration as robust as possible, even
if the operating system reports bogus values like 0 Hz, which can happen
on MacOS-X and Windows with some flat panels.

2. Highly accurate and robust stimulus onset timestamps in
Screen('Flip').

In normal operation, the Screen('Flip') command, after issuing a
buffer-swap
request to the gfx-hardware, pauses execution until the operating system
signals swap-completion in sync with vertical retrace. Then it takes a
high-
precision system timestamp. Due to the scheduling jitter present in any
operating system, sometimes the execution of Psychtoolbox is resumed
only after
some random multi-millisecond delay has passed after buffer-swap, so the
stimulus onset timestamp can be possibly off by multiple milliseconds
from
the real stimulus onset time. This is unwanted timing noise, especially
if
the time stamp is to be used for either computing stimulus onset time for
future stimuli, or for synchronizing Psychtoolbox execution with other
stimulus generators or acquisition hardware.

On Microsoft Windows 2000 and later, there is experimental support for
beamposition queries. This support is only enabled on single display
setups
and multi-display setups which are configured to appear to Psychtoolbox
as
single-display setups, i.e., one "virtual" primary monitor which consists
of multiple real displays in horizontal spanning mode. We use this
mechanism
to get high precision time stamps as the ones described below for
MacOS-X.

On GNU/Linux, timing precision even in non-realtime scheduling mode is
far
superior to all other operating systems, yielding a timing jitter of less
than 100 microseconds under normal operating conditions. For special
needs,
there exist multiple methods of improving timing down to microsecond
level,
although some of time require some advanced programming skills. If
Psychtoolbox runs on an ATI graphics card of the X1000 series or HD xxxx
series and Matlab/Octave is run with superuser privileges, Psychtoolbox
will also utilize beamposition queries for even better timing precision.
On other graphics cards, this is not yet supported.

On MacOS-X, whose timing accuracy is somewhere between Linux and Windows,
and luckily closer to Linux timing than to Windows timing, we use
beamposition
queries to improve accuracy of our timestamps, either with the native
support
on PowerPC computers and IntelMacs with NVidia or Intel graphics, or
with the
help of the PsychtoolboxKernelDriver (see help PsychtoolboxKernelDriver)
on
cards from ATI. An alternative mechanism, based on vertical blank
interrupts, is implemented on OS/X, should the beamposition mechanism
malfunction or become unavailable.

This is how beamposition queries are used:

When taking the system timestamp, we also query the current rasterbeam
position.
From the known height of the display (in scanlines, including height of
VBL),
and the known refresh interval of our display, we can translate the
current
beam position into "elapsed time since start of VBL == elapsed time since
double buffer swap". By subtracting this elapsed time value from our
system
timestamp, we get a corrected timestamp - the real system time of double
buffer
swap == start of VBL == aka stimulus onset. This allows for very
accurate timestamps,
despite possible non-deterministic multi-millisecond timing jitter.
Psychtoolbox
goes through great pains during startup to double-check that all required
calibration values and mechanisms are accurate and working properly.
You can assess the accuracy of all returned timestamps by use of the
script
VBLSyncTest. A visual correctness test is provided by
PerceptualVBLSyncTest.
PTB also performs continuous runtime checking to detect possible problems
caused by defective graphics card drivers.

In case that beamposition queries should not work properly or are not
supported,
PTB will use different fallback strategies:

On Microsoft Windows, only a normal - possibly noisy - timestamp is
taken.

On MacOS-X, PTB tries to get low-level access to the kernel interrupt
handlers
for the VBL interrupts and uses its values for timestamping the time of
buffer-
swap. This method is slightly less accurate and robust than the
bemposition method,
but should be still suitable for most applications. If the kernel-level
queries should
fail as well, PTB falls back to pure timestamping without any correction.

The behaviour of PTB can be controlled by the command:
Screen('Preference', 'VBLTimestampingMode', mode); where mode can be one
of the
following:

-1 = Disable all cleverness, take noisy timestamps. This is the behaviour
you'd get from any other psychophysics toolkit, as far as we know.
0 = Disable kernel-level fallback method (on OS-X), use either
beamposition
or noisy stamps if beamposition is unavailable.
1 = Use beamposition. Should it fail, switch to use of kernel-level
interrupt
timestamps. If that fails as well or is unavailable, use noisy
stamps.
2 = Use beamposition, but cross-check with kernel-level timestamps.
Use noisy stamps if beamposition mode fails. This is for the
paranoid
to check proper functioning.
3 = Always use kernel-level timestamping, fall back to noisy stamps if
it fails.
4 = Use OpenML OML_sync_control extension for high-precision
timestamping on
supported system configuration. This is currently a Linux only
feature on
some specific systems. It is considered experimental for now.

The default on OS-X, Linux and Windows with single display setups is
"1". On Windows in
explicit multi-display mode, we default to "-1" ie. noisy timestamps if
you
are running Psychtoolbox under a Matlab version older than R2007a, as
the current
beamposition mechanism is not capable of supporting multi-display setups
due to some limitations imposed by old Matlab versions. On modern
Matlab's or Octave, the accurate mode "1" is used as well. On Linux and
OS/X
the accurate mode "1" is also used on multi-display setups.

If the beampos query test fails, you will see some warning message about
"SYNCHRONIZATION TROUBLE" in the Matlab/Octave command window or other
error messages, as diagnostics is performed at various stages of setup
and operation.

There are two possible causes for failure:

1. System overload: Too many other applications are running in parallel
to
Psychtoolbox, introducing severe timing noise into the calibration and
test loop.
See 'help SyncTrouble' on what to do. This happens rather seldomly.

2. Driver bug: Not much you can do, except submit a bug report to Apple
or Microsoft
for your specific hardware + software setup. This is by far the most
common cause of failure. Psychtoolbox tries to enable work-arounds for
some common problems if possible. Usually you should update your graphics
card driver to see if that resolves the problems.

Note: As of Spring/Summer 2008, many graphics cards + driver combos from
ATI and NVidia on WindowsXP have bugs which cause beamposition queries to
fail in a peculiar way. If PTB detects that failure case, it will enable
some workaround to keep the mechanism going at slightly reduced accuracy:
Timestamps will still be mostly jitter-free and consistent, so they are
fully useable for timestamping, timing checks and as a basis for timed
stimulus presentation and animation. However, all returned timestamps
will contain a constant bias wrt. the real stimulus onset time of
somewhere between 20 microseconds and 1.5 milliseconds, depending on your
display settings, because Psychtoolbox can't determine the total height
of your display in scanlines (including the invisible VBL interval)
anymore. Exact height is important for spot-on timestamps. Psychtoolbox
uses some safe, conservative value for its internal computations, so
results will be consistent and useable, but contain a small constant
offset.

In some rare cases, PTB's automatic test fails to detect the bug and
doesn't enable the workaround by itself. You can manually enable the
workaround if you want by adding the setting 4096
(kPsychUseBeampositionQueryWorkaround) to the value x passed via:
Screen('Preference', 'ConserveVRAM', x);

Just insert this command at the top of your scripts before any other
Screen() commands. 'x' must be at least 4096 or the sum of 4096 and any
other values you may want to pass with that command. See "help
ConserveVRAMSettings" for other workarounds that you can enable manually
if needed.

If you want to get rid of that small offset, e.g., because you need to
synchronize with other modalities or stimulation/recording equipment at
sub-millisecond precisison, then you can try to figure out the real
height of the display yourself and tell Psychtoolbox about the true value
before calling Screen('OpenWindow').

Once you know the real height, e.g., VTOTAL, you'd call this function:
Screen('Preference', 'VBLEndlineOverride', VTOTAL);

How to find out about VTOTAL? One way is to search the display control
panel on Windows for some area with "Advanced Timing" or "Custom Timing"
settings. The shareware utility "PowerStrip"
(http://www.entechtaiwan.com/util/ps.shtm)
also allows to change and display these parameters in the Advanced Timing
-> Vertical Geometry -> "Total" field.

Accuracy of beamposition method:

Cross-checking of beamposition timestamps and kernel-level timestamps on
a single
display PowerPC G5 1.6 Ghz under OS-X 10.4.8 with NVidia GeforceFX-5200
showed an
accuracy of beamposition timestamping of better than 100 microseconds,
with a maximum
deviation between the different methods of less than 200 microseconds.

Initial checking on two Window PC's (Dell Inspiron 8000 Laptop, Geforce
2Go, Windows 2000,
and some 3.2 Ghz Pentium-4 with NVidia Geforce 7800 GTX) shows a
precision of about
30 microseconds. No further testing on Windows has been performed yet by
us, but multiple users performed similar testing procedures on their
setups and confirmed the high accuracy and reliability for various MacOSX
and Windows setups.

Also check the FAQ section of http://www.psychtoolbox.org for latest
infos.

(end of help BeampositionQueries output)


note that i'm not quite sure how to update my graphics driver, but the app
store indicates my system software is up-to-date. is there anything else i
should check, or can i just ignore the WARNING and assume that
synchronisation is really fine?
j
--
Joshua A. Solomon
http://www.staff.city.ac.uk/~solomon
4
That's the same as reported by Ian:
<https://gist.github.com/4151623>

Is this a MacBookPro Retina? What is its maximum resolution? Is the display resolution set to maximum or something lower?

If you run BeampositionTest.m, how do the plots look like? Correct would be one plot with a sawtooth pattern, one histogram with somewhat evely filled bins, and two other plots. Bad would be a histogram with all values in the "1800" bin and a plot with a flat constant line at 1800.

The proper way to solve it, assuming it is the OSX graphics driver bug i suspect it is, would be to install the PsychtoolboxKernelDriver ("help PsychtoolboxKernelDriver") on your machine, and then force ptb to use it in each session, by adding a:

v = bitor(2^16, Screen('Preference','ConserveVRAM'));
Screen('Preference','ConserveVRAM', v);

... to the top of each of your scripts - or to the Matlab startup file startup.m

This would force Screen() to use the beamposition mechanism implemented in the PsychtoolboxKernelDriver, instead of the OSX native mechanism which usually gets preferred if both are available, and which is supposedly broken on your machine.

If you don't do this, then PTB will use CoreVideo timestamping instead as a fallback, which is less accurate and robust, and is itself pretty buggy on many Apple machines. I'm contemplating to remove that mechanism completely, given how buggy it is.

Or you just ignore the warnings and live with timestamps that are inacccurate at best or unreliable or totally wrong at worst.

But please provide all info, and the output of Screen('Computer') anyway. Maybe i can find a way for a future beta release to detect the broken MacBookPro's so ptb switches automatically to the kernel driver method.

In general the presentation timing of the Retina MBP's seems to be pretty poor. Both your machine and Ian's machine show very noisy raw measurements. Also the DriftDemo6 seems to miss all presentation deadlines on a task that shouldn't be very taxing on the graphics card. I don't know if it is just a badly implemented graphics driver or if the whole operating system is that noisy, but both of you run 10.8 and timing has degraded with pretty much each OSX release since the golden days of 10.4 when Apple still knew or cared to put attention to technical details other than roundness of round corners on black rectangles.

-mario


--- In psychtoolbox@yahoogroups.com, "Solomon, Joshua" <J.A.Solomon@...> wrote:
>
> On 30/12/2012 22:11, "Mario" <mario.kleiner@...> wrote:
>
>
> >You can also get it directly from GitHub
>
> that worked, thanks. problems persist, however:
>
> >> DriftDemo6
>
>
> PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit
> (Version 3.0.10 - Build date: Oct 29 2012).
> PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
> PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you
> under terms of the MIT License, with
> PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox
> root folder for the exact licensing conditions.
>
> PTB-INFO: Broken Apple OS/X 10.7 or later detected: Using CoreVideo
> timestamping instead of precise vbl-irq timestamping.
>
> PTB-WARNING: Querying rasterbeam-position doesn't work on your setup!
> (Returns a constant value 1800)
> PTB-WARNING: This can happen if Psychtoolbox gets the mapping of connected
> displays to graphics card
> PTB-WARNING: outputs wrong. See 'help DisplayOutputMappings' for tips on
> how to resolve this problem.
>
>
>
> PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA GeForce GT 650M
> OpenGL Engine :: 2.1 NVIDIA-8.6.22
> PTB-INFO: Renderer has 1024 MB of VRAM and a maximum 991 MB of texture
> memory.
> PTB-INFO: VBL startline = 900 , VBL Endline = -1
> PTB-INFO: Beamposition queries unsupported on this system. Will try to use
> kernel-level vbl interrupts as fallback.
> PTB-INFO: Measured monitor refresh interval from VBLsync = 16.683959 ms
> [59.937813 Hz]. (299 valid samples taken, stddev=0.712099 ms.)
> PTB-INFO: Small deviations between reported values are normal and no
> reason to worry.
>
>
> ----- ! PTB - WARNING: SYNCHRONIZATION TROUBLE ! ----
>
> One or more internal checks (see Warnings above) indicate that
> queries of rasterbeam position are not properly working for your setup.
>
> Psychtoolbox will work around this by using a different timing algorithm,
> but it will cause Screen('Flip') to report less accurate/robust timestamps
> for stimulus timing.
> Read 'help BeampositionQueries' for more info and troubleshooting tips.
>
>
> PTB-INFO: Support for fast OffscreenWindows enabled.
> Building a fragment shader:Reading shader from file
> /Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur
> eShader.frag.txt ...
> Building a vertex shader:Reading shader from file
> /Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur
> eShader.vert.txt ...
>
>
> INFO: PTB's Screen('Flip', 10) command seems to have missed the requested
> stimulus presentation deadline
> INFO: a total of 297 times out of a total of 297 flips during this session.
>
> INFO: This number is fairly accurate (and indicative of real timing
> problems in your own code or your system)
> INFO: if you provided requested stimulus onset times with the 'when'
> argument of Screen('Flip', window [, when]);
> INFO: If you called Screen('Flip', window); without the 'when' argument,
> this count is more of a ''mild'' indicator
> INFO: of timing behaviour than a hard reliable measurement. Large numbers
> may indicate problems and should at least
> INFO: deserve your closer attention. Cfe. 'help SyncTrouble', the FAQ
> section at www.psychtoolbox.org and the
> INFO: examples in the PDF presentation in
> PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips.
>
> (end of DriftDemo6 output)
>
>
> note that after the exclamation point, which i assume accompanies the "PTB
> - WARNING," i saw DriftDemo6's two gratings and they looked OK.
> nonetheless, as suggested, i tried
>
> >> help DisplayOutputMappings
> DisplayOutputMappings -- How they work, how to resolve problems.
>
> You probably read this text, because Screen() gave you some error or
> warning message about problems with beamposition queries or other
> low-level functions and directed you to this document for
> troubleshooting.
>
> So, what happened here?
>
> For various low-level operations, e.g., beamposition queries for
> timestamping, control of high precision framebuffers and high precision
> display devices, and for certain stereo display modes, Screen() needs to
> know which video output connector on your graphics card is connected to
> which electronic display scanout engine (a so called "crtc") in the
> graphics card, because it needs to exercise low-level control over the
> crtc associated with a specific display. The actual wiring between crtc's
> and display connectors however is not fixed on modern graphics cards, but
> it is flexible. The wiring is controlled by electronic programmable
> switches, so called multiplexers ("MUXers"), which are configured by the
> operating system and graphics card driver. Depending on the specific
> hardware, operating system and display setup, the wiring can change
> dynamically.
>
> You can find more technical details at the following links if you are
> interested: <http://www.botchco.com/agd5f/?p=51> for AMD/ATI hardware,
> and <http://virtuousgeek.org/blog/index.php/jbarnes/2011/01/> for Intel
> hardware.
>
>
> Sometimes, due to operating system or graphics driver bugs, or system
> misconfiguration, the operating system "lies" to Screen() about the true
> wiring. On some systems, the operating system can't tell Screen() about
> the
> wiring and Screen() has to make an educated guess based on some
> heuristics - a guess which can go wrong.
>
> Long story short, Screen() can be wrong about which crtc to access for a
> given display, causing the kind of malfunctions, warnings and errors
> messages that brought you to this help text. To fix such problems you
> need to help Screen() in one of multiple different ways:
>
> 1. On MS-Windows, try to update your graphics driver in the hope that
> this fixes the problem. Don't forget to reboot!
>
> 2. If this doesn't help, or if you are on Linux or OS/X, try to replug
> the displays into different video output connectors on your computer.
> E.g., on a single monitor setup, plug the monitor into the other video
> output connector. On a dual-display setup, exchange which monitor is
> plugged into which connector etc. This replugging will make reality
> match the expectations of Screen(). Don't forget to restart Matlab or
> Octave after the change.
>
> 3. If 2. doesn't help or is infeasible or problematic, you can also tell
> Screen() about the true wiring by adding the command
> Screen('Preference', 'ScreenToHead', screen, head, crtc[, rank]); to
> the
> top of your script, before other Screen() commmands:
>
> On OS/X or Windows, Screen('Preference', 'ScreenToHead', 0, 1, 1);
> would tell Screen() that the Psychtoolbox screen with screenid 0 is
> not connected to video output 0 and crtc 0 (as would be the default),
> but to video output 1 and crtc 1.
>
> On Linux the same logic applies. However, on Linux, multiple video
> outputs (and thereby display monitors) can be connected to one single
> Psychtoolbox screenid (aka X-Window system X-Screen) to allow for more
> flexibility than on the other systems. For this reason an additional
> 'rank' parameter controls which of multiple possible outputs per
> screen is remapped. The default 'rank' of 0 refers to the primary
> display output, the one which is used for stimulus onset timestamping
> or framerate queries. It may therefore be neccessary to play with the
> 'rank' parameter as well on multi-display setups with multiple
> monitors per Psychtoolbox screen.
>
> 4. If you have a multi-GPU setup, ie., multiple graphics cards installed
> and active at the same time, then Screen() low-level functions may
> not work. More precisely, they will not work at all on MS-Windows or
> Apple OS/X. On Linux you can make them work on exactly one GPU, the
> other GPU's will be ignored. By default, the first GPU in the system
> is chosen. You can override the choice by setting a Unix environment
> variable PSYCH_USE_GPUIDX, e.g., the command...
> export PSYCH_USE_GPUIDX=1 ; matlab
> ... would start Matlab and instruct Screen() to use the GPU with index
> 1, which is the 2nd GPU in the system, as numbering starts with zero
> for the 1st GPU.
>
>
> Good luck with troubleshooting!
>
> (end of help DisplayOutputMappings output)
>
>
> note that neither 1, 2, nor 3 (above) seem to apply, because i'm using a
> MacBook Pro that isn't connected to anything else. 4 (above) says it
> doesn't work on OS/X. so i then tried
>
> >> help BeampositionQueries
> BeampositionQueries -- What they are used for, and what can go wrong.
>
> MacOS-X and M$-Windows provide a mechanism that allows to query the
> scanline which is currently updated by the scanning beam of a CRT
> display or by the equivalent mechanism in a video beamer or flat
> panel display, the so called "beamposition".
>
> We use this mechanism for two purposes:
>
> 1. Independent measurement of the monitor refresh interval: Psychtoolbox
> executes a measurement loop during Screen('OpenWindow') where it
> determines
> the monitor refresh interval. It takes a timestamp whenever the
> beamposition
> resets to zero at the start of a new display refresh cycle. The
> difference
> between consecutive timestamps is a sample of refresh duration. The
> samples
> of 50 consecutive refresh cycles are averaged. The "length" of the VBL
> is also computed as the difference between screen height (e.g., 1024 at a
> display resolution of 1280 x 1024 pixels) and the highest scanline value
> encountered during the 50 refresh cycles.
>
> This measurement is used to cross-check the results of the
> synchronization tests
> (see 'help SyncTrouble') and the value provided by the operating system
> to
> make the sync tests and display calibration as robust as possible, even
> if the operating system reports bogus values like 0 Hz, which can happen
> on MacOS-X and Windows with some flat panels.
>
> 2. Highly accurate and robust stimulus onset timestamps in
> Screen('Flip').
>
> In normal operation, the Screen('Flip') command, after issuing a
> buffer-swap
> request to the gfx-hardware, pauses execution until the operating system
> signals swap-completion in sync with vertical retrace. Then it takes a
> high-
> precision system timestamp. Due to the scheduling jitter present in any
> operating system, sometimes the execution of Psychtoolbox is resumed
> only after
> some random multi-millisecond delay has passed after buffer-swap, so the
> stimulus onset timestamp can be possibly off by multiple milliseconds
> from
> the real stimulus onset time. This is unwanted timing noise, especially
> if
> the time stamp is to be used for either computing stimulus onset time for
> future stimuli, or for synchronizing Psychtoolbox execution with other
> stimulus generators or acquisition hardware.
>
> On Microsoft Windows 2000 and later, there is experimental support for
> beamposition queries. This support is only enabled on single display
> setups
> and multi-display setups which are configured to appear to Psychtoolbox
> as
> single-display setups, i.e., one "virtual" primary monitor which consists
> of multiple real displays in horizontal spanning mode. We use this
> mechanism
> to get high precision time stamps as the ones described below for
> MacOS-X.
>
> On GNU/Linux, timing precision even in non-realtime scheduling mode is
> far
> superior to all other operating systems, yielding a timing jitter of less
> than 100 microseconds under normal operating conditions. For special
> needs,
> there exist multiple methods of improving timing down to microsecond
> level,
> although some of time require some advanced programming skills. If
> Psychtoolbox runs on an ATI graphics card of the X1000 series or HD xxxx
> series and Matlab/Octave is run with superuser privileges, Psychtoolbox
> will also utilize beamposition queries for even better timing precision.
> On other graphics cards, this is not yet supported.
>
> On MacOS-X, whose timing accuracy is somewhere between Linux and Windows,
> and luckily closer to Linux timing than to Windows timing, we use
> beamposition
> queries to improve accuracy of our timestamps, either with the native
> support
> on PowerPC computers and IntelMacs with NVidia or Intel graphics, or
> with the
> help of the PsychtoolboxKernelDriver (see help PsychtoolboxKernelDriver)
> on
> cards from ATI. An alternative mechanism, based on vertical blank
> interrupts, is implemented on OS/X, should the beamposition mechanism
> malfunction or become unavailable.
>
> This is how beamposition queries are used:
>
> When taking the system timestamp, we also query the current rasterbeam
> position.
> From the known height of the display (in scanlines, including height of
> VBL),
> and the known refresh interval of our display, we can translate the
> current
> beam position into "elapsed time since start of VBL == elapsed time since
> double buffer swap". By subtracting this elapsed time value from our
> system
> timestamp, we get a corrected timestamp - the real system time of double
> buffer
> swap == start of VBL == aka stimulus onset. This allows for very
> accurate timestamps,
> despite possible non-deterministic multi-millisecond timing jitter.
> Psychtoolbox
> goes through great pains during startup to double-check that all required
> calibration values and mechanisms are accurate and working properly.
> You can assess the accuracy of all returned timestamps by use of the
> script
> VBLSyncTest. A visual correctness test is provided by
> PerceptualVBLSyncTest.
> PTB also performs continuous runtime checking to detect possible problems
> caused by defective graphics card drivers.
>
> In case that beamposition queries should not work properly or are not
> supported,
> PTB will use different fallback strategies:
>
> On Microsoft Windows, only a normal - possibly noisy - timestamp is
> taken.
>
> On MacOS-X, PTB tries to get low-level access to the kernel interrupt
> handlers
> for the VBL interrupts and uses its values for timestamping the time of
> buffer-
> swap. This method is slightly less accurate and robust than the
> bemposition method,
> but should be still suitable for most applications. If the kernel-level
> queries should
> fail as well, PTB falls back to pure timestamping without any correction.
>
> The behaviour of PTB can be controlled by the command:
> Screen('Preference', 'VBLTimestampingMode', mode); where mode can be one
> of the
> following:
>
> -1 = Disable all cleverness, take noisy timestamps. This is the behaviour
> you'd get from any other psychophysics toolkit, as far as we know.
> 0 = Disable kernel-level fallback method (on OS-X), use either
> beamposition
> or noisy stamps if beamposition is unavailable.
> 1 = Use beamposition. Should it fail, switch to use of kernel-level
> interrupt
> timestamps. If that fails as well or is unavailable, use noisy
> stamps.
> 2 = Use beamposition, but cross-check with kernel-level timestamps.
> Use noisy stamps if beamposition mode fails. This is for the
> paranoid
> to check proper functioning.
> 3 = Always use kernel-level timestamping, fall back to noisy stamps if
> it fails.
> 4 = Use OpenML OML_sync_control extension for high-precision
> timestamping on
> supported system configuration. This is currently a Linux only
> feature on
> some specific systems. It is considered experimental for now.
>
> The default on OS-X, Linux and Windows with single display setups is
> "1". On Windows in
> explicit multi-display mode, we default to "-1" ie. noisy timestamps if
> you
> are running Psychtoolbox under a Matlab version older than R2007a, as
> the current
> beamposition mechanism is not capable of supporting multi-display setups
> due to some limitations imposed by old Matlab versions. On modern
> Matlab's or Octave, the accurate mode "1" is used as well. On Linux and
> OS/X
> the accurate mode "1" is also used on multi-display setups.
>
> If the beampos query test fails, you will see some warning message about
> "SYNCHRONIZATION TROUBLE" in the Matlab/Octave command window or other
> error messages, as diagnostics is performed at various stages of setup
> and operation.
>
> There are two possible causes for failure:
>
> 1. System overload: Too many other applications are running in parallel
> to
> Psychtoolbox, introducing severe timing noise into the calibration and
> test loop.
> See 'help SyncTrouble' on what to do. This happens rather seldomly.
>
> 2. Driver bug: Not much you can do, except submit a bug report to Apple
> or Microsoft
> for your specific hardware + software setup. This is by far the most
> common cause of failure. Psychtoolbox tries to enable work-arounds for
> some common problems if possible. Usually you should update your graphics
> card driver to see if that resolves the problems.
>
> Note: As of Spring/Summer 2008, many graphics cards + driver combos from
> ATI and NVidia on WindowsXP have bugs which cause beamposition queries to
> fail in a peculiar way. If PTB detects that failure case, it will enable
> some workaround to keep the mechanism going at slightly reduced accuracy:
> Timestamps will still be mostly jitter-free and consistent, so they are
> fully useable for timestamping, timing checks and as a basis for timed
> stimulus presentation and animation. However, all returned timestamps
> will contain a constant bias wrt. the real stimulus onset time of
> somewhere between 20 microseconds and 1.5 milliseconds, depending on your
> display settings, because Psychtoolbox can't determine the total height
> of your display in scanlines (including the invisible VBL interval)
> anymore. Exact height is important for spot-on timestamps. Psychtoolbox
> uses some safe, conservative value for its internal computations, so
> results will be consistent and useable, but contain a small constant
> offset.
>
> In some rare cases, PTB's automatic test fails to detect the bug and
> doesn't enable the workaround by itself. You can manually enable the
> workaround if you want by adding the setting 4096
> (kPsychUseBeampositionQueryWorkaround) to the value x passed via:
> Screen('Preference', 'ConserveVRAM', x);
>
> Just insert this command at the top of your scripts before any other
> Screen() commands. 'x' must be at least 4096 or the sum of 4096 and any
> other values you may want to pass with that command. See "help
> ConserveVRAMSettings" for other workarounds that you can enable manually
> if needed.
>
> If you want to get rid of that small offset, e.g., because you need to
> synchronize with other modalities or stimulation/recording equipment at
> sub-millisecond precisison, then you can try to figure out the real
> height of the display yourself and tell Psychtoolbox about the true value
> before calling Screen('OpenWindow').
>
> Once you know the real height, e.g., VTOTAL, you'd call this function:
> Screen('Preference', 'VBLEndlineOverride', VTOTAL);
>
> How to find out about VTOTAL? One way is to search the display control
> panel on Windows for some area with "Advanced Timing" or "Custom Timing"
> settings. The shareware utility "PowerStrip"
> (http://www.entechtaiwan.com/util/ps.shtm)
> also allows to change and display these parameters in the Advanced Timing
> -> Vertical Geometry -> "Total" field.
>
> Accuracy of beamposition method:
>
> Cross-checking of beamposition timestamps and kernel-level timestamps on
> a single
> display PowerPC G5 1.6 Ghz under OS-X 10.4.8 with NVidia GeforceFX-5200
> showed an
> accuracy of beamposition timestamping of better than 100 microseconds,
> with a maximum
> deviation between the different methods of less than 200 microseconds.
>
> Initial checking on two Window PC's (Dell Inspiron 8000 Laptop, Geforce
> 2Go, Windows 2000,
> and some 3.2 Ghz Pentium-4 with NVidia Geforce 7800 GTX) shows a
> precision of about
> 30 microseconds. No further testing on Windows has been performed yet by
> us, but multiple users performed similar testing procedures on their
> setups and confirmed the high accuracy and reliability for various MacOSX
> and Windows setups.
>
> Also check the FAQ section of http://www.psychtoolbox.org for latest
> infos.
>
> (end of help BeampositionQueries output)
>
>
> note that i'm not quite sure how to update my graphics driver, but the app
> store indicates my system software is up-to-date. is there anything else i
> should check, or can i just ignore the WARNING and assume that
> synchronisation is really fine?
> j
> --
> Joshua A. Solomon
> http://www.staff.city.ac.uk/~solomon
>
5
hi mario
maybe you've fixed it. (thanks!)

On 02/01/2013 14:23, "Mario" <mario.kleiner@...> wrote:


>
>Is this a MacBookPro Retina?

yes.

>What is its maximum resolution?

the NVIDIA specs say 2880 X 1800


>Is the display resolution set to maximum or something lower?

"best for Retina," which i assume is the maximum

>If you run BeampositionTest.m, how do the plots look like?

here:
http://www.staff.city.ac.uk/~solomon/MATLABScreenSnapz001.png

>The proper way to solve it, assuming it is the OSX graphics driver bug i
>suspect it is, would be to install the PsychtoolboxKernelDriver ("help
>PsychtoolboxKernelDriver") on your machine, and then force ptb to use it
>in each session, by adding a:
>v = bitor(2^16, Screen('Preference','ConserveVRAM'));
>Screen('Preference','ConserveVRAM', v);
>... to the top of each of your scripts

done.

>the output of Screen('Computer')

now says:
ans =

macintosh: 0
windows: 0
osx: 1
linux: 0
kern: [1x1 struct]
hw: [1x1 struct]
processUserLongName: 'Joshua A. Solomon'
processUserShortName: 'js'
consoleUserName: 'js'
machineName: 'Solomon's Retina'
localHostName: 'Solomons-Retina'
location: '/Sets/0'
system: 'Mac OS 10.8.2'
gstreamer: 1


>>>> DriftDemo6

this now seems to work (i.e. no exclamation point). output is

PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit
(Version 3.0.10 - Build date: Oct 29 2012).
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you
under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox
root folder for the exact licensing conditions.

PTB-INFO: Broken Apple OS/X 10.7 or later detected: Using CoreVideo
timestamping instead of precise vbl-irq timestamping.


PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA GeForce GT 650M
OpenGL Engine :: 2.1 NVIDIA-8.6.22
PTB-INFO: Renderer has 1024 MB of VRAM and a maximum 991 MB of texture
memory.
PTB-INFO: VBL startline = 900 , VBL Endline = -1
PTB-INFO: Beamposition queries unsupported on this system. Will try to use
kernel-level vbl interrupts as fallback.
PTB-INFO: Measured monitor refresh interval from VBLsync = 16.691964 ms
[59.909068 Hz]. (297 valid samples taken, stddev=0.645714 ms.)
PTB-INFO: Small deviations between reported values are normal and no
reason to worry.
PTB-INFO: Support for fast OffscreenWindows enabled.
Building a fragment shader:Reading shader from file
/Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur
eShader.frag.txt ...
Building a vertex shader:Reading shader from file
/Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur
eShader.vert.txt ...


INFO: PTB's Screen('Flip', 10) command seems to have missed the requested
stimulus presentation deadline
INFO: a total of 52 times out of a total of 52 flips during this session.

INFO: This number is fairly accurate (and indicative of real timing
problems in your own code or your system)
INFO: if you provided requested stimulus onset times with the 'when'
argument of Screen('Flip', window [, when]);
INFO: If you called Screen('Flip', window); without the 'when' argument,
this count is more of a ''mild'' indicator
INFO: of timing behaviour than a hard reliable measurement. Large numbers
may indicate problems and should at least
INFO: deserve your closer attention. Cfe. 'help SyncTrouble', the FAQ
section at www.psychtoolbox.org and the
INFO: examples in the PDF presentation in
PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips.


j
--
Joshua A. Solomon
http://www.staff.city.ac.uk/~solomon
6
On 08/01/2013 19:35, "Mario" <mario.kleiner@...> wrote:


>
>Yep, it now sort-of works. Can you give me the output at Screen verbosity
>10?

sure:

screenid =

0

PTB-DEBUG: PsychGetScreenDepths(): mode 0 : w x h = 1440 x 900, fps = 0,
depths = 16
PTB-DEBUG: PsychGetScreenDepths(): mode 1 : w x h = 1440 x 900, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 2 : w x h = 720 x 450, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 3 : w x h = 720 x 450, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 4 : w x h = 1920 x 1200, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 5 : w x h = 1920 x 1200, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 6 : w x h = 1680 x 1050, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 7 : w x h = 1680 x 1050, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 8 : w x h = 1280 x 800, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 9 : w x h = 1280 x 800, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 10 : w x h = 1024 x 640, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 11 : w x h = 1024 x 640, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 12 : w x h = 840 x 525, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 13 : w x h = 840 x 525, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 14 : w x h = 2880 x 1800, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 15 : w x h = 2880 x 1800, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 16 : w x h = 1440 x 900, fps = 0,
depths = 16
PTB-DEBUG: PsychGetScreenDepths(): mode 17 : w x h = 1440 x 900, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 18 : w x h = 2560 x 1600, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 19 : w x h = 2560 x 1600, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 20 : w x h = 2048 x 1280, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 21 : w x h = 2048 x 1280, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 22 : w x h = 1024 x 768, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 23 : w x h = 1024 x 768, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 24 : w x h = 800 x 600, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 25 : w x h = 800 x 600, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 26 : w x h = 640 x 480, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 27 : w x h = 640 x 480, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 28 : w x h = 1680 x 1050, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 29 : w x h = 1680 x 1050, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 30 : w x h = 1280 x 800, fps = 0,
depths = 32
PTB-DEBUG: PsychGetScreenDepths(): mode 31 : w x h = 1280 x 800, fps = 0,
depths = 32
PTB-DEBUG: In PsychCaptureScreen(): After display capture for screen 0
(Old CGDisplayId 0x4280380). Reenumerating all displays...
PTB-DEBUG: In PsychCaptureScreen(): After display capture for screen 0
(New CGDisplayId 0x4280380). Reenumeration done.


PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit
(Version 3.0.10 - Build date: Jan 7 2013).
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you
under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox
root folder for the exact licensing conditions.

PTB-INFO: Using CGL for fullscreen onscreen window creation...
PTB-INFO: Using GLEW version 1.5.3 for automatic detection of OpenGL
extensions...
PTB-INFO: Connection to kernel-level vbl handler established (shmem =
0x162000000).
PTB-INFO: Broken Apple OS/X 10.7 or later detected: Using CoreVideo
timestamping instead of precise vbl-irq timestamping.
PTB-INFO: CVDisplayLink for screen 0 created to work around the brokenness
of Apple Mac OS/X 10.7 and later:
PTB-INFO: Video refresh interval as measured by CoreVideo display link:
16.669370 msecs.
PTB-INFO: Video display output delay as reported by CoreVideo display
link: nan msecs.
PTB-DEBUG: PPM file magic is P6
-> Ok
# CREATOR: GIMP PNM Filter Version 1.1
PTB-DEBUG: Recognized splash image of 432 x 89 pixels, maxlevel 255.
Loading...


OpenGL-Extensions are: GL_ARB_color_buffer_float GL_ARB_depth_buffer_float
GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers
GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced
GL_ARB_fragment_program GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB
GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging
GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture
GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters
GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map
GL_ARB_shader_objects GL_ARB_shader_texture_lod
GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_sync
GL_ARB_texture_border_clamp GL_ARB_texture_compression
GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map
GL_ARB_texture_env_add GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float
GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two
GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix
GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object
GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr
GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color
GL_EXT_blend_equation_separate GL_EXT_blend_func_separate
GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array GL_EXT_depth_bounds_test GL_EXT_draw_buffers2
GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit
GL_EXT_framebuffer_multisample GL_EXT_framebuffer_multisample_blit_scaled
GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4
GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays
GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex
GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_shadow_funcs
GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array
GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic
GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp
GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent
GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query
GL_EXT_transform_feedback GL_EXT_vertex_array_bgra
GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array
GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range
GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels
GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes
GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint
GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range
GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators
GL_APPLE_ycbcr_422 GL_ATI_separate_stencil GL_ATI_texture_env_combine3
GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip
GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp
GL_NV_fog_distance GL_NV_fragment_program_option GL_NV_fragment_program2
GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_point_sprite
GL_NV_texgen_reflection GL_NV_vertex_program2_option GL_NV_vertex_program3
GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod

PTB-DEBUG: Interrogating Low-level renderer capabilities for onscreen
window with handle 10:
Indicator variables: FBO's 1, ATI_texture_float 1, ARB_texture_float 1,
Vendor NVIDIA Corporation, Renderer NVIDIA GeForce GT 650M OpenGL Engine.
Indicator variables: maxcolorattachments = 8, maxrectangletexturesize =
16384, maxnativealuinstructions = 16384.
GPU supports UYVY - YCrCb texture formats for optimized handling of video
content.
GPU supports non-power-of-two textures.
Basic framebuffer objects with rectangle texture rendertargets supported
--> RGBA8 rendertargets with blending.
Framebuffer objects support fast blitting between each other.
Framebuffer objects support anti-aliasing via multisampling.
Framebuffer objects support single-pass multisample resolve blits and
image rescaling.
Hardware supports floating point textures of 16bpc and 32bpc float format.
Assuming NV30 core or later...
Assuming NV40 core or later (maxcolattachments=8): Hardware supports
floating point blending and filtering on 16bpc float format.
Hardware also supports floating point framebuffers of 16bpc and 32bpc
float format.
Hardware supports full 32 bit floating point precision shading.
Assuming G80 core or later (maxtexsize=16384): Hardware supports full
floating point blending and filtering on 16bpc and 32bpc float format.
No compiled in support for OpenML OML_sync_control extension. Using
standard implementation.
PTB-DEBUG: Interrogation done.

PTB-DEBUG: glClear splash image top-left reference pixel: 255 255 255
PTB-INFO: Threshold Settings for successfull video refresh calibration
are: maxStdDev = 1.000000 msecs, maxDeviation = 10.000000 %, minSamples =
50, maxDuration = 5.000000 secs.
PTB-WARNING: Seems this window is displayed on a Retina-Display in scaled
mode at a non-native resolution for the display.
PTB-WARNING: Reliabiliy of visual stimulus onset timing in such a scaled
mode is so far unknown, but may be severely degraded.
PTB-WARNING: Stimulus onset timing and returned timestamps may be wrong,
with no way for me to automatically detect this.


PTB-DEBUG: Output of all acquired samples of calibration run follows:
PTB-DEBUG: Sample 0: 0.000000
PTB-DEBUG: Sample 1: 0.016581
PTB-DEBUG: Sample 2: 0.017362
PTB-DEBUG: Sample 3: 0.016594
PTB-DEBUG: Sample 4: 0.016440
PTB-DEBUG: Sample 5: 0.016488
PTB-DEBUG: Sample 6: 0.016325
PTB-DEBUG: Sample 7: 0.017416
PTB-DEBUG: Sample 8: 0.016574
PTB-DEBUG: Sample 9: 0.016469
PTB-DEBUG: Sample 10: 0.016401
PTB-DEBUG: Sample 11: 0.016477
PTB-DEBUG: Sample 12: 0.017368
PTB-DEBUG: Sample 13: 0.016544
PTB-DEBUG: Sample 14: 0.016583
PTB-DEBUG: Sample 15: 0.016577
PTB-DEBUG: Sample 16: 0.016434
PTB-DEBUG: Sample 17: 0.016588
PTB-DEBUG: Sample 18: 0.016625
PTB-DEBUG: Sample 19: 0.017344
PTB-DEBUG: Sample 20: 0.016647
PTB-DEBUG: Sample 21: 0.016466
PTB-DEBUG: Sample 22: 0.016704
PTB-DEBUG: Sample 23: 0.016527
PTB-DEBUG: Sample 24: 0.016299
PTB-DEBUG: Sample 25: 0.017389
PTB-DEBUG: Sample 26: 0.016449
PTB-DEBUG: Sample 27: 0.016378
PTB-DEBUG: Sample 28: 0.017441
PTB-DEBUG: Sample 29: 0.016562
PTB-DEBUG: Sample 30: 0.016205
PTB-DEBUG: Sample 31: 0.016279
PTB-DEBUG: Sample 32: 0.017262
PTB-DEBUG: Sample 33: 0.016208
PTB-DEBUG: Sample 34: 0.017360
PTB-DEBUG: Sample 35: 0.016175
PTB-DEBUG: Sample 36: 0.016168
PTB-DEBUG: Sample 37: 0.017284
PTB-DEBUG: Sample 38: 0.017158
PTB-DEBUG: Sample 39: 0.016241
PTB-DEBUG: Sample 40: 0.016130
PTB-DEBUG: Sample 41: 0.017194
PTB-DEBUG: Sample 42: 0.016078
PTB-DEBUG: Sample 43: 0.017213
PTB-DEBUG: Sample 44: 0.016141
PTB-DEBUG: Sample 45: 0.017253
PTB-DEBUG: Sample 46: 0.016053
PTB-DEBUG: Sample 47: 0.017237
PTB-DEBUG: Sample 48: 0.016169
PTB-DEBUG: Sample 49: 0.017307
PTB-DEBUG: Sample 50: 0.016050
PTB-DEBUG: Sample 51: 0.017252
PTB-DEBUG: Sample 52: 0.016041
PTB-DEBUG: Sample 53: 0.017371
PTB-DEBUG: Sample 54: 0.016266
PTB-DEBUG: Sample 55: 0.017173
PTB-DEBUG: Sample 56: 0.016169
PTB-DEBUG: Sample 57: 0.017267
PTB-DEBUG: Sample 58: 0.016058
PTB-DEBUG: Sample 59: 0.017271
PTB-DEBUG: Sample 60: 0.016041
PTB-DEBUG: Sample 61: 0.017172
PTB-DEBUG: Sample 62: 0.015932
PTB-DEBUG: Sample 63: 0.017282
PTB-DEBUG: Sample 64: 0.016096
PTB-DEBUG: Sample 65: 0.017275
PTB-DEBUG: Sample 66: 0.017109
PTB-DEBUG: Sample 67: 0.016207
PTB-DEBUG: Sample 68: 0.015977
PTB-DEBUG: Sample 69: 0.017298
PTB-DEBUG: Sample 70: 0.016069
PTB-DEBUG: Sample 71: 0.017269
PTB-DEBUG: Sample 72: 0.015877
PTB-DEBUG: Sample 73: 0.017228
PTB-DEBUG: Sample 74: 0.016155
PTB-DEBUG: Sample 75: 0.017247
PTB-DEBUG: Sample 76: 0.016124
PTB-DEBUG: Sample 77: 0.017196
PTB-DEBUG: Sample 78: 0.017215
PTB-DEBUG: Sample 79: 0.016224
PTB-DEBUG: Sample 80: 0.016201
PTB-DEBUG: Sample 81: 0.017377
PTB-DEBUG: Sample 82: 0.016202
PTB-DEBUG: Sample 83: 0.017352
PTB-DEBUG: Sample 84: 0.016145
PTB-DEBUG: Sample 85: 0.015981
PTB-DEBUG: Sample 86: 0.016810
PTB-DEBUG: Sample 87: 0.017273
PTB-DEBUG: Sample 88: 0.016067
PTB-DEBUG: Sample 89: 0.017319
PTB-DEBUG: Sample 90: 0.016089
PTB-DEBUG: Sample 91: 0.017339
PTB-DEBUG: Sample 92: 0.016068
PTB-DEBUG: Sample 93: 0.017254
PTB-DEBUG: Sample 94: 0.016052
PTB-DEBUG: Sample 95: 0.017327
PTB-DEBUG: Sample 96: 0.016246
PTB-DEBUG: Sample 97: 0.017438
PTB-DEBUG: Sample 98: 0.016210
PTB-DEBUG: Sample 99: 0.016176
PTB-DEBUG: Sample 100: 0.017087
PTB-DEBUG: Sample 101: 0.016094
PTB-DEBUG: Sample 102: 0.017193
PTB-DEBUG: Sample 103: 0.016171
PTB-DEBUG: Sample 104: 0.017235
PTB-DEBUG: Sample 105: 0.016104
PTB-DEBUG: Sample 106: 0.017220
PTB-DEBUG: Sample 107: 0.016071
PTB-DEBUG: Sample 108: 0.017339
PTB-DEBUG: Sample 109: 0.016115
PTB-DEBUG: Sample 110: 0.017142
PTB-DEBUG: Sample 111: 0.016095
PTB-DEBUG: Sample 112: 0.017354
PTB-DEBUG: Sample 113: 0.016048
PTB-DEBUG: Sample 114: 0.017139
PTB-DEBUG: Sample 115: 0.016150
PTB-DEBUG: Sample 116: 0.016730
PTB-DEBUG: Sample 117: 0.017348
PTB-DEBUG: Sample 118: 0.016131
PTB-DEBUG: Sample 119: 0.017370
PTB-DEBUG: Sample 120: 0.016284
PTB-DEBUG: Sample 121: 0.016130
PTB-DEBUG: Sample 122: 0.017346
PTB-DEBUG: Sample 123: 0.015952
PTB-DEBUG: Sample 124: 0.017241
PTB-DEBUG: Sample 125: 0.016113
PTB-DEBUG: Sample 126: 0.017156
PTB-DEBUG: Sample 127: 0.017303
PTB-DEBUG: Sample 128: 0.015966
PTB-DEBUG: Sample 129: 0.017292
PTB-DEBUG: Sample 130: 0.016157
PTB-DEBUG: Sample 131: 0.017343
PTB-DEBUG: Sample 132: 0.016086
PTB-DEBUG: Sample 133: 0.016056
PTB-DEBUG: Sample 134: 0.017379
PTB-DEBUG: Sample 135: 0.016107
PTB-DEBUG: Sample 136: 0.017152
PTB-DEBUG: Sample 137: 0.016080
PTB-DEBUG: Sample 138: 0.017388
PTB-DEBUG: Sample 139: 0.016032
PTB-DEBUG: Sample 140: 0.017107
PTB-DEBUG: Sample 141: 0.016161
PTB-DEBUG: Sample 142: 0.017225
PTB-DEBUG: Sample 143: 0.016069
PTB-DEBUG: Sample 144: 0.017068
PTB-DEBUG: Sample 145: 0.017300
PTB-DEBUG: Sample 146: 0.016108
PTB-DEBUG: Sample 147: 0.017218
PTB-DEBUG: Sample 148: 0.016183
PTB-DEBUG: Sample 149: 0.017061
PTB-DEBUG: Sample 150: 0.015989
PTB-DEBUG: Sample 151: 0.017312
PTB-DEBUG: Sample 152: 0.016065
PTB-DEBUG: Sample 153: 0.017346
PTB-DEBUG: Sample 154: 0.016143
PTB-DEBUG: Sample 155: 0.017250
PTB-DEBUG: Sample 156: 0.016121
PTB-DEBUG: Sample 157: 0.017415
PTB-DEBUG: Sample 158: 0.016150
PTB-DEBUG: Sample 159: 0.016215
PTB-DEBUG: Sample 160: 0.017097
PTB-DEBUG: Sample 161: 0.016060
PTB-DEBUG: Sample 162: 0.017221
PTB-DEBUG: Sample 163: 0.016062
PTB-DEBUG: Sample 164: 0.017243
PTB-DEBUG: Sample 165: 0.016243
PTB-DEBUG: Sample 166: 0.017478
PTB-DEBUG: Sample 167: 0.016455
PTB-DEBUG: Sample 168: 0.016001
PTB-DEBUG: Sample 169: 0.017328
PTB-DEBUG: Sample 170: 0.016012
PTB-DEBUG: Sample 171: 0.017223
PTB-DEBUG: Sample 172: 0.016064
PTB-DEBUG: Sample 173: 0.017287
PTB-DEBUG: Sample 174: 0.016075
PTB-DEBUG: Sample 175: 0.017345
PTB-DEBUG: Sample 176: 0.016170
PTB-DEBUG: Sample 177: 0.017543
PTB-DEBUG: Sample 178: 0.016100
PTB-DEBUG: Sample 179: 0.017333
PTB-DEBUG: Sample 180: 0.016108
PTB-DEBUG: Sample 181: 0.017129
PTB-DEBUG: Sample 182: 0.016182
PTB-DEBUG: Sample 183: 0.017128
PTB-DEBUG: Sample 184: 0.016211
PTB-DEBUG: Sample 185: 0.016121
PTB-DEBUG: Sample 186: 0.017304
PTB-DEBUG: Sample 187: 0.016106
PTB-DEBUG: Sample 188: 0.017184
PTB-DEBUG: Sample 189: 0.016097
PTB-DEBUG: Sample 190: 0.017328
PTB-DEBUG: Sample 191: 0.016101
PTB-DEBUG: Sample 192: 0.016988
PTB-DEBUG: Sample 193: 0.016881
PTB-DEBUG: Sample 194: 0.016271
PTB-DEBUG: Sample 195: 0.017424
PTB-DEBUG: Sample 196: 0.016376
PTB-DEBUG: Sample 197: 0.016244
PTB-DEBUG: Sample 198: 0.017328
PTB-DEBUG: Sample 199: 0.016023
PTB-DEBUG: Sample 200: 0.017278
PTB-DEBUG: Sample 201: 0.016304
PTB-DEBUG: Sample 202: 0.016155
PTB-DEBUG: Sample 203: 0.017183
PTB-DEBUG: Sample 204: 0.016062
PTB-DEBUG: Sample 205: 0.017396
PTB-DEBUG: Sample 206: 0.016137
PTB-DEBUG: Sample 207: 0.017131
PTB-DEBUG: Sample 208: 0.016141
PTB-DEBUG: Sample 209: 0.017253
PTB-DEBUG: Sample 210: 0.016016
PTB-DEBUG: Sample 211: 0.017154
PTB-DEBUG: Sample 212: 0.017346
PTB-DEBUG: Sample 213: 0.016272
PTB-DEBUG: Sample 214: 0.015966
PTB-DEBUG: Sample 215: 0.017437
PTB-DEBUG: Sample 216: 0.016088
PTB-DEBUG: Sample 217: 0.017402
PTB-DEBUG: Sample 218: 0.015989
PTB-DEBUG: Sample 219: 0.017331
PTB-DEBUG: Sample 220: 0.016139
PTB-DEBUG: Sample 221: 0.017334
PTB-DEBUG: Sample 222: 0.016161
PTB-DEBUG: Sample 223: 0.017012
PTB-DEBUG: Sample 224: 0.016019
PTB-DEBUG: Sample 225: 0.017166
PTB-DEBUG: Sample 226: 0.016131
PTB-DEBUG: Sample 227: 0.017066
PTB-DEBUG: Sample 228: 0.016126
PTB-DEBUG: Sample 229: 0.017334
PTB-DEBUG: Sample 230: 0.015805
PTB-DEBUG: Sample 231: 0.017308
PTB-DEBUG: Sample 232: 0.016198
PTB-DEBUG: Sample 233: 0.017235
PTB-DEBUG: Sample 234: 0.015979
PTB-DEBUG: Sample 235: 0.017307
PTB-DEBUG: Sample 236: 0.017257
PTB-DEBUG: Sample 237: 0.016173
PTB-DEBUG: Sample 238: 0.016249
PTB-DEBUG: Sample 239: 0.017314
PTB-DEBUG: Sample 240: 0.016158
PTB-DEBUG: Sample 241: 0.017365
PTB-DEBUG: Sample 242: 0.016176
PTB-DEBUG: Sample 243: 0.016122
PTB-DEBUG: Sample 244: 0.017203
PTB-DEBUG: Sample 245: 0.016152
PTB-DEBUG: Sample 246: 0.017187
PTB-DEBUG: Sample 247: 0.016029
PTB-DEBUG: Sample 248: 0.017075
PTB-DEBUG: Sample 249: 0.017323
PTB-DEBUG: Sample 250: 0.016054
PTB-DEBUG: Sample 251: 0.017375
PTB-DEBUG: Sample 252: 0.016182
PTB-DEBUG: Sample 253: 0.017230
PTB-DEBUG: Sample 254: 0.016508
PTB-DEBUG: Sample 255: 0.016248
PTB-DEBUG: Sample 256: 0.017152
PTB-DEBUG: Sample 257: 0.016153
PTB-DEBUG: Sample 258: 0.017283
PTB-DEBUG: Sample 259: 0.016188
PTB-DEBUG: Sample 260: 0.016085
PTB-DEBUG: Sample 261: 0.017203
PTB-DEBUG: Sample 262: 0.017359
PTB-DEBUG: Sample 263: 0.016211
PTB-DEBUG: Sample 264: 0.016230
PTB-DEBUG: Sample 265: 0.017159
PTB-DEBUG: Sample 266: 0.016202
PTB-DEBUG: Sample 267: 0.017237
PTB-DEBUG: Sample 268: 0.016292
PTB-DEBUG: Sample 269: 0.016269
PTB-DEBUG: Sample 270: 0.017200
PTB-DEBUG: Sample 271: 0.016077
PTB-DEBUG: Sample 272: 0.017251
PTB-DEBUG: Sample 273: 0.016034
PTB-DEBUG: Sample 274: 0.017445
PTB-DEBUG: Sample 275: 0.016342
PTB-DEBUG: Sample 276: 0.016233
PTB-DEBUG: Sample 277: 0.017218
PTB-DEBUG: Sample 278: 0.017308
PTB-DEBUG: Sample 279: 0.016237
PTB-DEBUG: Sample 280: 0.016055
PTB-DEBUG: Sample 281: 0.017327
PTB-DEBUG: Sample 282: 0.016358
PTB-DEBUG: Sample 283: 0.017144
PTB-DEBUG: Sample 284: 0.016106
PTB-DEBUG: Sample 285: 0.017219
PTB-DEBUG: Sample 286: 0.016231
PTB-DEBUG: Sample 287: 0.017233
PTB-DEBUG: Sample 288: 0.016076
PTB-DEBUG: Sample 289: 0.017123
PTB-DEBUG: Sample 290: 0.015986
PTB-DEBUG: Sample 291: 0.017311
PTB-DEBUG: Sample 292: 0.016136
PTB-DEBUG: Sample 293: 0.017390
PTB-DEBUG: Sample 294: 0.016088
PTB-DEBUG: Sample 295: 0.017496
PTB-DEBUG: Sample 296: 0.015977
PTB-DEBUG: Sample 297: 0.016091
PTB-DEBUG: Sample 298: 0.017297
PTB-DEBUG: End of calibration data for this run...



PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA GeForce GT 650M
OpenGL Engine :: 2.1 NVIDIA-8.6.22
PTB-INFO: Renderer has 1024 MB of VRAM and a maximum 984 MB of texture
memory.
PTB-INFO: VBL startline = 1800 , VBL Endline = 1851
PTB-INFO: Measured monitor refresh interval from beamposition = 16.669320
ms [59.990448 Hz].
PTB-INFO: Will use beamposition query for accurate Flip time stamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 16.670578 ms
[59.985921 Hz]. (298 valid samples taken, stddev=0.556441 ms.)
PTB-INFO: Small deviations between reported values are normal and no
reason to worry.
PTB-INFO: Support for fast OffscreenWindows enabled.
PTB-DEBUG: Swaprequest too close to last swap vbl (0.000503 secs) or
between forbidden scanline 1 and 50. Delaying...
VBL timestamp deviation: precount=357 , postcount=358, delta = 1,
postflip_vbltimestamp = 32660.400034 - beampos_vbltimestamp =
32660.398353 == Delta is = 0.001681
PTB-DEBUG: Swaprequest too close to last swap vbl (0.001018 secs) or
between forbidden scanline 1 and 50. Delaying...
VBL timestamp deviation: precount=358 , postcount=358, delta = 0,
postflip_vbltimestamp = 32660.400058 - beampos_vbltimestamp =
32660.398355 == Delta is = 0.001704


PTB-ERROR: Screen('Flip'); beamposition timestamping computed an
*impossible stimulus onset value* of 32660.398355 secs, which would
indicate that
PTB-ERROR: stimulus onset happened *before* it was actually requested!
(Earliest theoretically possible 32660.400603 secs).

PTB-ERROR: Some more diagnostic values (only for experts): rawTimestamp =
32660.414611, scanline = 1753
PTB-ERROR: Some more diagnostic values (only for experts):
line_pre_swaprequest = 198, line_post_swaprequest = 241,
time_post_swaprequest = 32660.400992
PTB-ERROR: Some more diagnostic values (only for experts):
preflip_vblcount = 358, preflip_vbltimestamp = 32660.400034
PTB-ERROR: Some more diagnostic values (only for experts):
postflip_vblcount = 358, postflip_vbltimestamp = 32660.400058,
vbltimestampquery_retrycount = 0

PTB-ERROR: The most likely cause of this error (based on cross-check with
kernel-level timestamping) is:
PTB-ERROR: Something may be broken in your systems beamposition
timestamping. Read 'help SyncTrouble' !

PTB-ERROR: For the remainder of this session, i've switched to kernel
based timestamping as a backup method.
PTB-ERROR: This method is slightly less accurate and higher overhead but
should be similarly robust.
PTB-ERROR: A less likely cause could be that Synchronization of stimulus
onset (buffer swap) to the
PTB-ERROR: vertical blank interval VBL is not working properly.
PTB-ERROR: Please run the script PerceptualVBLSyncTest to check this. With
non-working sync to VBL, all stimulus timing
PTB-ERROR: becomes quite futile.

tel =

0.0377

PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0
PTB-DEBUG: In PsychReleaseScreen(): After display release for screen 0
(Old CGDisplayId 0x4280380). Reenumerating all displays...
PTB-DEBUG: In PsychReleaseScreen(): After display release for screen 0
(New CGDisplayId 0x4280380). Reenumeration done.
OwnerPID: 161
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: SystemUIServer
OwnerPID: 161
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: SystemUIServer
OwnerPID: 161
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: SystemUIServer
OwnerPID: 573
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: Vuze
OwnerPID: 528
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: Skype
OwnerPID: 231
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: Dropbox
OwnerPID: 212
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: Growl
OwnerPID: 197
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: gfxCardStatus
OwnerPID: 177
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: Notification Center
OwnerPID: 98
WindowLevel: 24 (ShieldingWindow 2147483629)
WindowName: Menubar
WindowOwnerName: Window Server
OwnerPID: 160
WindowLevel: 20 (ShieldingWindow 2147483629)
WindowName: Dock
WindowOwnerName: Dock
OwnerPID: 160
WindowLevel: 19 (ShieldingWindow 2147483629)
WindowName: Magic Mirror
WindowOwnerName: Dock
OwnerPID: 2519
WindowLevel: 0 (ShieldingWindow 2147483629)
WindowName: MATLAB R2012b
WindowOwnerName: MATLAB
TARGETWINDOWNAME: 'MATLAB R2012b' with pid 2519.
PTB-DEBUG: In PsychCaptureScreen(): After display capture for screen 0
(Old CGDisplayId 0x4280380). Reenumerating all displays...
PTB-DEBUG: In PsychCaptureScreen(): After display capture for screen 0
(New CGDisplayId 0x4280380). Reenumeration done.
PTB-INFO: Releasing shared memory mapping for screen 0.
PTB-INFO: Releasing CVDisplayLink for screen 0.
PTB-DEBUG: In PsychReleaseScreen(): After display release for screen 0
(Old CGDisplayId 0x4280380). Reenumerating all displays...
PTB-DEBUG: In PsychReleaseScreen(): After display release for screen 0
(New CGDisplayId 0x4280380). Reenumeration done.
OwnerPID: 161
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: SystemUIServer
OwnerPID: 161
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: SystemUIServer
OwnerPID: 161
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: SystemUIServer
OwnerPID: 573
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: Vuze
OwnerPID: 528
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: Skype
OwnerPID: 231
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: Dropbox
OwnerPID: 212
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: Growl
OwnerPID: 197
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: gfxCardStatus
OwnerPID: 177
WindowLevel: 25 (ShieldingWindow 2147483629)
WindowOwnerName: Notification Center
OwnerPID: 98
WindowLevel: 24 (ShieldingWindow 2147483629)
WindowName: Menubar
WindowOwnerName: Window Server
OwnerPID: 160
WindowLevel: 20 (ShieldingWindow 2147483629)
WindowName: Dock
WindowOwnerName: Dock
OwnerPID: 160
WindowLevel: 19 (ShieldingWindow 2147483629)
WindowName: Magic Mirror
WindowOwnerName: Dock
OwnerPID: 2519
WindowLevel: 0 (ShieldingWindow 2147483629)
WindowName: MATLAB R2012b
WindowOwnerName: MATLAB
TARGETWINDOWNAME: 'MATLAB R2012b' with pid 2519.


>Ian also helps testing, he has access to a Datapixx, so we should be able
>to figure out which is which in the end by comparing our timestamps
>against the hardware timestamps.

FWIW I'll be at the IoO tomorrow. (Are you still there, Ian?) I'll bring
along my MacBook.