[x3d-public] keyValue at first next for Sequencers [was: ScalarSequencer proto repo]

[Andreas Plesch]

http://x3dom-sequencers-next.glitch.me/SequencerFirstNext.x3d
(https://glitch.com/edit/#!/x3dom-sequencers-next?path=SequencerFirstNext.x3d:35:6
for source)

is a non-interactive test for what keyValue is provided after the
first 'next' input event to an IntegerSequencer with a keyValue='0 1'
.field.

'child 0' is shown if value_changed is 0, and 'child 1' if
value_changed is 1 with first 'next'.

x_ite, view3dscene, freeWrl, and x3dom show 'child 0'

The example proto, Octaga, H3DViewer and InstantPlayers show 'child 1'

BS Contact shows neither, eg. no value_changed is generated. Perhaps
it does not support the next field but there are no errors reported.

I have a slight preference for 'child 0', eg. the first value with
first next. If there should be a call for standardization of this edge
case, I could provide a spec. comment.

-Andreas

On Sat, Nov 11, 2017 at 10:33 PM, Andreas Plesch
<andreasplesch at gmail.com> wrote:
> On Sat, Nov 11, 2017 at 12:09 AM, Andreas Plesch
> <andreasplesch at gmail.com> wrote:
>> ..
>> Relatedly, for event utility sequencers, what should be the first key
>> and keyValue produced by the first next input event if there was no
>> previous set_fraction event (as a reference for next) ? Presumably the
>> first one in the key and keyValue arrays ?
>
> To demonstrate with an example fragment:
>
> <IntegerSequencer DEF='S' key='0 0.1 0.2' keyValue='2 4 6' />
> <ROUTE fromNode='touch' fromField='isActive' toNode='S' toFIeld='next' />
>
> Nothing else in the scene provides input to the sequencer, so the
> first 'next' input has to be relative to some default start index. The
> question is if the value_changed event from the sequencer will be 2 or
> 4 after the first next event.
>
> x_ite (and x3dom) will provide 2.
>
> InstantPlayer and the Proto implementation here
> http://www.web3d.org/x3d/content/examples/Basic/development/IntegerSequencerPrototype.html
> will provide 4.
>
> The spec. is inconclusive from what I can tell. Tooltip is silent.
>
> Will check other browsers.
>
> -Andreas
>
>>
>> On Sat, Nov 4, 2017 at 9:13 AM, Andreas Plesch <andreasplesch at gmail.com> wrote:
>>> I developed a first ScalarSequence proto here:
>>>
>>> https://glitch.com/edit/#!/ripe-taxi?path=index.html:65:12
>>> https://ripe-taxi.glitch.me/
>>>
>>> and it works with x_ite. I will test it in other browsers as well.
>>>
>>> Looking through the examples, I see that persisting state is mostly
>>> managed by initializeOnly fields.
>>>
>>> Interestingly, the BooleanSequencerPrototype example
>>>
>>> http://www.web3d.org/x3d/content/examples/Basic/development/BooleanSequencerPrototypeIndex.html
>>>
>>> declares local variables outside of the functions:
>>>
>>> var key, keyValue;
>>>
>>> But this is rarely done, and I am not sure if this is covered by the spec.
>>>
>>> I also noticed that fields of accessType inputOutput are often
>>> substituted by the corresponding inputOnly/outputOnly fields.
>>> In theory, inputOutput type in a script should enable set_ and
>>> _changed events, so I am not sure why this splitting is necessary.
>>>
>>> For example, is it sufficient for an inputOutput key field to write
>>>
>>> function set_key(val) { key = val; }
>>>
>>> to achieve both assigning the new value to the field, and also
>>> outputting of a key_changed event ?
>>>
>>> I think in x_ite it is sufficient but I will need to test.
>>>
>>> -Andreas
>>>
>>> On Sat, Nov 4, 2017 at 12:39 AM, Andreas Plesch <andreasplesch at gmail.com> wrote:
>>>> Working on a ScalarSequencer proto ,I developed the script which
>>>> provides the functionality:
>>>>
>>>> https://ripe-taxi.glitch.me/
>>>>
>>>> It seems to work ok using x_ite. In order to maintain internal,
>>>> persisting state, the script uses an initializeOnly field:
>>>>
>>>> https://glitch.com/edit/#!/ripe-taxi?path=index.html:161:21
>>>>
>>>> Perhaps this is the intended use of such a field but I was wondering
>>>> if there are other standard ways to have such internal state storage.
>>>> For example, it may be convenient to use a javascript object for state
>>>> which could not be a field value.
>>>>
>>>> It is possible to just use a global variable, initialized in the
>>>> initialize() function. However, in an environment such as web page
>>>> this would intrude other script sharing the global context. One could
>>>> use a namespace then, say script1.globalA
>>>>
>>>> With x_ite it is possible declare a scoped variable in the script but
>>>> outside the functions which then persists and is in the scope of all
>>>> script functions but out of scope anywhere outside the script. A good
>>>> solution but likely this is not guaranteed to work in other browsers
>>>> since the spec. does not cover code execution outside the script
>>>> functions.
>>>>
>>>> Perhaps the namespaced global variable would be the most standard way
>>>> but it would be great if global variables could be avoided.
>>>>
>>>> -Andreas
>>>>
>>>> --
>>>> Andreas Plesch
>>>> Waltham, MA 02453
>>>
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>
>>
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453