Chart History Length can be modified when running?

[skywalkerxp]

Gentlemen,

I am wandering it can be or not? :question: If not there is an alter way? :thumbup:

Thx

Qia

[aledain]

If there is no property node to let you do this (there isn't in 6.0), then create a LV2 global "buffer" and have this data displayed in a wavefrom graph. LV2 style globals are explained in the FAQ here. By adding "methods" to your functional global you can increase and decrease your buffer size in very efficient steps.

cheers, Alex.

[didierj]

If there is no property node to let you do this (there isn't in 6.0), then create a LV2 global "buffer" and have this data displayed in a wavefrom graph. LV2 style globals are explained in the FAQ here. By adding "methods" to your functional global you can increase and decrease your buffer size in very efficient steps.

3662[/snapback]

From the moment you want to scroll through your graph, change scaling,... you end up to have to extract the needed portion of your data and always updating your graph/chart. At my workplace we use such a program. It is quite slow and even gets slower after a few hours running (acquiring about 5 samples per seconds over serial!), or when displaying lot of data and scrolling through your graph.

When you scroll through the graph you'll have first to read the new position of the graph (beginning and end time), find the array indexes of these times in your data, extract this portion of data, redraw your graph. When scrolling with the "hand"-tool (pick-and-move), either your graph updates ever 2 seconds or your data acquisition (when done with serial or similar) hangs.

I recommend to use the chart and set the chart history length to a value that probably won't ever be reached. For actual computer with 256MB and more memory this is not a problem. Chart updates are done much more efficient when LV handles it internally than when written in LV.

Didier

[aledain]

I recommend to use the chart and set the chart history length to a value that probably won't ever be reached. For actual computer with 256MB and more memory this is not a problem. Chart updates are done much more efficient when LV handles it internally than when written in LV.

3665[/snapback]

That's true, but by changing your if you can change the "function requirements" you can/may gain speed and avoid the hang. For example, don't, allow the user the use of the hand, but instead add a new control (slider) to control the scrolling. Next, if the update rate is slow, set the viewed portion to some fixed subset and "max/min" the intervening points (say by an enum {All points {Slow}, Last 2048, Last 1024, Last 356, Last 218, etc}). This will mean a quasi-decimation of your data, but will be faster to update.

Combining controls to appear to create a "control" can be powerful; of course RAM is also sooooooo cheap too

cheers, Alex.