The single most common problem people had at the workshop was name conflicts with a stimulus and a parameter from the excel file

Hi Jonathan,

I know I've mentioned this a few times already (to the point of harassment perhaps), but bitmaps still appear garbled sometimes when using the simpleImageStim. This happens on Windows, Linux and in both PyGlet and PyGame window mode. I have verified that this problem still exists with PsychoPy 1.70 on Ubuntu 11.04.

Illustration: http://files.cogsci.nl/tmp/example.png

I have described this issue in a bit more detail here:
http://groups.google.com/group/psychopy-users/msg/9548230b034be188

Regards,
Sebastiaan

branching is possible in the builder (branching.psyexp), yet it would be more intuitive to have bifurcating lines in the flow panel that translate into "if: ... else: ..." in lastrun.py

Currently Builder sets the start and end time by comparing against t (from the routine clock) but;

• for brief stimuli we know that this is less precise than using a fixed number of frames.
• would be nice to be able to yoke one component to another

This needs some thought, especially for the GUI aspect (ie how to draw it in the dialog box and in the Routine timeline).

Explain how the new system works (as a single separate document, linked to each of the other Component documents?)

Explain the advantage of using frames, rather than time, for better precision

Use some examples like:
Use 'time (s)' and simply set it to a numeric value
Use 'time (s)' and set it to a variable name with $. Then also set the 'expected time' to see a rough approximation (this won't affect the script)
Set to 'frameN' and use either a numeric value or a variable, as above
Set to condition with value myMovie.status==FINISHED

it should be relatively straightforward (medium effort?) to write a tweaked version of gui.DlgFromDict that will allow both preview and editing of conditions files. this could then be accessed from the loop dialog, via rightclick in the filename box. a full-blown editor would be too much work, but a simple one should be pretty easy, and make it possible to create and edit conditions files without needing a separate piece of software (like excel).

this would be similar to previewing the exp info dialog from the exp settings, but with a new DlgFromDict that is a little fancier.

bits++ mode is already supported by PsychoPy, but currently adding support for mono++ and colour++

stuck at:

elif instrText.status==STARTED and t>=(0.0+):

things go further if in _base.writeStopTestCode I add:

if self.params['stopVal'].val=='': # patch for old demos
self.params['stopVal'].val = 0

then I get an indentation error related to clocks

issue: seems to do the first item but skip subsequent items, at least in some cases

repro: a default patch with duration = 2s enclosed in a default loop, 5 repetitions with no external file list.

expected: should take 10 seconds total, but took only 2. hacking the lastrun.py script, the loop was executed 5 times.

Possible fix (its removing the white space)

for thisTrial in trials:
    currentLoop = trials
    for comp in trialComponents:
        comp.status = NOT_STARTED

have a new constant, so that 1000000 is replaced by FOREVER in scripts generated by builder:

while continueRoutine and (t < FOREVER):

Probably the first step here is to create a set of number-coded warnings/errors that correspond to the web page with further info.

see also issue #10

currently, you can insert an existing routine. I watched a couple people struggle to find out how to make a new routine. its in a menu but also having a button there on the flow would be helpful.

idea: insert a "mere pause", just a delay of specified duration that does not show anything on-screen, nor require subject action to end the routine. (implementation: after the duration has elapsed, continueRoutine goes False.) this would make it easy and intuitive to vary the timing between events within a routine, e.g., to have a random delay before showing a stimulus.

Labels are already being provided by calls to addToUndoStack(), but the menu item needs to be updated as well each time the undo stack is altered.

In prefs we need a place to type in additional paths that the psychopy python should include, for easier install of additional packages.

This can be written out to a text-based psychopy.pth file in the site-packages directory

Should remove those by setting the flow status correctly, as is done correctly when the user hits Esc

Many of the prefs, technically, could update at any time. We just haven't written the code to check which prefs have changed in the dlg and update them accordingly.

(from Marc Buhner)

I would find it extremely useful if one could re-size the entry fields in some of the builder dialogs.
This is most pertinent in the code component, where only a few lines fit in, and reading code there is awkward.

Also, Tab in this component should indent code, not skip to the next text entry field.

If a sound component of a trial is set to 'constant' then it will play on the first trial only. It does not play on subsequent iterations through a loop. If the sound component is set to 'repeat' then it will play on every iteration. This is true whether the soundfile name is specified directly or read from a config file.
(from Dave Braze)
Workaround is to set the sound to be set fresh 'on every repeat'

View/edit a readme.txt that sits alongside the psyexp file. Useful to save info about the experiment as a reminder to the creator, but also for demos, so we can point the user to what they are meant to learn from each demo

(I've wanted this in some demos to say "note how XXXX was achieved")

The file could be autoloaded to a floating window, or into a docked window (or turned off by the user)

low-priority cosmetic issues:

in a few circumstances, the time grid looks a little off.

• BART demo: feedback routine. the duration is 1.5s, but last labelled point is 1.4s and the horiz line sort of goes off into space on the right side
• Navon demo: trial routine. the duration is 9s, but the last vertical line is not drawn.

maybe have last-drawn timepoint be a 1, 2, or 5 (* .1, 1, 10, 100, ...), and scale things within that?

FIXED by disabling GCDC on linux: (in ubuntu, the routine panel is not auto-refreshed after using a scroll-bar. manual refresh can be achieved by zoom-in & zoom-out, or by switching to another routine and then switching back. )

non-noticeable performance issue:
the time-grid method is called 25 times when opening a psyexp file that has 5 routines (and so presumably only needs 5 time grids?)

An easy task for someone wanting to get started with wxPython. See coder.py

writeInitCode, around line 52 at "text = setDefault"

to save data from a single, unique trial, it seems like it should not require the user to make a loop with 1 repetition and no conditions. that seems like extra work and counter-intuitive. key response components allow you to specify what will be saved. then nothing is saved unless its part of a loop.

maybe there's a way to auto-detect whether a routine on the flow is not part of a loop, and implicitly make a trial handler with 1 rep (doing so invisibly, behind the scenes). probably a full blown trialHandler is not actually needed, and would produce more code than necessary in the lastrun.py files, but it might be a relatively low-effort way to invoke code that will save the data.

The need for this is substantial, but the effort is too!

The pyglet and pygame back-ends currently used by PsychoPy are not designed for low-latency playback. pyAudio uses portaudio, but also doesn't manage to support low latencies (this is probably to do with the wrapper though - psychtooolbox uses portaudio and does claim good latency).

We need a new python wrapper around something like FMod or portAudio

This is a potentially large project, but it would be great to have a website that people could use to 'publish' experiments, scripts, or just components. Upload things, tag them, add a description, search and download. A 'flickr' for science!

Users would get publicity for their study, science would get reproducibility, new users would get examples to build on. Everyone wins!

Flow currently allows various forms of broken construction - like loops that don't properly nest - and the bugs it introduces will cause things to crash. First this needs someone to click around on it and record all the 'stupid' things that it currently allows so we can fix them!

Also, not all computers have a right-click, which makes it hard to delete things.

currently the setting gets changed only when the browse file dialog is closed, but then if someone deletes the text (to get rid of the file info) it has no effect

If the user selects an empty one then use it; if not then create one (called psychopyDemos?)

When a component is going to use a parameter that gets set every trial then it needn't be initialised to that value. Just initialise with default and set later to the necessary value. This has the advantage that we can create the parameter variables (e.g. thisTrial['ori']) just before the loops, rather than at the start of the script.

Not sure though. Is it worth the effort for some slightly better code? Does it /matter/ if the TrialHandler is created at the start of the experiment rather then just before it runs?

Users won't know to go looking in the output pane of the coder to find error messages

It would be great to be able to switch between versions programmatically within the app and to go to any arbitrary version and to have all versions locally saved.

Easiest with git or hg, but git would require the user to install software. Maybe we need to setup hg-git mirroring system so that psychopy version system could access the hg repos.

routines should have an ISI period, during which nothing can be updated (but constant stimuli can be drawn) and use this period to update other stimuli. e.g. when loading a new image from disk it should be loaded at the beginning of a routine, while only a fixation is presented

for debugging purposes, it would be nice to be able to run a script while simulating receiving a scanner sync pulse. I'm envisioning a window in which you can configure some options (eg, set the desired TR, the desired signal (e.g., key-5), when the signal comes relative to the TR), and then click "start scanner" to start generating the signals with high temporal precision. Presumably, this would be best implemented as a separate thread that is invoked by your script.

Things that update on every frame (e.g. a drifting grating) shouldn't log every single change, because it swamps the logging system.

We can already simply set no loggin to occur for the stimulus (autoLog=False), but would be better to have every single stimulus set method inherit decide whether to send a log message, in a way that can be overridden

Presumably on linux this should be handled by package manager, not by psychopy

Maybe we should leave it in place for non-debian-derived systems?

As the number of Components grows, we need a way to hide them from new users to stop them being overwhelmed.

Maybe a prefs-type panel with all available components where you can tick boxes to hide things that you never use, and maybe some presets for 'vision science', 'fMRI/EEG', 'cognitive'

Jeremy has also suggested adding 2 columns of components instead of 1

And we could allow the buttons to be smaller too as a preference.

For running two interleaved Quests using the MultiStairHandler class:

First, it would be nice to be able to change the recorded intensity with the addData-call (as with QuestHandler).
Here's the bug: In the data file (xlsx) the first trial for each staircase does not show the startIntensity, but the intensity of the second trial, and so on. I guess there should be special handling for the first trial of each staircase to record intensities correctly.

(submitted by Gerrit Maus on googlecode)

Currently, users can set the keyboard input not to receive a 'corrAns' and the script will be written, but will contain a syntax error.
There is no case where a staircase is sensible if there is no 'corrAns' because this is needed to determine the next stimulus level.

warn unsuspecting users of the need for this.

The 1.70 release includes changes that are incompatible with previous releases (experiments saved with this version cannot be opened by older versions). That means this is a good time to deal with some other names that could do with updating:

Keyboard[forceEndTrial] should be forceEndRoutine
trialList and trialListFile should be conditions and conditionsFile

any others?

Lots of routines have common goals;

• provide feedback
• run a go/no-go trial
• run a 2IFC/2AFC trial
• get a rating

These could be saved as templates in the experiment menu. The system for copying and pasting routines between experiment windows already exists, this could probably be re-used here, but with saving to disk instead of clipboard.

in OSX 10.6 running python 2.7, I can build the egg just fine, but when running setupApp.sh I get an error that the module "hid" cannot be found

./setupApp.sh chokes. the final out put from the process is:

Traceback (most recent call last):
File "setupApp.py", line 88, in
CFBundleTypeRole='Editor')],
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/core.py", line 152, in setup
dist.run_commands()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app-0.6.3-py2.6.egg/py2app/build_app.py", line 470, in run
self._run()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app-0.6.3-py2.6.egg/py2app/build_app.py", line 626, in _run
self.run_normal()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app-0.6.3-py2.6.egg/py2app/build_app.py", line 691, in run_normal
mf = self.get_modulefinder()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app-0.6.3-py2.6.egg/py2app/build_app.py", line 586, in get_modulefinder
debug=debug,
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/modulegraph-0.9-py2.6.egg/modulegraph/find_modules.py", line 258, in find_modules
find_needed_modules(mf, scripts, includes, packages)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/modulegraph-0.9-py2.6.egg/modulegraph/find_modules.py", line 184, in find_needed_modules
mf.import_hook(mod)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/modulegraph-0.9-py2.6.egg/modulegraph/modulegraph.py", line 642, in import_hook
q, tail = self.find_head_package(parent, name, level)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/modulegraph-0.9-py2.6.egg/modulegraph/modulegraph.py", line 721, in find_head_package
raise ImportError, "No module named " + qname
ImportError: No module named hid

