15 Mar
2005
15 Mar
'05
4:36 a.m.
Jens M Andreasen wrote:
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).
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 ... 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