On Sunday 07 March 2004 22:55, Guillaume Laurent wrote:
> According to RosegardenSequencerApp::play(), all segments are remapped.
> However I realize this is of little use to the case at hand (getting ghost
> notes if editting when playback is stopped), since the segments mmapped
> files are kept
On Wednesday 03 March 2004 17:35, Richard Bown wrote:
> On Tuesday 02 March 2004 22:26, Guillaume Laurent wrote:
> > > Yeah, that is the case.
> >
> > Quite surprising given that we should be remapping everything right
> > before playing.
>
> Well there's something else to investigate then.
Accord
On Thursday 04 March 2004 12:59, Chris Cannam wrote:
> Remember that cvs commit tells you what branch you're committing to (in the
> comment at the bottom of the commit log edit page)
Hmm, no I'd never noticed that actually. Ta.
So has anyone had a look at this CVS replacement thing yet that all
On Thursday 04 Mar 2004 12:46 pm, Richard Bown wrote:
> On Thursday 04 March 2004 09:22, Chris Cannam wrote:
> > cvs update -rsome_tag_name
>
> Ok, so what if I've got two checked out copies. One is recently
> updated and unmodified, the other one I've already done some branch
> work on. If I tag
On Thursday 04 March 2004 09:22, Chris Cannam wrote:
> cvs update -rsome_tag_name
Ok, so what if I've got two checked out copies. One is recently updated and
unmodified, the other one I've already done some branch work on. If I
tag/branch the unmodified copy and then cvs update the modified br
On Wednesday 03 Mar 2004 5:33 pm, Chris Cannam wrote:
> On Wednesday 03 Mar 2004 4:35 pm, Richard Bown wrote:
> > On Tuesday 02 March 2004 22:26, Guillaume Laurent wrote:
> > > I don't remember us finding a reason why not doing it, and I
> > > think it would be a good solution for our problems.
> >
On Thursday 04 Mar 2004 7:09 am, Richard Bown wrote:
> how do you check into a branch?
There are two examples in the CVS manpage in the section on "commit".
Generally you do "cvs tag -b some_tag_name" followed by "cvs update
-rsome_tag_name" and then your following commits will go to that
bran
On Thursday 04 Mar 2004 6:59 am, Richard Bown wrote:
> Actually all the segments are weirdly truncated at high zooms.
Segments have always been truncated on occasion: if I import a MIDI
file with nearly 700 bars in it, then the segments all get chopped
off in bar 40 (at default zoom -- this dep
On Thursday 04 March 2004 06:59, Richard Bown wrote:
> Actually all the segments are weirdly truncated at high zooms. I'm not
> sure this can have anything to do with the preview stuff but I'm going to
> have a look at the QCanvas problem that's arisen now anyway and hence all
> of this stuff.
On Wednesday 03 March 2004 21:14, Guillaume Laurent wrote:
> On Wednesday 03 March 2004 20:23, Chris Cannam wrote:
> > The resize glitch thing looks OK to me now btw -- but I am seeing one
> > other weirdness (related or not). Try opening mandolin-sonatina.rg
> > and setting the zoom to 1000% or 2
On Wednesday 03 March 2004 21:10, Guillaume Laurent wrote:
> On Wednesday 03 March 2004 19:16, Richard Bown wrote:
> > Shouldn't we be scaling the QCanvasView using transformation matrices?
>
> Yes, that's probably our only option.
Eeek. This will be fun.
R
---
On Wednesday 03 March 2004 20:23, Chris Cannam wrote:
>
> The resize glitch thing looks OK to me now btw -- but I am seeing one
> other weirdness (related or not). Try opening mandolin-sonatina.rg
> and setting the zoom to 1000% or 2000%. When I do that, all the
> previews look right, and the fir
On Wednesday 03 March 2004 19:16, Richard Bown wrote:
>
> Shouldn't we be scaling the QCanvasView using transformation matrices?
Yes, that's probably our only option.
> Is this what we do on the matrix view (he asks lazily without looking) ?
Yes.
--
On Wednesday 03 March 2004 19:23, Chris Cannam wrote:
> It might be possible to improve on it by changing the canvas chunk
> size (see docs for QCanvas::retune()) but I'm not sure how far that
> would count as a fix.
Hm, I don't like this line for retune() "For example if you have a very large
c
On Wednesday 03 Mar 2004 6:16 pm, Richard Bown wrote:
> > zoom right in RG eats up all available memory
>
> Yeah, for example: Empty composition, set duration to 300 bars and
> zoom right in to max.
You're right, it's dreadfully slow isn't it? I had expected zooming a
blank canvas to take next t
> zoom right in RG eats up all available memory
Yeah, for example: Empty composition, set duration to 300 bars and zoom right
in to max. It takes its time resizing and eats up 163MB in the process.
Adding some debug it looks like the thing that's taking the time is the
QCanvas::resize() at g
On Wednesday 03 Mar 2004 4:35 pm, Richard Bown wrote:
> On Tuesday 02 March 2004 22:26, Guillaume Laurent wrote:
> > I don't remember us finding a reason why not doing it, and I
> > think it would be a good solution for our problems.
>
> Ok then, so who's going to do this? We're getting a bit vagu
On Tuesday 02 March 2004 22:26, Guillaume Laurent wrote:
> > Yeah, that is the case.
>
> Quite surprising given that we should be remapping everything right before
> playing.
Well there's something else to investigate then.
> > Hmm, I dunno enough about the update mechanism to be able to comment
On Tuesday 02 March 2004 14:09, Richard Bown wrote:
> On Tuesday 02 March 2004 10:55, Chris Cannam wrote:
> > So that
> > suggests that if you change the segment when playback is stopped, you
> > will get ghost notes: but as soon as you then make another change
> > during playback, it should resync
On Tuesday 02 March 2004 08:45, Richard Bown wrote:
>
> partial memset going on inside it removing only one or two notes. So
> either we make the memset at the end of dump() cleverer by sending along
> the maximum mmapped file size (the true size) or we reinstate the complete
> memset - which work
On Tuesday 02 March 2004 10:55, Chris Cannam wrote:
> So that
> suggests that if you change the segment when playback is stopped, you
> will get ghost notes: but as soon as you then make another change
> during playback, it should resynchronise itself. Is that the case?
Yeah, that is the case. I
On Tuesday 02 Mar 2004 9:17 am, Richard Bown wrote:
> Hmm, but additionally it would appear that
> SegmentMmapper::computeMmappedSize() is returning a size that has
> no real relation to the number of events stored in the Segment
> (m_segment->size()).
Not sure I get what you're saying here. comp
On Tuesday 02 Mar 2004 7:45 am, Richard Bown wrote:
> At this stage the size of the buffer has already changed to the new
> smaller version (when deleting a group of notes from a segment) so
> any zeroing of data in that buffer is going not going to extend to
> the end of it anymore.
The important
On Tuesday 02 March 2004 07:45, Richard Bown wrote:
> So
> either we make the memset at the end of dump() cleverer by sending along
> the maximum mmapped file size (the true size) or we reinstate the complete
> memset - which works in the non-playing case but according to the comment
> attached to
Ok, I think I'm getting somewhere with the ghost notes thing. The events are
definitely getting deleted from the Composition OK, it's just the mmapping
that is causing issues as first suspected. We're doing some horribly funky
stuff with mmapped segment resizing and I reckon the memset() at th
25 matches
Mail list logo
