[gst-devel] fractions and aspect ratios

[Steve Baker]

> On Tue, 2004-07-13 at 23:42, Steve Baker wrote:
>> Thomas spoketh:
>> > - I also looked at creating a GST_TYPE_RANGE that would be implemented
>> > with a GArray with three members (lower, upper, increment).  A lot of
>> > code would be the same as for the LIST type, and we could convert over
>> > the GST_TYPE_INT_RANGE and GST_TYPE_DOUBLE_RANGE to it.  What do you
>> > think ?
>>
>> For GST_TYPE_RANGE to be universally useful there would need to be a
>> flag
>> which indicates the range as being logarithmic. We would then have to
>> define what the increment means for a logarithmic range.
>>
>> Examples of logarithmic ranges would be frequency and decibels.
>
> Hm, hadn't thought about that, could be an issue.  Can you give me
> simple examples of when it would make sense, for both of these, to have
> increments, and not just a range ?
>
> Anyway, the increment would then probably be treated as a multiplier,
> instead of an accumulator value, no ?

One approach which I ended up doing in dparams is if the range is flagged
as being logarithmic value then the lower and upper are stored in
GST_TYPE_RANGE as log(lower), log(upper). The increment then becomes a
value which linearly increments from log(lower), log(upper).

You can then do linear arithmetic for increments as you would for a linear
GST_TYPE_RANGE. When you want a real value back out again, you have to do
exp(value) to get the desired value back.

see demo_dparams.c lines 103 and 25 for this in action.

I don't know if this is the most mathmatically correct and
self-documenting way of doing it - perhaps some maths inclined developers
could clarify.

> Not sure yet where the information of what the increment does should be
> stored; maybe a fourth GValue holding an enum ?

Hopefully all that is needed is a fourth boolean GValue flagging it as
being logarithmic.

cheers