Re: Re: [Audacity-devel] What I want to implement for release

[<me...@me...>]

James Crook <cr...@in...> schrieb am 19.04.2003, 13:43:42:
> 
> ----- Original Message -----
> From: Markus Meyer 
> 
> > Just added bug #57 to bugzilla which describes what I want to implement
> > for the release.
> 
> [..extract from bugzilla#57..]
> > Make display more state-of-the-art (no flicker w/ background buffer etc.)
> > When playing, make cool scrolling (which needs acceptable amount of
> processor
> time)
> 
> Please say a little more about this Markus.

Currently no background bitmap is used for the update (I believe), so
updates flicker badly on my system. Although this doesn't really matter
to me this makes the app appear not as professional as it could. Also, I
don't like that when playing the cursor goes to the end, then redraws
the screen and starts from the beginning. This is confusing. I'm hoping
to be able to implement it that the cursor doesn't go further than to
the middle of the screen, then the wave form starts scrolling under the
cursor. I have created a small patch for this but I won't check it in
right now because of the flickering that occurs and because it needs an
inacceptable amount of processor time.

> I am thinking post 1.2.0 of implementing XaoS style zooming using a short
> cut.

At the moment, this has nothing to do with zooming.

> The idea is to get Audacity to draw to a bitmap at twice the resolution, and
> then
> use scaled down blt to screen - giving us zooming anywhere from x1 to x2
> without
> recalculating.  The bitmap would only need regenerating when we actually
> reached the x2 zoom level, and this could be done in a separate thread so
> that it
> would be ready when we need it.  I believe this is easier to implement than
> XaoS's method and would also be usable on any owner-draw display.

Hmm... that would be nice, but at the moment zooming isn't so badly slow
here either (then again, I have 2.4 GHz here).

> I would like a little more discussion of the improved display refresh, as I
> think
> taking account of this future possibility in its design would save work all
> round.

Yes, full ACK. It should also be possible that one updates the display
more often on faster computers  than on slower computers, just like you
get more FPS in games if you have more MHz. I personally wouldn't mind
if Audacity uses 90% CPU time for redrawing on playback, giving me 60
FPS on the preview, as long as playing still is uninterrupted. IMHO the
current design (using a fixed timer) doesn't scale well to faster or
slower systems.

> [..extract from bugzilla#57..]
> > Add "play fast (2x speed)" function
> 
> A possible cheap trick is to lie about the data rate to the play code.  At
> any
> rate could be OK for lower data rate sources.

I rather was thinking about pitch-preserving preview. This is very cool
when one has to dig through large live recordings, trying to find some
particular song etc. Although quality wouldn't matter too much, it would
still need some processing power.


Markus

> Again for post 1.2.0 I've been thinking that we could degrade play-quality
> (fewer samples per second) on lower power machines when mixing large
> numbers of tracks for playing-preview.  The logic for this is going to be
> very similar for the logic for speeded up play (when done properly, i.e.
> without the cheap trick!), so I'd like to suggest you bear that feature in
> mind as you (or we) write the 2x speed function.
> 
> Like the ideas.
> 
> --James.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Audacity-devel mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel