Re: [Rosegarden-devel] Crash using velocity property (and volume)event rulers

[Henrik Andersson <dbug@sp...>]

1) 
I agree, its easier to catch which velocity reflecting which note.

2)
Can you describe those drawingartifacts ? I just added a small patch for
correcting the Z value so that those lines wont be drawn above a bar
which
occured when you rasied a velocity bar value above ~110

3)
I think i know what this crash is all about, the EventSelection is not
threadsafe
and a redraw of event is done (call to EventSelection.contains()) while
an addEvent() to the eventselection is done this occurs.
I have some ideas to get around this problem and will soon provide a
fix.

/Henrik




<-----Ursprungligt Meddelande----->

 	 	From: D. Michael McIntyre
[rosegarden.trumpeter@...]
Sent: 12/11/2008 5:58:42 AM
To: rosegarden-devel@...
Subject: Re: [Rosegarden-devel] Crash using velocity property (and
volume)event rulers 

On Tuesday 11 November 2008, Shelagh Manton wrote: 

> 4. When however I Shift -> key and <- key to select particular parts
of 
> the song then I can get it to crash. 

I think I got the crash with left arrow. Here's a trace that runs all
the way 
to #0. 

Looks like it's either a quickie oh duh fix or something really ugly to
figure 
out. 

My initial reaction to the ruler change (first time I've looked at it) 

1) Having the notation selection reflected on the ruler has a lot of
potential 

2) There are tons of drawing artifacts that look terrible, and this is
nowhere 
near production quality (though we can worry about production quality
for 
this on the other side of porting it over to the Qt4 branch) 

3) This whole thing with keyboard arrow keys doing one thing and the
mouse 
doing something different is rather confusing and unsettling. I use
shift + 
up/down keys to move the blue-selected ruler bars, and I use shift +
mouse to 
move the red-selected ruler bars, and ruler bars can be both red- and 
blue-selected at the same time. Are we sure we want to start writing 
documentation for this yet? Do we really need two parallel selection 
mechanisms with conflicting but similar controls? (Yes is a viable
answer, 
but let's talk about why.) 

Stack trace: 
#0 0x0895f673 in std::_Rb_tree<Rosegarden::Event*, Rosegarden::Event*, 
std::_Identity<Rosegarden::Event*>, Rosegarden::Event::EventCmp, 
std::allocator<Rosegarden::Event*> >::upper_bound (this=0xb408d8f0, 
__k=@0xbf9a1534) at /usr/include/c++/4.2/bits/stl_tree.h:1484 
#1 0x0895f6f7 in std::_Rb_tree<Rosegarden::Event*, Rosegarden::Event*, 
std::_Identity<Rosegarden::Event*>, Rosegarden::Event::EventCmp, 
std::allocator<Rosegarden::Event*> >::equal_range (this=0xb408d8f0, 
__k=@0xbf9a1534) at /usr/include/c++/4.2/bits/stl_tree.h:1511 
#2 0x0895f756 in std::multiset<Rosegarden::Event*, 
Rosegarden::Event::EventCmp, std::allocator<Rosegarden::Event*> 
>::equal_range ( 
this=0xb408d8f0, __x=@0xbf9a1534) 
at /usr/include/c++/4.2/bits/stl_multiset.h:481 
#3 0x0895d3a2 in Rosegarden::EventSelection::contains (this=0xb408d8e8, 
e=0xb49f2260) at /home/silvan/SVN/rosegarden/src/base/Selection.cpp:134 
#4 0x0860f0e9 in Rosegarden::ControlRuler::isEventSelected
(this=0xb433ec10, 
e=0xb49f2260) 
at /home/silvan/SVN/rosegarden/src/gui/rulers/ControlRuler.cpp:165 
#5 0x0882ac20 in Rosegarden::ControlItem::draw (this=0xb4310178, 
painter=@0xbf9a1770) 
at /home/silvan/SVN/rosegarden/src/gui/rulers/ControlItem.cpp:96 
#6 0xb7ce10e5 in QCanvasItemList::drawUnique () from
/usr/lib/libqt-mt.so.3 
#7 0xb7ce755c in QCanvas::drawCanvasArea () from /usr/lib/libqt-mt.so.3 
#8 0xb7ce86bc in QCanvas::drawChanges () from /usr/lib/libqt-mt.so.3 
#9 0xb7ce9569 in QCanvas::update () from /usr/lib/libqt-mt.so.3 
#10 0x0860f239 in Rosegarden::ControlRuler::slotUpdate (this=0xb433ec10)
at /home/silvan/SVN/rosegarden/src/gui/rulers/ControlRuler.cpp:109 
#11 0x085bdce6 in Rosegarden::EditView::updateControlRulers
(this=0xb4bedd38, 
updateHPos=false) 
at /home/silvan/SVN/rosegarden/src/gui/general/EditView.cpp:210 
#12 0x085c7346 in Rosegarden::EditView::paintEvent (this=0xb4bedd38, 
e=0xbf9a20d0) at
/home/silvan/SVN/rosegarden/src/gui/general/EditView.cpp:190 
#13 0x084ea77e in Rosegarden::NotationView::paintEvent (this=0xb4bedd38,
e=0xbf9a20d0) 

