Jump to content

Chart History Length can be modified when running?


Recommended Posts

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.

Link to post
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

Link to post
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 :D

cheers, Alex.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.