Re: [Rosegarden-user] Comments on some RG issues

[D. M. M. <mic...@ro...>]

On Saturday 16 August 2008, Peter Plessas wrote:
> Is it consistent to have the resizing be destructive from left-to-right
> and being reversible to some extend from right-to-left?

As far as I can tell, it is consistent, and my long memory of experience 
interacting with the application agrees.  If this isn't documented properly, 
I'd consider that a bug, but the behavior itself is pretty much not up for 
debate at this point.  There is a complicated technical reason why we behave 
this way.  We realize the behavior is inconsistent, but doing the same sort 
of non-destructive resize from the left is much more technically difficult, 
and dare I say a problem we couldn't figure out how to solve at all.

> On the spacebar issue (changing its meaning once the transport window
> has focus) please see my other mail to David Tisdell, forwarded to you
> as well.

I have some vague idea what you mean, but no energy to investigate more deeply 
at this time.

> >> This behavior can't be changed in a config file.  I really don't like
> >> this idea at all.  It would drive me completely nuts.
>
> You are right again not to make everything customizeable, so what do you
> think about changing the default behavior of the scroll wheel to a
> horizontal scroll instead? Would that have to be a community decision?

No, there wouldn't have to be a community decision, because I actually use 
Rosegarden myself, and this behavior would drive me nuts, so the answer on 
this being the default is a firm no.

We could probably have more debate about it being configurable, but as I said 
in the other message, we really can't afford to get sidetracked with things 
like this at this time.  We should debate comparatively trivial details of 
user interaction after 2.0 gets into at least a working alpha state.  (It is 
currently miles of slogging away from building at all.)

(I'm rearranging the order of your comments, so I can put the big blurb of 
debug stuff at the very end, so you won't have to wade through all of it to 
find the rest of my reply.)
> Don't you ever need that? Like: Stopping playback, and then jumping to
> the beginning of the song using a shortcut? Can this be added? Using
> "Pos1" perhaps?

I always just hit the rewind button on the transport, with my mouse.

Shelagh already pointed out that it's possible for you to create your own 
shortcut for this.  We'd consider adding it as a default for everyone, but 
again, as I've said elsewhere in this discussion, just not at this time.

> >>> - Recording very much Midi data makes RG become slower and slower on
> >>> screen redraws, the finally halting the whole program so that one
> >>> looses recorded midi data. This happens on an otherwise powerful enough
> >>> machine.
> >>
> >> I've never had this problem.  How much is "very much?"
>
> Like in that midi file: http://mona.mur.at/xeq_test_240sek.mid
> (about 35000 notes within 4 minutes)

What do I do with it, exactly?  Load it and then start trying to record 
something on top of it?

> You made me very happy with your reply to my comments. Isn't it great
> that there is so much wonderful exchange going on in open source
> software projects?

We can agree on that too!

> Aha, so the internal representation of notes is already done in respect
> to notation? Or do you do the score rendering over again after the
> shifting?

I have to confess that I'm not completely sure I understand all of this 
myself, now that I've poked around and had a look. What I said about our 
storing notation-related properties with all events is true, but that isn't 
what's happening here at all.

I'm doing an experiment.  I loaded a MIDI file that contains an entire 
symphony in one file, which should serve well as an example of a "longer 
segment with many notes inside."  I shifted one of the segments four bars to 
the right, and sure enough, it shut Rosegarden down for a long time.  My CPU 
didn't go to 100%, and it didn't really affect anything else running on my 
computer, but it did shut Rosegarden's user interface down for the duration.  
It wouldn't repaint itself, or respond to input, and appeared to have gone 
dead.

I had to go back and do a full debug build to get a look at what was 
happening, and here it was.  The move generated a few billion lines of this 
stuff, of which I've pasted just the end (forwarding to the devel list for 
further contemplation):