at
/home/silvan/SVN/rosegarden/src/gui/editors/notation/NotationView.cpp:29
90 
#14 0xb7ae722b in QWidget::event () from /usr/lib/libqt-mt.so.3 
#15 0xb7bbc2da in QMainWindow::event () from /usr/lib/libqt-mt.so.3 
#16 0xb7a44c36 in QApplication::internalNotify () from
/usr/lib/libqt-mt.so.3 
#17 0xb7a47564 in QApplication::notify () from /usr/lib/libqt-mt.so.3 
#18 0xb75c49b2 in KApplication::notify () from /usr/lib/libkdecore.so.4 
#19 0xb79d528d in QApplication::sendEvent () from /usr/lib/libqt-mt.so.3
#20 0xb7a101e3 in QWidget::repaint () from /usr/lib/libqt-mt.so.3 
#21 0xb7a45c56 in QApplication::sendPostedEvents () 
from /usr/lib/libqt-mt.so.3 
#22 0xb7a45d76 in QApplication::sendPostedEvents () 
from /usr/lib/libqt-mt.so.3 
#23 0xb79e98a3 in QEventLoop::processEvents () from
/usr/lib/libqt-mt.so.3 
#24 0xb7a5ff90 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 
#25 0xb7a5fc8e in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 
#26 0xb7a467df in QApplication::exec () from /usr/lib/libqt-mt.so.3 
#27 0x083be211 in main (argc=-1080416328, argv=0xbf9a27e4) 
at /home/silvan/SVN/rosegarden/src/gui/application/main.cpp:733 

-- 
D. Michael McIntyre 

------------------------------------------------------------------------
- 
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge 
Build the coolest Linux based applications with Moblin SDK & win great
prizes 
Grand prize is a trip for two to an Open Source event anywhere in the
world 
http://moblin-contest.org/redirect.php?banner_id=100&url=/ 
_______________________________________________ 
Rosegarden-devel mailing list 
Rosegarden-devel@... - use the link below to
unsubscribe 
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel 
. 
	

Re: [Rosegarden-devel] Crash using velocity property (and volume)event rulers

[D. Michael McIntyre <rosegarden.trumpeter@gm...>]

On Wednesday 12 November 2008, Henrik Andersson wrote:

> 1)
> I agree, its easier to catch which velocity reflecting which note.

There is some inconsistency with respect to selections too, if this is all 
going to work smoothly.  Like if I have a selection and then I open a ruler, 
the existing selection isn't reflected on the ruler.  I probably noticed one 
or two other similar circumstances yesterday, but unfortunately forgot to 
write them down.

Just fine tuning stuff though that's hopefully a simple matter to tweak.

> 2)
> Can you describe those drawingartifacts ? I just added a small patch for
> correcting the Z value so that those lines wont be drawn above a bar
> which
> occured when you rasied a velocity bar value above ~110

That sounds like the source of the artifacts I'm seeing.

> and a redraw of event is done (call to EventSelection.contains()) while
> an addEvent() to the eventselection is done this occurs.
> I have some ideas to get around this problem and will soon provide a
> fix.

OK, great!  All of this looks to be a huge improvement in usability.

I wonder if we want to keep the color representing value idea intact somehow.  
I think the reason Guillaume went with the almost invisible thin red outlines 
for the rulers' native selection display was probably to preserve the color 
of the bars themselves.  I like "blue means selected" just fine, but I have 
the idea maybe we could vary the blue with the height of the bar in some 
mathematically convenient way.  I wonder if it's worth playing with that 
idea.  On the one hand, I do feel like something subtle is missing from this, 
but on the other, it could be a lot of tinkering just to wind up with 
something that looks ridiculous, to serve no really worthwhile purpose.

Hrm.

I'll just throw the thought out then.  That was by no means an official 
mandate.
-- 
D. Michael McIntyre

Re: [Rosegarden-devel] Crash using velocity property (and volume)event rulers

[Shelagh Manton <shelagh.manton@gm...>]

On Wed, 12 Nov 2008 11:36:52 -0400
"D. Michael McIntyre" <rosegarden.trumpeter@...> wrote:

> On Wednesday 12 November 2008, Henrik Andersson wrote:
> 
> > 1)
> > I agree, its easier to catch which velocity reflecting which note.
> 
> There is some inconsistency with respect to selections too, if this
> is all going to work smoothly.  Like if I have a selection and then I
> open a ruler, the existing selection isn't reflected on the ruler.  I
> probably noticed one or two other similar circumstances yesterday,
> but unfortunately forgot to write them down.
> 
> Just fine tuning stuff though that's hopefully a simple matter to
> tweak.
> 
> > 2)
> > Can you describe those drawingartifacts ? I just added a small
> > patch for correcting the Z value so that those lines wont be drawn
> > above a bar which
> > occured when you rasied a velocity bar value above ~110
> 
> That sounds like the source of the artifacts I'm seeing.
> 
> > and a redraw of event is done (call to EventSelection.contains())
> > while an addEvent() to the eventselection is done this occurs.
> > I have some ideas to get around this problem and will soon provide a
> > fix.
> 
> OK, great!  All of this looks to be a huge improvement in usability.
> 
> I wonder if we want to keep the color representing value idea intact
> somehow. I think the reason Guillaume went with the almost invisible
> thin red outlines for the rulers' native selection display was
> probably to preserve the color of the bars themselves.  I like "blue
> means selected" just fine, but I have the idea maybe we could vary
> the blue with the height of the bar in some mathematically convenient
> way.  I wonder if it's worth playing with that idea.  On the one
> hand, I do feel like something subtle is missing from this, but on
> the other, it could be a lot of tinkering just to wind up with
> something that looks ridiculous, to serve no really worthwhile
> purpose.
> 
Hmm... It just goes to show how unsophisticated my use of rosegarden
has been. I thought the blue selection method was the standard one
because it uses the colour of the note selection in the notation and
matrix that I'm sure has been there all along and that the red line
selection method was the new. Oh well! I know better now.

SOM
> Hrm.
> 
> I'll just throw the thought out then.  That was by no means an
> official mandate.


-- 

----------------------------------------------------------------
Jabber: shelagh.manton@...
----------------------------------------------------------------