Fwd: [psychopy-users] auditory stimulus resulting in error message NameError: name 'sound' is not defined

[Jeremy Gray]

[moving to dev-list]

In the Builder, instead of trying to keep track of which libs are
needed and then selectively import only those libs, how about if
Builder-generated scripts always do this:
from psychopy import *

Currently you get: 'core', 'data', 'event', 'filters', 'gui', 'misc',
'sound', 'visual'
So some things are not showing up. Editing psychopy.__init__.__all__
would probably take care of most of the others, like microphone, but
maybe not psychopy.hardware? Should be easy enough to adjust (fingers
crossed!)

The upside is a) simpler code under the hood, and b) no failures like
the one reported in this other post (when people start doing things in
code components). Is there a downside that I am not seeing? The extra
RAM usage and start-up overhead seem small.

--Jeremy


---------- Forwarded message ----------
From: Michael MacAskill <michael....@otago.ac.nz>
Date: Wed, Apr 17, 2013 at 7:00 PM
Subject: Re: [psychopy-users] auditory stimulus resulting in error
message NameError: name 'sound' is not defined
To: psychop...@googlegroups.com


Dear Tricia,

The Builder doesn't know explicitly that it needs to access some sound
code. So in the "Begin experiment" box, also type on a separate line:


from psychopy import sound


Regards,

Mike

On 17 Apr, 2013, at 19:32, tricia <p.licht...@gmail.com> wrote:

> Hi,
>
> I'm designing a routine in which an auditory stimulus will play throughout the routine while visual stimuli get updated by a loop.
>
> I'm using a code component for the auditory stimulus as specified in the response here, which includes these instructions.
>
> -- Insert a Code component in the routine. Right click on it and move it to the top so that it occurs before your image stimulus.
>
> -- In the "Begin Experiment" box, type:
> soundStarted = False
>
> -- In the "Begin Routine" box, type:
>
> if not soundStarted:
> sound.Sound('mySound.wav').play()
> soundStarted = True
>
> I'm getting the following error message.
>
> sound.Sound('list1.wav').play()
> NameError: name 'sound' is not defined
>
> I've checked that my sound file is in the same directory as my experiment. I've tried assigning the sound file to a variable name (list1='list1.wav'). But I keep getting the same error message. Any suggestions about what I'm doing wrong?
>
> Thanks!
>
> Tricia
>
>
> --
> You received this message because you are subscribed to the Google Groups "psychopy-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to psychopy-user...@googlegroups.com.
> To post to this group, send email to psychop...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msg/psychopy-users/-/5GPfj2K6XgYJ.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google
Groups "psychopy-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to psychopy-user...@googlegroups.com.
To post to this group, send email to psychop...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Peirce]

I don't like
from psychopy import *
It encourages beginners not to think about what is being imported or
what imported names they might be overlapping with.

I agree that sound is common enough that we might assume most
experiments need it, so we could add that to builder's load-by-default
list.

Not sure about importing microphone for all experiments. I feel like
that's still likely to be used relatively rarely, no? Should we be
trying to 'train' people only to import what they need, rather than
always importing everything? Or should we not care about such things?

Jon

--
Jonathan Peirce
Nottingham Visual Neuroscience

http://www.peirce.org.uk

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

[Jeremy Gray]

> I don't like
> from psychopy import *
> It encourages beginners not to think about what is being imported or what
> imported names they might be overlapping with.

Agreed. in retrospect I like listing everything explicitly much better.

> I agree that sound is common enough that we might assume most experiments
> need it, so we could add that to builder's load-by-default list.
>
> Not sure about importing microphone for all experiments. I feel like that's
> still likely to be used relatively rarely, no?

I have no real idea about microphone, although people are asking about
usage (unlike say google speech or encryption). (As an aside, it seems
like microphone should really be part of sound, not a separate module.
This issue might be reason enough to do it. The previous thinking was,
yeah, it probably should be in sound but its not worth the effort to
change it now.)

Two, more-general thoughts here. a) Besides style, is there any real
cost of importing things that are not used much? How often do people
use sin, cos, tan, log, log10, pi, average, sqrt, std, deg2rad,
rad2deg, linspace, asarray? Isn't that the same issue?
b) Knowing that everything will be available means that Builder /
experiment objects do not have to keep track, which would simplify
their internal code.

> Should we be trying to
> 'train' people only to import what they need, rather than always importing
> everything? Or should we not care about such things?

