Excellent! Thanks for the pointer. And like what I've seen of wxWidgets as well.
-Sean
Dear Sean,I gave some thought to the enhancement of stimulusframes/stimulustimes while keeping in mind my above remark about not making things too complicated for the average user. Here's what I'd probably do: allow counters as timing specifiers. Just counters, nothing more. Dynamic timings could then be achieved without any need for expressions, as well as things like a timing "repository" where timings would be specified once within a script (i.e., in a counter) and then distributed across all trials.Programmers should be even more satisfied if you additionally allowed expressions as elements in counters. If memory does not fail me, expressions can be embedded in counters but they only become evaluated once at the beginning of an experiment which does not suffice.Enabling dynamic timing definitions by whatever means may bring a feature suggestion back to the table that I voiced a while ago: ISIs as an alternative to SOAs in a trial. My syntax would read(1) The Inquisit SOA variant/ stimulusframes = (1=pic1; 100=pic2; 500=pic3; 750=pic4; 900=blank)(2) The ISI variant/ stimulusframes = (99:pic1; 400:pic2; 250:pic3; 150:pic4; 1:blank)The time course is identical in both variants (pic1 for 99ms, pic2 for 400ms, pic3 for 250ms, pic4 for 150 ms), only the definition is different. Following a cumulative timing scheme as granted by ISIs, counters could be employed with maximum flexibility for timing specifications.To summarize:(1) Allow counters as timing/frame specifiers in a trial(2) Allow expressions in counters and have them evaluated every time the respective item is accessed(3) ISIs as an alternative to SOAs for timing specification.With that, I see no need for expressions in timing definitions, plus, most Inquisit users will already be familiar with all concepts required to set up dynamic timings.Malte.
Not quite the same thing, but the following should work:
<values>/ sometext = "a"/ someothertext = "bracadabra"</values><expressions>/ myexpression = concat(capitalize(values.sometext),values.someothertext)</expressions><text mytext>/ items = ("<%expressions.myexpression%>")</text>
~Dave
Hi Dave,
ever since some remote entity named D. pointed me to expressions I strive to have the number of trials in my scripts not exceed one. This requires to store the code of the current experimental condition into the trialcode at runtime. I'm using a lot of format() statements there and came up with the same solution as suggested by you. I find it funny, however, that expressions work and functions do not.
Bye, Malte.
How dare he do that to you?! Tell me where that guy lives and I'll go by his place and beat him up!
Another feature request:
/ writetodatafile = true|false
as a <trial> attribute.
This way you could exclude none-essential trials (e.g., those which do not produce subject generated data) from being stored in the data file, thus making the data file more immediately analysis friendly.
Bye, Malte
The <trial> element already features the '/ recorddata' attribute which will do just that.
Well, SOLVED, I guess... *flushing*