rosegarden: CompositionModelImpl::endChange
rosegarden: SegmentOrderer::segmentClicked() s = 0xb533a7a0 - max Z = 37
rosegarden: [Rosegarden::CompositionItem 
Rosegarden::CompositionView::getFirstItemAt(QPoint)] no item under cursor
rosegarden: [Rosegarden::CompositionItem 
Rosegarden::CompositionView::getFirstItemAt(QPoint)] no item under cursor
rosegarden (sequence manager): SequenceManager::event() with user event
rosegarden (sequence manager): SequenceManager::event(): update requested
rosegarden (sequence manager): SequenceManager::checkRefreshStatus()
rosegarden (sequence manager): SequenceManager::checkRefreshStatus: segments 
modified by changes to trigger segments are:
rosegarden (sequence manager): SequenceManager::checkRefreshStatus: we have 5 
segments
rosegarden (sequence manager): SequenceManager::segmentModified(0xb461d458)
rosegarden (sequence manager): 
CompositionMmapper::segmentModified(0xb461d458) - mmapper = 0x94189d8
rosegarden (sequence manager): 
SegmentMmapper::refresh() - /tmp/kde-silvan//segment_b461d458 - 
m_mmappedRegion = 0xb543d000 - m_mmappedEventBuffer = 0xb543d004 - new size = 
27524 - old size = 27524
rosegarden (sequence manager): SequenceManager::segmentModified() : size 
changed = false
rosegarden (sequence manager): SequenceManager::segmentModified(0xb46231f8)
rosegarden (sequence manager): 
CompositionMmapper::segmentModified(0xb46231f8) - mmapper = 0x9418258
rosegarden (sequence manager): 
SegmentMmapper::refresh() - /tmp/kde-silvan//segment_b46231f8 - 
m_mmappedRegion = 0xb5436000 - m_mmappedEventBuffer = 0xb5436004 - new size = 
27044 - old size = 27044
rosegarden (sequence manager): SequenceManager::segmentModified() : size 
changed = false
rosegarden (sequence manager): SequenceManager::segmentModified(0xb4b24608)
rosegarden (sequence manager): 
CompositionMmapper::segmentModified(0xb4b24608) - mmapper = 0x8efea48
rosegarden (sequence manager): 
SegmentMmapper::refresh() - /tmp/kde-silvan//segment_b4b24608 - 
m_mmappedRegion = 0xb4c04000 - m_mmappedEventBuffer = 0xb4c04004 - new size = 
516644 - old size = 516644
rosegarden (sequence manager): SequenceManager::segmentModified() : size 
changed = false
rosegarden (sequence manager): SequenceManager::segmentModified(0xb533a7a0)
rosegarden (sequence manager): 
CompositionMmapper::segmentModified(0xb533a7a0) - mmapper = 0x9420c60
rosegarden (sequence manager): 
SegmentMmapper::refresh() - /tmp/kde-silvan//segment_b533a7a0 - 
m_mmappedRegion = 0xb5121000 - m_mmappedEventBuffer = 0xb5121004 - new size = 
518004 - old size = 518004
rosegarden (sequence manager): SequenceManager::segmentModified() : size 
changed = false
rosegarden (sequence manager): SequenceManager::segmentModified(0xb53e3968)
rosegarden (sequence manager): 
CompositionMmapper::segmentModified(0xb53e3968) - mmapper = 0x8f5fe40
rosegarden (sequence manager): 
SegmentMmapper::refresh() - /tmp/kde-silvan//segment_b53e3968 - 
m_mmappedRegion = 0xb5d9b000 - m_mmappedEventBuffer = 0xb5d9b004 - new size = 
2724 - old size = 2724
rosegarden (sequence manager): SequenceManager::segmentModified() : size 
changed = false

Interesting.  I'm sure you have no idea what this means, and neither do I.  
I've never worked on the sequencer or the sequence manager at all, and don't 
really know how any of it works.  This looks like something we should give 
thought to optimizing, if possible, but Chris will have to opine further on 
this matter.
-- 
D. Michael McIntyre