Re: CurveData proposal

[Tim Janik <timj gtk org>]

On Wed, 15 Sep 2004, Stefan Westerfeld wrote:

>    Hi!
>
> As I'd really like to add a curve to the compressor, here is my proposal
> for curves. I also attached a patch against artscompressor.cc /
> artscompressor.idl, so there is an example how code using this proposal
> would look. It compiles here (with some tiny hackery you also see in the
> patch, as I #impl-included it into bse.idl).

hm, i had really hoped to have some kind of text-only write-up first
(i.e. a proposal with requirements, decision resoning, recommendations
and alternatives), before we get into implementation details.

i'll try to comment on what i think your code is intended to do...

> Some comments:
>
> While it would have been possible to make the proposal n-dimensional
> using sequences for axis and point coordinates, as I see no really
> practical way to display 3D or even higher dimensional data at the
> gui, I left it with x and y. This also has the advantage that a plugin
> writer will have a good idea how the corresponding widget will look.

right, i don't intend to implement a curve editing widget with more
than 2 dimensions anytime soon. there is not an actual need for this
atm (in contrast to two dimensional curves) and not an awfull lot of
examples out there in competing synthesis software either (not as far
as i'm aware at least, pointers welcome).

> The proposal allows drawing two or more functions into one graph,
> because I think there will be scenarios where a filter for instance
> displays a "desired" curve (like: an ideal lowpass) and an "achieved"
> curve (like: a lowpass with ripples).

looking at the patch, you actually used a sequence of functions.
that is just enough to "draw" the functions at the GUI, and nothing
more.
and even the drawing needs clarification, in your patch you got:

> choice CurveStyle
> {
>   CURVE_STYLE_DOTS,
>   CURVE_STYLE_LINE
> };

> record CurvePoint {
>   Real x;
>   Real y;
> };

and a sequence of CurvePoints. i guess with DOTS and LINE you think
of gnuplots drawing functions. where DOTS means the individual points
are simply marked with pixels, small crosses or a small circles, and
LINES means to draw n_points-1 line segments enclosed by the sequence
of points. am i guessing your right here?

what kind of constrains are implied for the points? e.g. may a
sequence of points consist of 5 points with the coordinates:
{0,0}, {0,1}, {1,1}, {1,0}, {0,0} to get a square?
if so, shouldn't we s/Curve/polygon/ ?

> When it comes to editing, there is probably room for improvement, as
> maybe if there are two functions in one graph, one of them might be
> editable and one not. In fact, I didn't think too much about editing at
> all yet, so when it comes to this, the proposal doesn't say much.

i do want a curve editing widget to be editable though (in fact, beast
already used to have one 3-4 years ago to edit instrument envelopes).
for that, if multiple functions are supplied, the functions/points which
are editable need to be identified.

and, edited points may be constrained by their environment, e.g. an
envelope point at the decay-sustain knee can't be moved beyond the
attack-decay or sustain-release points. this kind of logic can only
be implemented in the module, not the GUI, so the currently edited
point has to be supplied as information as well (so the correct point
is properly constrained by the module).

> I wasn't so sure about whether the CurveData should be containing
> colors. Since obviously, which colors might make sense might depend on
> the users theme, I ommitted this part.

colors greatly help to tell the curves apart. i think there is some
merit to drawing the curves with different colors. a few schemes
come to mind:
* the GUI picks random colors, kinda like gnuplot
  - this can be made to interoperate farily well with themes
  - but may mismatch in semantics, e.g. if the editable curve is
    drawn with lesser contrast or less brightly than the fitted version
* the module picks a color
  - colors may seem to be choosen kinda randomly as picks vary across
    multiple modules by multiple authors
  - this can be made interoperable with themes if colors too similar
    to the background color (picked by the theme) are inverted
  - if the module also picks a background color, there's no theming
    problem (but probably less integration with the rest of the GUI)
* the number of curves that can be drawn is limited to a fixed set
  - GUIs can provide a fixed set of colors, guaranteed to match the
    curve background
* an indication of "focus" or "importantness" or "emphasis" of curves
  could help GUIs to markup curves of particular interest in a
  prominent manner

> Finally, I choose not to open a subnamespace, although there are some
> curve related data structures now; prefixing them with Curve seemed to
> be okay. Not sure whether it should be Curve or Graph.

for what it's worth:
  namespace Bse { record CurvePoint; }
and
  namespace Bse { namespace Curve { record Point; } }
map to the same C and type system name. so in a way,
you did open up a namespace and may very well write
"namespace Curve" in the idl files.
as for Curve vs. Graph, consider the rename to Polygon i mentioned
above.

i'd like to get back to your choice of having a sequence of
curves for a second, i have a couple points about that:
- if the GUI picks different colors, does the sequence order
  have any correspondance with the order the curves are drawn
  in? so to generate the effect of some curves to be "on top of"
  or "in front of" others? and how would that interact with
  the introduction of an "emphasis" or similar indication featue?
- do we have actual use cases for more than 2 curves?
  so far, we have: envelope definitions: 1 curve
                   filter approximation: 2 curves
- if we come up with more use cases, can we decide on a sensible
  upper boundary for that, so to still allow GUI provided color
  schemse?

another issue are the axes, you got:
> record CurveData {
    /* the x-Axis */
>   String            x_axis_label;
>   Real              x_min;
>   Real              x_max;
    /* the y-Axis */
>   String            y_axis_label;
>   Real              y_min;
>   Real              y_max;
    /* the functions to draw in this diagram */
>   CurveFunctionSeq  functions;
> };

it'd be better to move those into an extra ...Axis structure.
this simplifies usage of the CurveData structure, and scales
better with future improvements like axis color specification
or a hide-axis flag.

>
>    Cu... Stefan

PS: i'd like us to stay with textual descriptions in this proposal
    as far as possible, so at the end we have something definite
    enough, so that it:
    a) can be used to implement the GUI in one rush, and
    b) can go into http://beast.gtk.org/plugin-devel.html as an
       extra section on displaying/handling curves.
    (i.e. one goal is to reduce the amount of GUI work i have to
    put into this. but if others are willing to help with this,
    i have no problems with more experimental GUI patches)


---
ciaoTJ