[Jeremy]

Hi Sabrina,

Re. the image problem, this is likely due to the high number of requests for files sent to the server within a short time period. It would most likely improve with a dedicated server (as the farm’s server is already close to saturation all the time) but the issue has happened with a dedicated server too. The solution most likely to prevent this issue is to consolidate the images into a zip file. See this post on how to use the zip file method with the S3 service of the AWS Free Tier offer

Re. the save problem, a less radical workaround consists in re-creating the file, rather than copying the whole project. Reference

Re. the results, there are two known issues. The first is, it takes time for results to be added to the database, so you will likely need to wait a few hours before you can see the latest submission. The other issue is, if you try to access the results several times without refreshing the page, the different requests can sometimes conflict and you end up with incomplete or redundant results file. So ideally, always refresh the page before accessing the results. Reference

[Jeremy]

Hi,

When you print a TextInput element, PennController gives it focus by default, so that the participant can start typing right away. The most recently printed TextInput element will take focus, and if an element has focus outside the current viewport, browsers usually automatically scroll down to make it visible

One workaround is to wait a few ms after printing the last TextInput element, at which point the browser will have scrolled down, and tell it to scroll back up:

    newTextInput("123aaa", "")
        .print()
        .log()
    ,
    newTimer(20).start().wait() // wait for focus to take effect
    ,
    newFunction( ()=>window.scrollTo(0,0) ).call()  // then scroll all the way back up

Jeremy

[Jeremy]

Hi,

Unless you have high-quality hardware in a controlled environment, you won’t reach millisecond-precise computation. Every single instruction takes time to be executed on a machine, including low-level steps such as receiving and processing audio signal from the microphone or updating the display on the monitor, or higher level steps such as executing the PennController commands in your script

Some things work in a cyclic way, including the way Timer elements work, and I think audio processing too. If the process happens to start near the end a cycle and end near the beginning of another cycle, you might end up with two extra cycles (compared to a situation where the process happens to start at the beginning of a cycle and end at the end of the current cycle)

Because you call record on the MediaRecorder element and then wait on the two Timer elements before calling stop on the MediaRecorder element, the audios will be at least 3000ms long. But if the Timer elements happen to be longer than their respective duration, the audios will be longer too. Plus the delays due to internal processing

The differences you see between the End-Start subtractions and the actual audio file lengths are also due to processing delays: the MediaRecorder element logs when the record and stop commands are executed, but there also are small delays between when the commands are executed, and when they actually take effect at a lower level. Ideally, I should have designed the element to log both the timestamps of the record and stop commands, and the actual start/stop events of the recorder (which should be closer to when recording actually happens)

You might get closer to an actual duration of 3000ms by doing away with the extra layer of PennController and writing your experiment directly in javascript instead, but you will likely still end up with delays, because javascript is executed in the browser at a rather high level. If you really need high time accuracy, you’d be better off writing your experiment using a lower-level paradigm and running it on the same machine using a high-quality recording device for all your participants. Then you’ll get as close to 3000ms as can be nowadays

Jeremy

[Jeremy]

Hi,

This is because the TextInput element gets deleted once the trial is over, and the .log command on newTrial() is executed asynchronously, so this command will fail when it so happens that it is executed after the trial is over: .log("answer", getTextInput("answer_box"))

Use a global Var element to make sure the element persists outside the trial and the log command never crashes:

            .wait( getTextInput("answer_box").testNot.text(""))
        ,
        newVar("answer").global().set( getTextInput("answer_box") )
    )
    .log("code", row.code)
    .log("context", row.context)
    .log("answer", getVar("answer"))
)

Jeremy

[Jeremy]

Hi,

Using version 4, replace the content of PennController.css with this:

.PennController {
    position: static !important;
    width: auto !important;
}

This way, the main container will inherit the max width of its children (including the 1000px width of the Maze controller) and because its position will be set to static, it will be centered by default. Note the !important keywords to overwrite the style that’s normally applied by the PennController script itself

Re. the labels on the radio scale, explicitly set their positions so they’re printed accordingly: .labelsPosition("right")

Jeremy

[Jeremy]

Hi,

I’m not sure if you want to move on to the next trial without logging any keypress if the participant does press the spacebar before the three seconds have elapsed (and otherwise still wait for a keypress on the spacebar after those three seconds have elapsed, but make sure the keypress is logged), or if you want to automatically move to the next trial after three seconds without logging any keypress if the participant fails to press the spacebar within that time window

The former would look like this:

newKey("space", " ")
,
newTimer("3s", 3000).callback( getKey("space").log() ).start()
,
getKey("space").wait()

the latter would look like this:

newTimer("3s",3000).start()
,
newKey(" ").log("last").callback( getTimer("3s").stop() )
,
getTimer("3s").wait()

(Note that with the latter, you’ll still have a line in the results file that says “Never” if the spacebar is pressed after 3s)

Jeremy

[Jeremy]

Hi,

This is a bug caused by the embedding of after commands: shuffle will try to move the elements around, but since some are embedded inside other ones, it ends up crashing because of a recursion issue

A workaround consists in printing all three Text elements inside a container Text element:

newText("agent",row.agent).bold().color("red").css("margin-right","0.25em"),
newText("verb",row.verb).bold().color("red").css("margin-right","0.25em"),
newText("patient",row.patient).bold().color("red").css("margin-right","0.25em"),

newText("container", "").css("display","flex").print(),
getText("agent").print(getText("container")),
getText("verb").print(getText("container")),
getText("patient").print(getText("container"))
,

newSelector("triads")

Jeremy

[Jeremy]

Hi,

This message only remains on the page if there’s nothing after SendResults(). If you have a trial coming after it, then the experiment moves on to that trial as soon as the results have been sent

You can remove the message altogether by setting completionMessage to "":

completionMessage = ""

newTrial( newButton("Hello World").print().wait() )

SendResults()

Jeremy

[Jeremy]

Hello,

I am unable to replicate the problem, using either Chrome or even Firefox: in both browsers, I seem to hear the audio files fully (sometimes the very first phoneme sounds more like a glottal stop to me though, but maybe that’s intentional)

What happens if you try to place all the newAudios at the beginning of the trial instead, and use getAudio("...").play() wherever you are currently using newAudio("...").play()? Does the situation improve?

Jeremy

[Jeremy]

Hi Yev,

All the “three”/”3” filenames referenced in your CSV table end with .jgp instead of .jpg

Jeremy

[Jeremy]

Hello,

You can use <p> tags in your Text elements to tell your browser to print them as paragraphs, which browsers usually surround with spacing by default (eg. newText("<p>1. Me interesa tener amigos de mi cultura nativa.</p>")) or just add some spacing using CSS (eg. defaultText.css({"font-size": "1.2em", "margin": "0.5em"}).print())

Jeremy

[Jeremy]

You can try deleting the mp3 file from the project altogether, and then uploading it again, and see whether the problem persists

Jeremy

[Jeremy]

Did you happen to upload an earlier version of that mp3 file, and overwrite it with a newer version since then?

Jeremy

[Jeremy]

Hi,

Those visual renderings are consistent with the audio file failing to load. I share your confusion, since you’re only fetching two audio files from the farm, so I can’t imagine the server being overloaded. Have you heard of other people experiencing this problem? I’m thinking it could be specific to your testing, if you sent multiple requests for that file across your test runs, maybe the server is being slow to serve it back, or your browser thinks it has a version in cache but fails to find it. I don’t know, really..

Jeremy

[Jeremy]

Hi Lily,

Could you share the demonstration link to your experiment, here or at support@pcibex.net, so I can have a better look at the situation? Thank you

Jeremy

[Author]

Posts