2008/5/19 pete shorthose <zenadsl6252@zen.co.uk>:
i'm currently looking towards releasing 0.9.4 soonish, to get some of
niceties out the way. (schemes, recent files, new file open dialogs,
rejig the transport bar, finally drag in the UI manager branch)

that being the case, i'd like to see the display cache in for 0.9.5.
Radoslaw, what's the status of that branch? i can see it still
has some bugs. would you be able to work on it at all?

Well... all caching aspects should be redesigned. First, display cache should be implemented on widget side, because it is widget specific (as you can read from the name: _display_ cache). Second, current display cache should be renamed to sample cache and its code need a lot of work (internal algorithm tuning, memory management, etc.). So it isn't stable yet.
For example, I have written a levelmeter widget for sweep (Pete, you should remember our earlier discussion about it) which uses cairo as a drawing api. First implementation which uses pure cairo in expose event was very sloooow/cpu intensive. In second implementation with clever display caching/compositing I've got more than 100 times speedup (about 30 frames/s and widget size about 80 x 1100) with cpu utilisation near 0.

In current implementation of sweep the most cpu intensive tasks are: sample_display_expose and scroll_pane_expose (you can check gprof data). Every time we want to update something on screen we redraw almost completely everything into those widgets. I'm writing new sample-display widget from scratch. It will have threaded drawing/compositing engine which allow to draw wave, spectrum, selections, markers, envelopes (for volume, pan or filter/effects parameters) and proper rulers all with cairo interface and all with reasonable speed :). If I'll get fast enough drawing speed i'll send information on the list. Next will be scroll_pane.

offline storage of the peak data would be good too. i've been thinking
along the lines of an xml doc with inline base64 encoded peak
data. base64 has a size and speed overhead but we could put all manner
of useful info in alongside it. eg:

peak data:
 base64 encoding 33% overhead (apparently)

selection history

selection names

assuming osc/midi input for use as an impromptu sampler,
 add assignments for midi/osc triggers to selections

cue points/markers

recently used plugins

file notes (arbitrary text block)

last window size / position

source metadata (tag info) from supporting types


Its a great idea. I should call it: Sweep Project file :). Alternate to base64 encoded sound data we can compress it by flac and store in separated files zipp'ed or tar'ed together with custom header (like openoffice does/did with its documents).

OTOH, we don't strictly need xml for any of that. the chances of
someone else needing to access that data is probably quite slim,
and any format we decide on would be necessarily open.
any thoughts?

I think xml should be easy extensible, but hard to make first implementation.

Radosław Korzeniewski