Well, PsychoPy is your creation. Here's how I see it. Enabling easy
construction of high-quality experiments seems like the primary,
defining goal of the package. This is why people will try it out and
stick with it. Training or teaching good coding practices by example
is a noble but secondary goal. If it came along for free, that would
be great. But to learn python, I don't think people are going to start
and end with psychopy. And there's a real cost of supporting that as a
high priority goal, in terms of code complexity; supporting that fully
will mean that functional things will not get implemented, or not as
quickly. So as a compromise, I think a realistic goal is to generate
code that is readable and comprehensible, even if there are some rough
edges. Tradeoffs are acceptable, and heck, they even might lend
themselves to teaching (e.g., "Here's some auto-generated code that
works -- how would you optimize it?").

Currently, there are many ways that Builder-generated code is not what
you would write yourself. This is surely because of the considerable
added work required to further streamline / optimize (especially in
builder.py and experiment.py). The numpy imports are one example.
Another is that if you use the same routine 3 at three places in the
flow in an experiment (e.g., for practice and two sessions of real
trials), you get redundant code, like:

# Initialize components for Routine "trial"
trialClock = core.Clock()

# Initialize components for Routine "trial"
trialClock = core.Clock()

# Initialize components for Routine "trial"
trialClock = core.Clock()

To avoid this, we could go through and add checks and so on... ugh.
There are many other ways that the generated code is not going to be
tight. You get a trialClock whether or not your routine needs a clock.
Do we add a check for that? When might that check not be smart enough?

If you compile an .psyexp that consists of one routine having a single
code component with nothing in it, you get 100 lines of python that
queries for a subject number and then does nothing. You know, I'm okay
with that.

The Coder examples might be the place to strive for exemplary code.
Possibly there could be an included example or two of how to do the
same thing directly in code that will run exactly the same as one of
the Builder demos.

--Jeremy

> "psychopy-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to psychopy-dev...@googlegroups.com.

[Jonathan Peirce]

OK, fair enough.

On 18/04/2013 13:11, Jeremy Gray wrote:
>> I don't like
>> from psychopy import *
>> It encourages beginners not to think about what is being imported or what
>> imported names they might be overlapping with.
> Agreed. in retrospect I like listing everything explicitly much better.
>
>> I agree that sound is common enough that we might assume most experiments
>> need it, so we could add that to builder's load-by-default list.
>>
>> Not sure about importing microphone for all experiments. I feel like that's
>> still likely to be used relatively rarely, no?
> I have no real idea about microphone, although people are asking about
> usage (unlike say google speech or encryption). (As an aside, it seems
> like microphone should really be part of sound, not a separate module.
> This issue might be reason enough to do it. The previous thinking was,
> yeah, it probably should be in sound but its not worth the effort to
> change it now.)
>
> Two, more-general thoughts here. a) Besides style, is there any real
> cost of importing things that are not used much?

As with packaging additional modules in standalone, the answer is that
any individual answer is probably "no" but they all add up.

Does microphone import cleanly without errors everywhere now? We
obviously don't want to add this if it means the scripts start crashing
on system that don't have input (mic) drivers.

> How often do people
> use sin, cos, tan, log, log10, pi, average, sqrt, std, deg2rad,
> rad2deg, linspace, asarray? Isn't that the same issue?

Well, I think they are slightly different:
- these have essentially zero overhead (they're tiny)
- they put ideas in people's heads about what things might be
possible (I could do maths?)
- they might well be used in things like setting a stimulus
position, e.g. to set your stimuli in a circular pattern. Including them
obviates the need for a code component that would otherwise be needed
for this. Whereas the microphone is either used as a std component (so
the import can be added by the current standard method) or is used in a
code component, so the user could add the import too.

> b) Knowing that everything will be available means that Builder /
> experiment objects do not have to keep track, which would simplify
> their internal code.
>
>> Should we be trying to
>> 'train' people only to import what they need, rather than always importing
>> everything? Or should we not care about such things?
> Well, PsychoPy is your creation. Here's how I see it. Enabling easy
> construction of high-quality experiments seems like the primary,
> defining goal of the package. This is why people will try it out and
> stick with it. Training or teaching good coding practices by example
> is a noble but secondary goal.

fair enough.

I don't feel strongly about it. I think sound should be included as
default (and I agree that Microphone class should ideally be within
sound). I'm agnostic about moving mic now, and about including it by
default in builder scripts. I'll leave it up to you.

cheers,
Jon

--
Jonathan Peirce
Nottingham Visual Neuroscience

http://www.peirce.org.uk/

[Michael MacAskill]

I agree with Jon:

> I don't like
> from psychopy import *

But I also agree we should add a default import for 'sound', as this is exactly where the problems have been popping up for users. The need for microphone will be less common, and as noted, importing it by default might lead to increased instability for some users. There might not be stability or significant speed/memory costs with importing other modules, but I like being a bit judicious with them nonetheless. It won't make much difference for many users, but for those who go on to code things themselves, there is some didactic value in "training" them by example.

I don't think sin, cos, tan, sort, etc are in the same class as the other stimulus and hardware modules. A lot of people with exposure to many other programming environments might expect them to be core features of the language (I was surprised to find that they aren't). I think simple trig is crucial for doing any sort of calculated placement or animation of stimuli, as important as having access to randomising functions.

In the larger picture, is PyschoPy Builder an end in itself, or the "gateway drug" to proper, well-written, hand-coded experiments? I think it can, and should, be both, with the compromises that inevitably entails.

I've used Builder a number of times to create the skeleton of an experiment, using it to rapidly layout the overall structure and tedious boiler plate code, and then rapidly get straight to the more complicated bits in Coder. So I'd personally rather the code was as clean and efficient as possible. Explicitly seeing what has been imported (and the namespaces) is part of that.

At the end of the day, the system is reasonably robust. The recent post on the user list for creating a "loading wheel" animation has a *swag* of redundant imports in the code component, but I'm assuming the sky won't fall in there.

Cheers,

Mike

[Jeremy Gray]

Thanks for the discussion, Jon and Mike. Good stuff. I've added
'sound' to the list of things that are always imported. That seems
like a clear consensus.

I suspect importing microphone would be fine, because the pyo imports
are only done when you switchOn() the microphone. This is where people
are having issue (such as the recent unicode issue). But its a really
good point you guys raise that there are some unknowns here. I'll move
slowly here.

--Jeremy

> --
> You received this message because you are subscribed to the Google Groups "psychopy-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to psychopy-dev...@googlegroups.com.