| Reference | Downloads | Github

Feature request: "Mute" a component or routine

Hello Jon and company,

I’m assuming you’re all sitting around with way too much time on your hands just hoping for random feature requests to keep you busy. Well, I’m here to oblige!

Would it be possible to make it so a component or an entire routine can be “muted”. I ask because my lab uses a Cedrus button box and a LabJack U3 for our EEG paradigms. Attempting to tweak/modify/update the experiment while away from the lab’s stimulus presentation computer is problematic because the .psyexp won’t run unless those devices are present. Our workaround is to have two versions – one that expects the devices and one that does not – and manually carryover any changes, but this is really error prone. So it would be ideal if we could just “mute” the components and routines that expect that hardware so that PsychPy comments out the relevant code when it compiles the script.

This is hardly an urgent concern and perhaps I’m alone in thinking such a feature would be useful, but I thought I’d add it to my public wishlist.



Hi Andrew,

Not directly, but there are some workarounds that could achieve what you want. e.g. You could add some custom variables to the experiment info dialog that is displayed before each experiment.


  • add a field called, say, run_cedrus_routine, and give it a default value of 0
  • add a loop around around that routine (not connected to a conditions file) and put $run_cedrus_routine in its nReps field. If the value of that variable is 0, the routine will not run. If it is 1, it will run.
  • alternatively (a cleaner solution), add a code component to that routine and in its Begin routine tab, put something like this:
if not run_cedrus_routine:
    continueRoutine = False

This will have the same effect, without adding a kludgy loop. But in either case, I’m not sure this would solve your issues, as it is a hardware thing. Does the problem arise because of trying to create the hardware link at the start of the experiment, which enabling or disabling the actual routine later would have no effect over.

You can do the same thing with custom code components: make the code execution contingent on some variable.

“Muting” other components is trickier. Visual stimuli can have their visibility controlled by a variable, so can be made invisible. For others, the “Start” field could be set to “Condition”, again controlled by some variable. But this isn’t a general solution.

You’re probably right that all components could do with an “Enabled” field so they can be switched on and off as required.

1 Like

Hi Michael,

Thanks for the suggestions. Unfortunately, I don’t think the workarounds would be successful because, as you noted, the error arises because a hardware link cannot be established. So any and all instances in which the hardware is called or referenced will lead to a failure. Many of these instances are components within a routine, so the loops would not be an option.