On Friday 15 January 2010, Jim Cochrane wrote:
> I just found a similar bug to the one I just reported but this one is
> more severe.
>
> To trigger this one, all I have to do is to start rosegarden, open the
> MIDI mixer and adjust the volume of instrument 1, and start recording.
> RG crashes le
On Friday 15 January 2010, Jim Cochrane wrote:
> Make sure you have some data/notes to play - Hit "play". While
> rosegarden is playing the piece, click on MIDI mixer.
Confirmed.
> (I didn't try
> the MIDI manager or the audio mixer, but I suspect they would also have
> the same result.)
Incor
On Friday 15 January 2010, Jim Cochrane wrote:
> In the notation editor with two tracks (or segments or staffs -
> whatever they're called)
The little yellow bars you draw with the pencil to put notes in are called
segments. Segments sit on tracks. Tracks correspond with staffs in the
notatio
On Friday 15 January 2010, Jim Cochrane wrote:
> Open a non-empty track in the notation editor.
Non-empty segment from just one track. (Just one staff.) Check.
> (I suspect the behavior will be the same with > 1 track.)
At > 1 track/staff the view should open initially in a smaller font by
I tried this twice and RG crashed both times:
In the notation editor with two tracks (or segments or staffs -
whatever they're called) open, select 2 close-together notes in the
top staff. Right-click and choose "move to staff below" to move them
to the lower staff. Crash.
Before I tried this t
I just found a similar bug to the one I just reported but this one is
more severe.
To trigger this one, all I have to do is to start rosegarden, open the
MIDI mixer and adjust the volume of instrument 1, and start recording.
RG crashes less than a second after I hit the record button. I tried
thi
I'd say the severity of this one is medium, or a little greater.
How to reproduce:
Make sure you have some data/notes to play - Hit "play". While
rosegarden is playing the piece, click on MIDI mixer. (I didn't try
the MIDI manager or the audio mixer, but I suspect they would also have
the same
Just found this little bug:
Open a non-empty track in the notation editor. (I suspect the behavior
will be the same with > 1 track.) Click on Segment -> Add Layer.
(BTW, I'm not sure exactly what this is for, though it looks like it may
be a tool to help with working with multiple parts on the s
On Thursday 14 January 2010, Jim Cochrane wrote:
> I suppose one thing I can try is force rosegarden to not use calf, but
> I'd first have to figure out how to do that - maybe some
> option/disabled-option at build or pre-build time, or maybe just rpm -e
> calf-whatever-its-name is.
There's not (
On Thu, 14 Jan 2010 18:56:11 -0500
"D. Michael McIntyre" wrote:
> On Thursday 14 January 2010, Jim Cochrane wrote:
>
> > I suspect (looking at '/usr/lib/dssi' in the path above) that this
> > plugin factory is loading or using /usr/lib/dssi/calf.so. (It must
> > have been configured to load thi
On Thursday 14 January 2010, Jim Cochrane wrote:
> I suspect (looking at '/usr/lib/dssi' in the path above) that this
> plugin factory is loading or using /usr/lib/dssi/calf.so. (It must
> have been configured to load this at build time, I think.) I don't
> think it's actually being used, but is
On Thursday 14 January 2010, Shelagh Manton wrote:
> Cautionaries are the (#) or (b) in front of notes to show that they are
> sharped/flatted at this part of the music where you normally wouldn't
> bother putting them because they have already been shown in the key
> signature. Mostly used for in
On Fri, 15 Jan 2010 07:13:15 +0900
oota wrote:
> I'm translating .ts file to Japanese, but
> I found the word that did not understand the meaning.
>
>
> Require cautionaries in other octaves
>
>
> What meaning this word?
>
> oota
>
Cautionaries are the (#) or (b) in fro
I'm translating .ts file to Japanese, but
I found the word that did not understand the meaning.
Require cautionaries in other octaves
What meaning this word?
oota
--
Throughout its 18-year hist
On Thursday 14 January 2010 09.19.25 wrote Jim Cochrane:
> I assume you were implying you thought this might get rid of the core
> dump. I did not examine the terminal output for any differences except
> to note that the same "Segmentation fault (core dumped)" output
> occurred.
That's right. Si
On Thursday 14 January 2010, Chris Cannam wrote:
> Well, it's just very peculiar. I don't like not being able to understand
> it.
I don't like not being able to understand it either, but I can confirm that
doing a clean rebuild cures the crash. I re-applied the patch, did a make
clean, and a
On Thu, Jan 14, 2010 at 2:37 PM, Julie S wrote:
> I've attached a .diff file and a gdb backtrace along with a couple lines from
> RG right before the crash.
Mm, very strange.
Have you built from clean since making the change (in whatever working
copy that diff came from)? Shouldn't make any di
Hello Chris,
Concerning the crash:
> Can you get a stack trace?
I've attached a .diff file and a gdb backtrace along with a couple lines from
RG right before the crash.
I didn't like what I saw, but since it was deep inside a Qt Library, but since
RG is threaded that may not mean anything. I'
On Wed, Jan 13, 2010 at 6:32 PM, Julie S wrote:
> I've attached a .diff based off the revision 11636. Bsically it is just two
> lines of code.
>
> This makes RG crash. Change DeviceEventMap to DeviceEventMap * and all is
> well.
Hm, it doesn't crash for me -- I've tried it several times -- and
Michael, a late answer to your question on this core-dump-on-exit bug:
On Sat, 9 Jan 2010 23:29:00 -0500
"D. Michael McIntyre" wrote:
> On Saturday 09 January 2010, Jim Cochrane wrote:
>
> I'm going to have to blow the rest of this off for today and try to
> catch up with everything else tomorr
OK, a little late, but I've obtained the requested information re. this
core dump on exit. (See below.)
On Sun, 10 Jan 2010 20:05:05 +
Chris Cannam wrote:
> On Sun, Jan 10, 2010 at 4:29 AM, D. Michael McIntyre
> wrote:
> > My eye was first drawn to the free(). We don't use malloc/free
> >
Hi Stefan.
I tried your suggestion - defined the MALLOC_CHECK_ environment
variable as 0 and started rosegarden. It behaved the same way on exit
- core dump.
I assume you were implying you thought this might get rid of the core
dump. I did not examine the terminal output for any differences exc
I've compiled svn version 11634 and tried to duplicate the bug I
reported last week that I titled "core dump results from moving a
segment all the way to the left". The problem no longer occurs. I
tried the same steps twice (hit "record", wait a bit, play some notes,
stop, move the segment all th
23 matches
Mail list logo
