[linux-audio-dev] Lock-free gtk/jack interaction

[Olivier Guilyardi]

Jens M Andreasen wrote:
> On Mon, 2005-03-14 at 17:34 +0100, Olivier Guilyardi wrote:
> 
> 
> Inserting the new widgets and having them propagate up thru the layout
> engine in order to be redrawn is probably expensive whatever way you do
> it.

Yeah, I'd have to reparent widgets, destroy a gtk table, and show the whole 
thing up again. I guess it wouldn't be such an optimization. Needs testing though.

Of couse with a gtk DrawingArea, I could optimize the drawing at low-level, but 
I don't think I'll go that way. I like these gtk buttons, altough inspired by 
Aube's drummmachine, it's Jackbeat's touch ;-) Especially I like the way they 
scale : recoding that kind of dynamics within a DrawingArea would be much work.

> Scrapping the underlying structure (is "workspace" equal to "sequence_t"
> here?) sounds a bit overdramatic though. I would instead like yo
> envision something like blocks of 32 tracks × 32 beats that can be
> extended vertically or horisontally as in:

No I'm not scrapping the whole sequence_t structure when resizing the workspace 
(=tracks/beats/measure length) only the sequence_t->tracks member. This indeed 
could be optimized by playing with pointers, but I believe the bottle-neck is 
drawing widgets not resizing the actual underlying tracks data.

> In this fashion you could most of the time get away with adjusting
> max_track and/or max_beat. A deleted track will stop sounding when you
> hear the click from the mouse-button (although it may take a little
> longer before the UI has rearranged itself.)

Well, vertically, for tracks, it makes sense to use say blocks of 8. But for 
beats this is not that useful.

>>By redesigning the gui, I would keep many widgets as they are and only create 
>>some new ones, or destroy a few... This is very important, when you have a big 
>>workspace (ie: 1k beats, 16 tracks), because things then get very slow the way I 
>>currently do.
> 
> Yeah .. I can imagine that one to be slow :) OTOH, the whole concept is
> pretty much broken by then ...

The thing is I personnally used such high number of beats, but it is not a good 
idea. I want to implement "sequence nesting" since the first lines of Jackbeat, 
which would help avoiding such big sequences : you could nest a sequence into an 
other, that means assign a sequence to a track as you assign a sample.

With a few sequences on your screen you could then achieve both long melodies 
and precise rythms.  But I was unsuccesul with my first attempt to code a such 
sequence "graph" (it is not just a sequence "playlist", you would be able to 
cascade sequences).

> Waiting for IO is a classic way of having the UI get stuck and
> irresponsive. Therefore the nice people at gtk.org made this writeup:
> 
>    Monitoring IO
>    -------------
>  
>    http://gtk.org/tutorial/sec-monitoringio.html

I'm not sure what you see this for : receiving messages from the RT thread 
trough a named pipe, or reading from song files ? In the first case, that 
gdk_input_add() could indeed be useful, in order to implement the RT-to-mainloop 
notifications Paul talked about.

Thanks

--
   og