Rate of power _change_ as scaled control value

[stephenwhitmarsh]

Not only might this give interesting extra continuous dynamics from the same 'source', it reflects, at least conceptually, a cognitive phenomenon: e.g. a sudden change in attention (in the case of alpha), versus a stable state. Interestingly, by normalizing the change of power (i.e. after calculating the rate of change), rather than the power, they would be further independent. Of course, the same idea might be applied to other continuous control values, such as EMG envelope, or heart-rate. David Roosenboom has also been using something like the rate of change in alpha, and uses that to trigger events. He conceptualizes this as 'surprise', which is a nice way to put it.

Where would be the best place of implementing this?

• I see no better place than doing this directly within spectral/heartrate/etc. Historycontrol would even be an option, although that would create some extracomplexity as we would need to use historycontrol to help normalize the values in the end.

What would be the best way of implementing this?

• something could be said about just doing a diff, i.e. (old-new)/stepsize. Easy and clear. This would further point to implementing it in the spectral/heartrate module.

[robertoostenveld]

Why not implement it using postprocessing?

[robertoostenveld]

Why not implement it using postprocessing?

One reason not to do this is that the Redis control values are only updated every now and then (typically every 50ms), which makes it a step-like function. Taking the derivative in another module that is not exactly synchronous will lead to jitter in the derivative output values.

I do think that a special derivative module would be better (more in line with the architecture) than replicating the functionality. It could work by using the pubs triggers that are sent with each EEGsynth.setvalue update. It could in principle be implemented in the existing processtrigger, but I think that a separate derivative module would be easier to use.

PS Considering symmetry, we could also make an integrate module.

[stephenwhitmarsh]

Agreed, I'll try a difference module Op ma 4 nov. 2019 om 08:55 schreef Robert Oostenveld < notifications@github.com>:

…

Why not implement it using postprocessing? One reason not to do this is that the Redis control values are only updated every now and then (typically every 50ms), which makes it a step-like function. Taking the derivative in another module that is not exactly synchronous will lead to jitter in the derivative output values. I do think that a special derivative module would be better (more in line with the architecture) than replicating the functionality. It could work by using the pubs triggers that are sent with each EEGsynth.setvalue update. It could in principle be implemented in the existing processtrigger, but I think that a separate derivative module would be easier to use. PS Considering symmetry, we could also make an integrate module. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#346?email_source=notifications&email_token=AC3TIBTYNTJLNELWOLI4WSTQR7IOBA5CNFSM4JIE5TF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC6OPKA#issuecomment-549250984>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3TIBQUP6VBOXEOBN3HX5LQR7IOBANCNFSM4JIE5TFQ> .

[stephenwhitmarsh]

I've got the basis for a difference module, based on existing code. However, I am now a bit confused about how we deal with with triggers/pubsub; i.e. the TriggerThread objects you use. I've been under the impression that dealing with triggers was a more "wait until a pub", i.e. discontinuous process. How I read the TriggerThread code now is that these are just while loops that continuously listen. The effect might be the same of course. I just want to be sure, before I continue, that there is not a better way than taking a TriggerThread loop, and:

• before the while loop, initialize 'old' values
• in the while loop, check whether values are different from old, if so make a diff, new becomes old, etc.

[stephenwhitmarsh]

Correction: we need to know whether values have just been published (and time in between), and do not care whether they are different.

[stephenwhitmarsh]

Perhaps even a better idea - can't the monitor.update be used for this? It already keeps track of previous values, and it could add timing. Or even better, implement a similar object in the difference module... neat! I'll try that

[stephenwhitmarsh]

Actually, can't we expand the EEGsynth class, either by extending the monitor.update method to output a 'diff' (when asked), or in some other way? We can then use that in a skeleton that creates the threads etc., as is done in the other functions such as writetrigger, processtrigger, slewlimiter etc.