Re: [bongo-devel] seek and volume

[Daniel Brockman]

address@hidden (Daniel Jensen) writes:

> Daniel Brockman <address@hidden> writes:
>
>> What if we somehow queued consecutive seek commands and only
>> issued them, say, once per second?  We would want a single
>> seek command to have immediate effect, but a ``continuous''
>> one (where the user holds the key down) to seek in batches.
>
> Now, this sounds too complicated to me. And maybe I don't really
> understand what it means. Are you suggesting a virtual key repeat rate
> of 1? That would defeat the purpose of key repeat.

Let's say you have a key repeat that sends 10 seek commands
per second.  The first command would not actually perform
any seek, but set a variable --- say `bongo-pending-seek'.
The first command would also set a timestamp variable.

As soon as you release the key you used to seek, the pending
seek would be performed.  If you don't release the key, then
your key repeat would cause more seek commands to be issued.
Each new seek command would compare the time to the timestamp,
and either do the seek or just change `bongo-pending-seek'.

But we can't implement this if we can't detect key releases.

> I do think that the jerky seeking is a problem, but with a
> lot of other good options at hand (keys 1-0 is a great idea)
> it is not urgent.

Okay.

> Unless there's a simple and elegant solution near, like
> somehow skipping a seek command that would "jerk", I
> suggest we leave this matter as a TODO item for now.

It occurs to me that that it might help to inhibit the
normal periodic time information updates while seeking.

I will experiment with this and get back to you.

>> If we can't make key-repeat-seeking work intelligently,
>> would you like to bring the old behavior back?  I don't
>> think I would, so maybe we could make it customiziable.
>
> I don't think this makes sense from an end-user
> perspective, so no.

Okay.

>>> The mpg321 program segfaults [...]
>
> You can forget about this problem now. I compiled a new
> mpg321 binary and it does not crash.

Oh, good!

Thanks, Daniel.  It seems we're sorting this out.

-- 
Daniel Brockman <address@hidden>