On Saturday 26 July 2003 14:33, Chris Cannam wrote:
>
> The main window is not an edit view. You can make dozens if not
> hundreds of different kinds of edits without having an edit view.
OK, I was thinking only of segment-level edits which require the segment's
mmapping to be refreshed. Are there any operations from the track editor
which require this ? Er, yes, I suppose displacing a segment horizontally
will do, since segment's mmapped events are stored with absolute times.
> > In the case of several
> > editviews, only one of them will trigger changes at a time, so the
> > mmapped segment gets updated only once.
>
> I don't get this part. They all have (sorry, had) separate
had ? EditViews no longer have seperate refresh-status IDs ??
> refresh-status IDs, and they all got paintEvent calls following a
> commandExecuted. None of them ever had any way of knowing that some
> other edit view had already refreshed the segment.
You're right, I assumed we were acting on the SequenceManager's own
refresh-status IDs, but looking at my initial version of the code we were
not. This was a quick'n dirty way of doing things I guess.
> Well, this is the question. I maintain that you don't want "immediate"
> in the sense of "every time an observer calls back", because you at
> least want to batch up the various edits that make up a single command.
Agreed, though an Observer can be made clever enough to work around that
problem. Though that would probably be fairly tedious to design.
> Also, we're not really talking about "when you're idle", we're talking
> about "when you next return to the event loop". This is likely to be
> almost immediately after the command has executed [...]
OK.
> Changing the transpose level (in the combo box on the segment parameter
> box) is non-undoable. Why? I can't remember. I think you tried to
> implement it, ran into some problem or other, and Bownie got in a strop
> and declared that we shouldn't bother.
I think that was because it was a play-time action.
> Probably better to work out which studio objects the sequencer actually
> needs to know about changes to first, of course, or at least which ones
> it needs a new mechanism for (e.g. the DCOP mechanism for Devices works
> OK already -- I have been thinking of making it use shared-memory to do
> the bulk device dump, but that's a quite different matter, the basic
> protocol would stay the same).
By shared-mem do you specifically mean SysV shm() stuff, or mmapped files ?
Implementing a mmapped "sequencer control block" was among my plans for the
mmapped branch at some point, DCOP is another possibility, but I'd rather
avoid pulling it a 3rd means of communication between the sequencer and the
GUI.
--
Guillaume.
http://www.telegraph-road.org
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Rosegarden-devel mailing list
[EMAIL PROTECTED] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