is libhid supposed to be installed in OSX?

currently, there is a slight visual blip (win.flip) at the transition from one routine to another even if the routines have identical visual stimuli. so from the builder its impossible to create a continuous visual experience for subjects.

on mac, when I open a new coder window, I get an error message printed to the console:
<date, machine name> Python[48348] : CGContextRestoreGState: invalid context 0x0

if I then hit return, and then space, I get the same error msg for the space. and then backspace gives another one. it seems to be something about the last line being sensitive to space or backspace.

the wx people confirm something very similar as bug in wxStyledTex: http://trac.wxwidgets.org/ticket/4272

they say its low priority because a simple work around is to use wx.CallAfter( ), which is described here: http://wiki.wxpython.org/CallAfter. but I could not see where to add this in the coder. I tried several places in CodeEditor.OnKeyPressed() but it made no difference.

Currently the outputs to .csv and .xlsx always generate summarised data (although log files can be used to create detailed chronological outputs).

Should be easy enough to spit out data from a Trial/Stairhandler in a chronological format instead, with one line per trial.

Probably implement as an option to existing methods e.g.:

trials = data.TrialHandler(....)
#collect data in exp
trials.saveAsExcel(filename, chronological=True)

In Coder we can have multiple interleaved staircases but not possible yet in Builder. To make this possible we need a MultiStair class that handles randomising the stairs and storing parameters for each (potentially different) staircase.

currently randomisation is performed on each repeat of the trial list, but some users might want full randomisation
e.g. perform the shuffle on the entire matrix of nrepsXntrials

Idea: define a region of the screen, e.g., within which to detect mouse events, display an image, and so on. This could be implemented as a class visual.Zone() to do things like wx.Rect does, but allowing floating point coordinates (needed for psychopy) and be extendible to arbitrary polygons.

Ideally, this would seem best as a definition accessible to all components in a script. (It could effectively be a code component that defines a region at the start of the experiment.) This might be useful as part of the psychopy libs, not just for builder.

Currently for many of the functions in builder only the specific lowercase argument is accepted e.g. gauss is fine but Gauss is not.

Ideally all the functions that these arguments are directed at should accept a greater variation for example to create a sine texture, Sin, Sine, sin, sine could all be acceptable entries.

Also warn users if they have entered an unrecognised argument.