FR to Facilitate Custom Graph Creation

[dmbaer]

... because I know Vojtech has vast amounts of free time.

Seriously though, this would be extremely useful to anyone who has occasion to define custom transformation graphs. For other than simple shapes with few points, graph data entry can be quite tedious. It would be very useful to be able to import data from a .cvs (comma delimited) file. These can be created in and exported from Excel or pretty much any other spreadsheet program.

Common-sense restrictions on the data would be reasonable. E.g., values are assumed to be evenly spaced on the X-axis and Y-axis value must be between -1 and +1 or 0 and +1 (depending on graph bounds).

Anyway, please give it some thought. I could be wrong but I suspect this one would not be hugely challenging.

[MeldaProduction]

Ok, so find 20 people, who would use it and I'll make it happen . It would be quite easy, but it would be yet another feature to clutter the GUI, which would be used by 1 people in 10000 probably imho.

[dmbaer]

Ok, so find 20 people, who would use it and I'll make it happen .

If one person used it 20 times, would that count?

I would just ask instead: how many users aggressively use transfer curves? Probably not that many, admittedly. However, once you discover what can be done with them, you find all sorts of places where they make sense (at least such was my experience).

I would further refine my original idea to suggest that a feature for importing transfer curve data would not really be useful for osc. waveforms - only for transfer curves. If not an import capability, then maybe some kind of column-oriented value entry capability would be OK (especially if it had a paste option). The thing about transfer curve data entry is that it can be really fatiguing doing it with precision mouse gestures.

[MeldaProduction]

Import from a text file would be much easier . I'll think about it. How about an expression evaluator instead? I mean I sometimes need to approximate like ln(x^2) .

[dmbaer]

Import from a text file would be much easier . I'll think about it. How about an expression evaluator instead? I mean I sometimes need to approximate like ln(x^2) .

A CSV file is essentially a text file that guarantees the data is in columns, one line per record and that the column values are separated by commas.

In the case of transform graph import files, you could impose the following rules:

- one or two columns; if one, it's the y values; if two columns it's x then y values; if two columns, white spaces, tabs and/or comma can be the separator; all records must have the same number of entries (one or two) as the first record
- all values between 0.0 and 1.0 inclusive
- if y values only presented, the x values are assigned so that they are evenly spaced, starting at 0.0 and ending at 1.0
- if x values are presented, a entries for x=0.0 and one for x=1.0 are mandatory (or else assumed to be (0.0, 0.0) and (1.0, 0.0) for example)

In other words, just basic common-sense specification of the data - no overthinking required.

As for the expression evaluator, it might be handy in some cases, but it is unlikely it could ever be as powerful as doing expression evaluation in Excel, for example. Excel can export a csv file, which as pointed out above, is actually just a text file. Whatever open-source spreadsheet program someone might use should have the same capability, so this is a very general solution, I believe.

By the way, an expression evaluator would have to be way more work than a text file import capability, I'm pretty sure.

[MeldaProduction]

I know CSV files of course, so no problem. I don't really get half of what you wrote really , but I assume simple text file like:
0.232342;5.214
2.24953;3.353425

would do the trick . I'll think about it then. Expression evaluator may actually be about the same (since I already have the engine)

[dmbaer]

I know CSV files of course, so no problem. I don't really get half of what you wrote really , but I assume simple text file like:
0.232342;5.214
2.24953;3.353425

Well, it depends on whether the range was 0.0 to 1.0 or 0.0 to 100.0 (percents) - either range would be just fine. Your example would be valid if the second option was in effect.

But basically yes, two numbers on a line would be an (x, y) pair. Valid separators should include white space (other than new line) and comma. Really any other delimiter other than period (aka decimal point) would also be fine. Choose what to do if no (0.0, y) and/or (1.0, y) pair are provided - to just assign a default value pair, e.g. (0.0, 0.0), would be fine. Rejecting the file import as invalid would also be just fine. If the input was messed up, the user would see that right away when looking at the shape of the resultant graph.

If there was just one column, you could take that to mean all points are evenly spaced along x axis (or just require two columns - no big deal if that's a strict requirement).

[MeldaProduction]

Done with ';' as delimiter, that's imho the only reasonable choice, because whitespaces are just used normally and ',' is a decimal point in some countries (like Czech ).
Expression evaluator added too

[dmbaer]

Done with ';' as delimiter, that's imho the only reasonable choice, because whitespaces are just used normally and ',' is a decimal point in some countries (like Czech ).
Expression evaluator added too

Looking forward to seeing what the expression evaluator is.

The ";" delimiter is really not a very reasonable choice IMO. Excel (and probably other spreadsheets) can export files as CSV (which presumably will use the local equivalent of comma), as tab-delimited, and as space delimited. There appears to be no option within Excel that can be used to specify the delimiter character (e.g., no way to say "use semicolon as the separator character"). Now, admittedly, it's not that big a deal to bring a text file up in an editor and change all commas to semicolon. But it's an extra step that shouldn't be necessary.

It seems to me you should just load the file, change any occurrence of semicolon to space and proceed with the parsing, using any sequence of whitespace characters as a delimiter. C++ string streams make value retrieval of space separated numeric values trivial, does it not? Whitespace-delimited files (exportable directly out of Excel) could be loaded without further ado. Requiring semicolon as delimiter is extra work.

Don't take this as a gripe - I'm pleased we've gotten 99% of the way there. I'm just adding a suggestion as to how we get to 100%.

[MeldaProduction]

Hmmm, I just checked in openoffice and ";" is definitely available. Anyways ok then, it will search for ";", if not available then ",", and if even that is not available, tab will be the one. But really, I have actually never seen a CSV with a delimited different than ';'

[dmbaer]

Hmmm, I just checked in openoffice and ";" is definitely available. Anyways ok then, it will search for ";", if not available then ",", and if even that is not available, tab will be the one.

That's certainly a thorough and general solution - thanks.

But really, I have actually never seen a CSV with a delimited different than ';'

Well, unless I missed something, with Excel, the only way to get a ";" delimiter in the USA is to change the Windows locale setting, which would make all kinds of other things outside of Excel really messed up.

[MeldaProduction]

Interesting!