Timed vs Transformer objects

[d3cod3]

Right now every object is a "timed object" synced with internal (not OF) fps, the idea is to add an alternative model that update instantly (next available cycle) only when data content change, a "transformer object"

[Daandelange]

This aspect changes quite a lot, depending on the final ofxVPParameter implementation. #22

Some quick thoughts on this :

The current parameters draft uses references, so values are always up-to-date, used on-demand in the nodes update() cycle. (No need to make them flow, by default.)

Both parameters and node objects will define how data flows, depending on their respective individual nature.

We'll have to define how data is sampled, synced and/or converted, if needed. And how to keep a continuous data flow.
...which will probably lead us to somehow implementing a system for flagging (+notifying?) data changes.
Which is also related to the bang type implementation. (which [imo] is different from an on/off boolean type)

All this seems a little far away, would these rather be optimisation questions for later ? (in terms of optimising the computation flow)
Anyways, it would be nice to enlighten these aspects for future compatibility.

[Daandelange]

Some more thoughts, some re-says :
ofxVPParameters will be able to address this issue, instead of the Object domain.
To sum-up : links will hold references to values, holding always up-to-date data, without copying values, eliminating the FPS sync model. Everything is real-time.
And there will probably be a mechanism for flagging/notifying parameter-changes, triggering object-recompute-functions.

Above of this, parameters could have an optional ParamModifier to sample data, average, smooth, etc. values.
Or is that interfering with the logic too much ? (better have a separate SmoothDataObject in between ?)

To bring in an example :
We could think of an ArduinoSerialRead object receiving an AnalogRead value from a distance sensor at a varying 200 fps. How do we inject this data to the Mosaic data flow ? The object could ensure the retrieved data changes only at 60FPS, but then we lose information. Mosaic's visual engine runs at 60fps, what about the rest. What if I'd like to use the full FPS distance value to generate some sound for example ? Or map the value to a 120Hz OSC output ?

[d3cod3]

About the data sampling/smoothing, i think it's better that ofxVPParameters just handle the raw data coming from wherever, and then having specific objects to clean/smooth/sample etc.. the data. This will guide the users to adjust the data speed depending of his/her needs while obviously depending of the machine capabilities.

Right now Mosaic run on the draw side at 60 FPS ( ofSetVerticalSync is active on the main window, while deactivated on projection windows ) while the update thread runs at the FPS the user set in System/FPS ( default at 60, with the upper limit will be the machine maximum FPS, depending on the patch load )

The issue about limiting the main window with ofSetVerticalSync is because, without setting the FPS internally with OF, i was having Mosaic running at maximum speed all the time ( on my laptop with linux i had more than 1000 FPS with an empty patch ), and that was reflecting in multiple threads consuming 100% of various cores ( a lot of heat, basically a computer destroyer )

So i choose this synching mechanism, without using the OF framerate, so i could control the processor resources, but having maximum speed on the update and on the render of projection windows ( the output window object ).

Now, your proposal is interesting, filter/map data depending on the receiving speed, we could plan different scenarios and think to something, but first i think would be better to give the current release some practical use testing, doing some complex patches, integrating different protocols and interfacing multiple data streams, then find the current weak points of the current mechanism and think of something better. I think that will help us a lot.

Feedback from other users too could help a lot, having multiple new pair of eyes trying stuff.

Anyway, we'll leave this issue open, let's see where we'll land.

[Daandelange]

Ok, thanks, lots of useful information in your post, sounds fair.
Ok to keep this for later, user feedback will be useful indeed to have a better overview of issues and needs.

[Daandelange]

An additional note to this: The Cinder framework seems to have a nicely architectured param class, and they seem to bind it to a Node class (which is basically a param holder/processor) which is dependent on the processing rate (glParams, audioParams, etc.)