| Reference | Downloads | Github

Glitching frames on JS but not PsychoPy & Rating scale error

URL of experiment:

Description of the problem:

There are 2 separate problems which I will describe below

  1. There is a glitching of frames on JS but not local runs.
    The experiment presents a Libet clock stimulus, that is a clock with one fast-moving hand.
    The clock hand is a line stimulus, whose ori and pos are dynamically changing as a function of t, to produce a clock-hand appearance.
    The experiment passes the ori on from one routine to the next, and I believe it is at this point where the glitch happens: On JS, but not locally, the hand stimulus briefly presents as a flat line, centered on 0,0 – which I think is because the line stimulus is initially defined like that, and the dynamic updating happens later in the code
    How can this be fixed

  2. the experiment uses a rating scale stimulus to elicit responses: The subject has to adjust the clock hand to a particular angle. They move the slider around and that dynamically moves the hand around. On JS, this throws a Reference error – it cannot find the rating component. I am not sure why this is.

Many thanks!

  1. You could have your begin routine code include the following:

(where hand is your clock hand object) and then in your each frame code, in the same code that sets the orientation


That should ensure that it only appears on the screen after the orientation has been computed.

  1. See here:

@jonathan.kominsky Thanks for this.

I implemented the AutoDraw as you suggested, but this does not solve the problem.
The glitches are still there…

As in, it still starts on 0,0 regardless? How odd. What you may need to do is set the initial position of the hand as something that is set on every trial (e.g., something that might be pulled from a conditions file) and then just start updating from there in your code. I assume if you change the settings of the object in the builder, that’s what you see on this first-frame “glitch”.

@jonathan.kominsky. Yes, still on 0,0.
How and where would I set the initial position & orientation? in Builder there is only the bit in the dialog box that is set to update every frame. The initial definition appears in the code only. Do you suggest I manually update the code on JS?

Is the object itself not a polygon component in the builder?

@jonathan.kominsky yes it is. And I have defined ori and pos in there and set to update on every frame

@jonathan.kominsky It might help to add that there are actually different components in each routine, rather than the same instance. This is because in each routine, the hand has different durations, or stops at different conditions.

Hmm. I might need to see the repository to figure out what’s going on. If it’s updating each frame then it should update on the first frame, at least in principle.

@jonathan.kominsky - can you access that via the URL? What do I need to do to make it available?

If you go to your dashboard and click “view code”, and link the page that goes to, I will be able to look at the full experiment repository and make a copy of it to do some bug-hunting. You will likely have to make the repository public, so on that same page, go to settings -> general -> permissions and set it to “public”.

@jonathan.kominsky – thanks so much.

I ve set it to public – here is the URL

It is currently acting as though it is not public, but this may just be GitLab being slow. I’ll try again a little later, but you might want to double-check that the setting was saved.

HI Jonathan,

Indeed, it had not saved.

Just changed it again


I definitely needed to see this one to work out what was going on. I can tell you the general rule of how to fix it, but you’ll have to fix it in several different places.

The basic problem is that in the builder, things that are set to update every frame don’t start updating until the first frame. In order to update the position and orientation of the clock hand before the first frame (so it starts in the correct position and doesn’t jitter), you need to manually set its position and orientation in the “begin routine” section of the code component on that trial. This is not all that intuitive, so I’ll add some illustration of what I’ve done to get the FirstEvent routine working.

First, let’s look at the properties of hand_6 in the builder, which were mostly correct except that you should remove the dollar sign before firstAngle, as I have done here:

Now, in the code component, I’ll give you an image of where this code goes and separately the text of the code itself:

hand_6.setPos([(0.095 * Math.cos(((3.14159 / 180) * (firstAngle - (t * 140.625))))), (0.095 * Math.sin(((3.14159 / 180) * (firstAngle - (t * 140.625)))))]);
hand_6.setOri((firstAngle - (t * 140.625)));

The console.log statement was just there to help me ensure the issue wasn’t with how firstAngle was being set, that turns out to be fine.

This probably looks rather familiar as it is the same calculations you put in the builder component with one important change (see below), but now we are running those calculations for t=0 before the first frame is drawn, and so the hand should appear in the correct orientation.

Note that you’ll need to change the position calculation to use Math.cos and Math.sin instead of just “sin” and “cos” when you do this.

I ran into a separate issues with the slider not rendering that you may need to do something about, but to start with you should try doing this to get rid of the flicker. The same general principle should apply to everything: If you need to set the orientation and position of an object before it is drawn, you should do it in a code component in the “Begin routine” tab as well as having it update each frame in the builder component. You could also set it to constant in the builder have the same lines in the “each frame” of your code component as well, but that’s effectively what setting it to “every frame” in the builder does anyways.

I hope that helps!

1 Like

Thanks a million @jonathan.kominsky.
That works.
Out of curiosity: Why remove the $ in the builder – is that now obsolete? I thought this tells Builder that it is a variable it is evaluating…
Thanks again

The $ is a builder-specific thing and seems Python-specific as well. See here: Referencing conditions file in code component

In my experience, it doesn’t work well if the variable being referenced is defined in a code element rather than a condition file. I’m not entirely sure why. Online, it also has a tendency to cause errors like this one, though again, I could not give you a complete explanation why: Reference error "$ not defined" on Pavlovia

Oh, one further thing to be aware of: Direction of rotation is flipped online versus local. I think you compensate for this already, but in case you get unexpected behavior, I thought I would mention it: