On Sunday 11 Dec 2005 21:50, Pedro Lopez-Cabanillas wrote:
> HEAD - No Jack
> 1: 8.17
> [...]
> HEAD - With Jack
> 1: 21.22
Wow. These figures are something of an eye-opener.
> experiments - With Jack
> 1: 7.14
I wonder what on earth could have made that 21 -> 7 second difference?
That _reall
On Friday 09 Dec 2005 13:56, Chris Cannam wrote:
> Meanwhile, I've just noticed that the sequencer process appears to be
> leaking about 16MB every time I press Record (MIDI track armed) on a
> file with a few audio segments in it. Uh-oh...
That one&#x
On Friday 09 Dec 2005 10:36, Chris Cannam wrote:
> As for option (b), it would get us an 8-bit QImage which means we
> could have enough colours and still only use a quarter of the current
> memory load, but I have absolutely no idea whether Qt will do the
> right thing when drawing
On Monday 12 Dec 2005 15:05, Guillaume Laurent wrote:
> The reason the recording audio segment doesn't show is that we
> no longer systematically invalidate the segment draw buffer when the
> pointer is moved, as it used to be. It's now invalidated only when a
> MIDI recording segment receives an
On Monday 12 Dec 2005 16:43, Chris Cannam wrote:
> The thread actually _does_ throw away duplicate requests that have the same
> notify callback (i.e. that originate from the same object) -- see
> audiopreviewthread.cpp:156
Actually, I don't think it should even be doing that.
On Monday 12 Dec 2005 17:18, Guillaume Laurent wrote:
> I tried adding a
> 'if (recording) segmentDrawBufferNeedsRefresh()' in
> CompositionView::setPointer(), and that will put us back in CPU-hogging
> mode just the same.
Point is, it shouldn't make any difference logically whether we're recordin
On Monday 12 Dec 2005 17:23, Chris Cannam wrote:
> Point is, it shouldn't make any difference logically whether we're
> recording or not. Only one segment has changed -- in this case the
> recording segment's end marker time has changed (or whatever equivalent
>
On Tuesday 13 Dec 2005 13:48, Guillaume Laurent wrote:
> Chris Cannam wrote:
> > To put this another way: when the duration or contents of a single
> > segment changes in normal editing use, does the canvas refresh
> > everything, or only that segment?
>
> Only that s
On Tuesday 13 Dec 2005 23:53, Pedro Lopez-Cabanillas wrote:
> On Sunday 11 December 2005 23:26, Chris Cannam wrote:
> > I wonder what on earth could have made that 21 -> 7 second
> > difference? That _really_ wasn't in the script.
>
> [Y]ou mean this changeset, right
On Tuesday 13 Dec 2005 23:40, Guillaume Laurent wrote:
> No, it's something else. As I said I added a trace in
> viewportPaintEvent() on the redrawn rect that is computed by
> checkScrollAndRefreshDrawBuffer(), and it showed that the whole
> screen was redrawn with every pointer move [...] But look
On Wednesday 14 Dec 2005 21:35, Chris Cannam wrote:
> What I think is happening is simply that the paint event for the
> segment (which is wide and short) is being coalesced with the paint
> event for the pointer move (which is tall and thin) and the resulting
> rectangle union covers
On Wednesday 14 Dec 2005 22:43, Chris Cannam wrote:
> The reason for this is actually pretty simple. A segment has
> changed, so we've set m_segmentsDrawBufferNeedsRefresh. And because
> that flag is set, checkScrollAndRefreshDrawBuffer decides it needs to
> refresh the whole bu
On Thursday 15 Dec 2005 16:09, Mikael Larsson wrote:
> Here's a patch that adds two buttons to the transport control.
> The point of this is for easier control of the looping function.
> Both loop start and loop stop points can with this patch be set or
> changed during playback with only a mouse c
Stephen Torri:
> I am a bit fuzzy on who had a laundry list of things
> to be done to the guitar chord editor.
I had some of these as well, but I never got around to writing them down
either... sorry (sigh). I'm not at a proper computer at the moment and I'm
awful busy for the next week at le
Haven't tested this yet, but why did you add the artifacts stuff to that
checkScrollAndRefresh method (whatever it's called)?
-Original Message-
From: Guillaume Laurent <[EMAIL PROTECTED]>
Date: Sun, 18 Dec 2005 01:18:31
To:rosegarden-devel@lists.sourceforge.net
Subject: Re: [Rosegarden
On Monday 19 Dec 2005 14:54, Guillaume Laurent wrote:
> On Monday 19 December 2005 13:33, Guillaume Laurent wrote:
> > I committed some intermediate stuff at the request of Chris in case
> > he could take on from there, so seg canvas has serious update
> > problems at the moment. Don't worry about
On Monday 19 Dec 2005 22:08, Guillaume Laurent wrote:
> On Monday 19 December 2005 21:25, Chris Cannam wrote:
> > More to the point though I'm not very happy with the rather random
> > approach here.
>
> It's not random, but I don't want to go disrupting ever
On Monday 19 Dec 2005 23:12, Guillaume Laurent wrote:
> The only reason I started messing with it is that dissociating the
> updates on the seg buffer with the global ones yielded update
> problems with the artifacts buffer.
I realise that -- I just think that was a red herring.
> OK, I'll merge
On Monday 19 Dec 2005 23:34, Guillaume Laurent wrote:
> On Tuesday 20 December 2005 00:32, Chris Cannam wrote:
> > I'm going to commit one more thing (if I can get the damn thing
> > working) on this branch this evening and then go to bed.
>
> Ah f*ck, I've already
On Monday 19 Dec 2005 20:25, Chris Cannam wrote:
> Next things:
>
> -- The MIDI record segment doesn't appear until the first event
> arrives (but updates smoothly after that). Fix.
Not fixed. Attached is a patch I previously mentioned, that does some
of this (i.e. it does
On Tuesday 20 Dec 2005 09:41, Guillaume Laurent wrote:
> Actually I wonder if this isn't what we were looking for in the first
> place, rather than maintaining our own seg buffer update rect :-).
No, they're two separate problems. You're mixing up modified and exposed
areas again.
It's easy to
On Tuesday 20 Dec 2005 10:48, Guillaume Laurent wrote:
> I think you have the guarantee that when you update(rect), the rect will be
> among the ones in the QRegion of the next paint event, so it should work
> correctly.
I think scrolling may sometimes bugger that one up, for the viewport. I thin
On Tuesday 20 Dec 2005 00:28, Guillaume Laurent wrote:
> On Tuesday 20 December 2005 00:32, Chris Cannam wrote:
> > > QPaintEvent also carries a QRegion, which is an array of QRects.
> > > That's probably what we're looking for.
> >
> > That does sound p
DMM:
> rg-20051223-220211-7.wav: ERROR: unsupported compression type 3
The error messages are unhelpful, but this appears
to be flac failing to understand the 32-bit audio files
we now write as default. A simple workaround is to
switch back to writing 16-bit audio (in the sequencer
settings o
> It looks like it only supports compression code 1.
> Whatever the hell that means.
I'm not sure why "compression code" - I think this is
just the WAV format subtype where 1 is 16-bit PCM
and 3 is IEEE floating point. But that's from my
usually unreliable memory.
> Is there some way to wr
G:
> Any chance to restore the loading of fonts as it
> previously was ? If I recall correctly this was part > of a change meant to
> speed up RG startup but it
> doesn't, really :-).
It hugely speeds the startup of the notation editor
the first time you open it.
> And when you're trying to
G:
> I'm not sure it's worth the tradeoff actually.
Well, it just seems rather absurd that if you run the
program for five minutes and then open the notation
editor, the notation editor takes twenty seconds to
show up because it's looking up some things we could
easily have found out in any id
G:
> I don't like this very much either...
Nor do I, really.
> I guess there's no way to speed up the
> loading of the fonts ?
Feel free to suggest one.
> Or could it be done in a seperate thread ?
I seem to remember it needs to use the Qt event loop.
Chris
---
G:
> Thinking more about this I think that loading the fonts when the notation
> editor is invoked is still better, given that even as it is now it blocks the
> UI.
Well, I don't find that it does particularly. Even if it
did, at least you get to look at something meaningful
meanwhile (instea
On Wednesday 28 Dec 2005 06:24, D. Michael 'Silvan' McIntyre wrote:
> On Tuesday 27 December 2005 06:11 am, Chris Cannam wrote:
> > Well, I don't find that it does particularly.
>
> It does particularly.
OK -- as far as I can be bothered with at the moment, you and
On Tuesday 27 Dec 2005 11:11, Chris Cannam wrote:
> > On a different matter, any concerns about my fix
> > for selection rect trails ?
>
> I haven't had a chance to try it yet. I'm likely to
> have relatively little time at a real computer with an
> intern
> 3. Canvas behaves bad when working with really big
> compositions. I mean REALLY big. The Rite Of Spring > by Igor Stravinsky is
> good example.
>From a MIDI file? If so can you send the file
(compressed if you like) off-list to me and Guillaume
please? Concrete examples are always helpful
On Thursday 29 Dec 2005 13:04, Vladimir Savic wrote:
> And one more questions. Forgive me, I was off list for a long time.
> :) What happened to that nice new way of showing tempo changes?
I backed it out for the moment. It will be back in an editable form
(click and drag to change tempo, etc),
If we were to permit the user to select multiple MIDI tracks and record
on all of them at once, how should they select which track records
which MIDI data?
Some options:
-- The existing "channel" property of the instrument (used for playback
channel now) is also used to select events to reco
On Wednesday 28 Dec 2005 06:35, D. Michael 'Silvan' McIntyre wrote:
> [If] the KDE "General" font is set at a size
> larger than 12 (mine is Arial 13), then the number gets cut off.
> This is also happening to the track numbers and other text in the
> main window.
I've just tried wicking up the
> I feel almost goofy bringing this up again, but
> looking at my bugs list I don't have any showstoppers left.
As Michael says, that doesn't mean there aren't any
showstoppers. The crash when recording audio with
a MIDI segment armed is definitely one. Practically
guaranteed to bite anyone
On Monday 09 Jan 2006 08:16, Chris Cannam wrote:
> > I feel almost goofy bringing this up again, but
> > looking at my bugs list I don't have any showstoppers left.
>
> As Michael says, that doesn't mean there aren't any
> showstoppers. The crash when recordi
Silvan:
> On Monday 09 January 2006 11:20 am, Brett McCoy wrote:
> > A couple weeks ago on the rosegarden-user list we were talking about the
> > insertion/deletion of measures into a score [...]
>
> [...] The problem is figuring out how everything fits together
> to a sufficient extent that you
On Wednesday 11 Jan 2006 21:10, Brett McCoy wrote:
> What's the procedure for submitting code? Does it get submitted as a
> patch?
Yes please, send a patch to this list.
Chris
---
This SF.net email is sponsored by: Splunk Inc. Do you grep thr
On Monday 09 Jan 2006 13:35, Guillaume Laurent wrote:
> Chris Cannam wrote:
> > btw, what's the procedure for updating the .po files these days?
>
> Run po/messages.sh.
OK, note that you have to be _in_ the po directory, you can't actually
run po/messages.sh from the
On Wednesday 11 Jan 2006 22:02, Guillaume Laurent wrote:
> On Wednesday 11 January 2006 22:55, Chris Cannam wrote:
> > /usr/include/kde.pot does not exist, there is something wrong
> > with your installation!
> >
> > Need I worry?
>
> Could be. It should
The next release of Rosegarden will appear during the next few weeks.
The translation strings have changed significantly since the 1.0
release. If your language translation has not been updated, we would
appreciate it if you could submit an update during the next week.
The following translati
On Wednesday 11 Jan 2006 22:17, Guillaume Laurent wrote:
> On Wednesday 11 January 2006 23:17, Chris Cannam wrote:
> > What's it for?
>
> It holds the messages for all the standard KDE actions and strings,
> so it's pretty much necessary.
Maybe you'd better
On Thursday 12 Jan 2006 12:52, Alexandre Prokoudine wrote:
> I have updated ru.po ~1month ago, but some messages are still not
> ngettextized.
Can you remind me which?
Chris
---
This SF.net email is sponsored by: Splunk Inc. Do you grep throu
> In particular, she didn't like seing notes on icons for
> accidentals.
Can you explain why? The notes are there for a
reason - because the functions modify note insertion,
rather than inserting accidentals on their own.
Chris
---
This S
On Friday 13 Jan 2006 02:37, Alexandre Prokoudine wrote:
> On 1/12/06, Chris Cannam <[EMAIL PROTECTED]> wrote:
> > On Thursday 12 Jan 2006 12:52, Alexandre Prokoudine wrote:
> > > I have updated ru.po ~1month ago, but some messages are still not
> > > ngettextized
On Friday 13 Jan 2006 10:58, Alexandre Prokoudine wrote:
> On 1/13/06, Chris Cannam wrote:
> > You know, I don't think this KDE 3-argument i18n() call is working.
>
> If only you knew how much I dislike "special" solutions like that :-/
Too right.
> Watch me as
On Friday 13 Jan 2006 16:22, Stefan Asserhall wrote:
> The reason the plural forms are not extracted correctly is that you
> need the specific gettext patched for kde to do that. You can find
> the patch in "kdesdk/scripts/gettext.patch". The patch is valid for
> gettext-0.10.35.
Wow. So the API
On Friday 13 Jan 2006 19:57, Chris Cannam wrote:
> What output would be expected to be produced by this hack? For
> example, in the case
>
> i18n("1 pixel", "%n pixels", sizes[i])
>
> where we currently just get
>
> #: ../gui/notationview.cpp:2121
>
On Friday 13 Jan 2006 02:37, Alexandre Prokoudine wrote:
> Btw, what does "Segment Debug Dump" mean
It's an option that doesn't actually appear in the GUI -- once upon a
time it was used for printing out debug information -- no longer.
Don't worry about it.
> and why is "HSpinBox class"
> (#:
On Sunday 15 Jan 2006 17:00, Eckhard Jokisch wrote:
> Is "time" sometimes equivalent to measure? Or is it always just time
> like hh:mm:ss?
Usually we use "time" on its own to describe a moment in time (hh:mm:ss
or musical time), and "duration" if it's a duration. Measure is either
"measure" or
On Monday 16 Jan 2006 07:20, Guillaume Laurent wrote:
> On Saturday 14 January 2006 23:12, D. Michael 'Silvan' McIntyre wrote:
> > It looks like you haven't updated your tree in a long time, or else maybe
> > anon CVS is lagging way behind again.
>
> I doubt it has any relation, but Eckhard's machi
On Monday 16 Jan 2006 11:31, Guillaume Laurent wrote:
> Do not try to patch 1.0
> though, use anon-cvs to get a tree which is up to date.
This dialog doesn't appear in current CVS, and it won't appear in the release
that we're currently trying to get out of the door.
Chris
---
.. To answer the other part of the question: search for FailureXRuns in
gui/sequencemanager.cpp.
Chris
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine
On Saturday 14 Jan 2006 04:49, Ross Vandegrift wrote:
> Ok, the patch is included below. I need this patch to compile with Qt
> 3.3.3 and g++ 3.3.4.
>
> I think there's a possibility I'm missing something obvious, and this
> patch is likely not the correct solution. But it shows what's up.
Thank
On Monday 16 Jan 2006 17:14, Ross Vandegrift wrote:
> I just checked out your changes and I'm still seeing this:
> [...]
> RGbuild/gui/audiomanagerdialog.cpp:1011: error: no match for 'operator[]'
> in ' nameMap[Rosegarden::SoundFile::getFilename() const()]'
What is line 1011 of audiomanagerdialog
I hereby declare CVS HEAD officially soft-frozen (like a delicious Mövenpick
ice cream) in preparation for the forthcoming release, which unless anyone
strenuously objects, I propose we number "1.2.3".
Nothing further is to be committed to HEAD before the release except for:
-- Translation up
On Thursday 19 Jan 2006 11:32, Eckhard Jokisch wrote:
> Why was the flag OFFER_JACK_START... introduced?
Oops -- that's a mistake. I mean, the compile flag should be there -- that
part isn't a mistake -- but it should be defined by default.
I introduced this flag for the Studio to Go! build, fo
On Friday 20 Jan 2006 07:38, D. Michael 'Silvan' McIntyre wrote:
> On Friday 20 January 2006 02:21 am, Guillaume Laurent wrote:
> > cvs update.
> >
> > Please take a look at http://ximbiot.com/cvs/manual/
>
> Or hell, just use Cervisia for crying out loud. Remembering CVS
> commands sucks.
Or, as
On Tuesday 17 Jan 2006 14:36, D. Michael 'Silvan' McIntyre wrote:
> On Tuesday 17 January 2006 08:04 am, Chris Cannam wrote:
> > I suggest that we make the first release candidate at the end of
> > this week, and aim to have relatively few before the 1.2.3 release.
>
On Friday 20 Jan 2006 06:07, Marcos Guglielmetti wrote:
> Hi,
Can I ask you to actually subscribe to this list, please? At the moment
one of the list admins has to approve every message you post.
I don't speak Spanish, but I might be able to clarify a couple of the
strings you quoted anyway.
On Tuesday 17 Jan 2006 16:58, D. Michael 'Silvan' McIntyre wrote:
> The reason is because users have too damn many choices, and it's
> impossible to write something that covers every eventuality while it
> maintains a tight "code path" for the readers to follow through
> working out the particulars
On Friday 20 Jan 2006 03:59, Marcos Guglielmetti wrote:
> At least, it would be nice that Rosegarden says something like "There
> are no output MIDI Devices configured at all, so you will not hear
> MIDI events until you ... bla bla bla
OK, this is a good example of the potential problems of the a
On Saturday 21 Jan 2006 04:43, Meka[ni] wrote:
> Having ability to download VST SDK from the steinberg's site, are we
> going to get support for VST in rosegarden, or we should (always?)
> use dssi-vst? Thanx!
The Steinberg VST SDK is still licensed incompatibly with the GPL, and
it looks like it
The next release of Rosegarden will appear during the next few weeks,
and preliminary release candidate packages are expected within a couple
of days.
The translation strings have changed significantly since the 1.0
release. If your language translation has not been updated, we would
apprecia
On Friday 20 Jan 2006 22:13, D. Michael 'Silvan' McIntyre wrote:
> You're all missing the point to some extent. I realize we can't
> *fix* everything automatically.
I suppose what makes me glum is the thought that there is no fix for
some of these problems (other than switching to a whole differ
On Friday 20 Jan 2006 22:33, Marcos Guglielmetti wrote:
> On Friday 20 January 2006 14:57, Chris Cannam wrote:
> > (We _could_ change the default connection
> > semantics so as to prefer software synths, of course -- but then the
> > problem is there's no reliable way
I've just discovered that as of ALSA 1.0.11rc1, the ALSA sequencer client
numbers have been reorganised, with system clients using numbers 0-15 instead
of the previous 0-63, hardware clients now using 16-127 instead of 64-127,
and software clients taking 128+ as before.
This is a real problem
On Monday 23 Jan 2006 12:19, Alexandre Prokoudine wrote:
> Because you started discussion of ALSA seqiencer, did anyone read
>
https://sourceforge.net/mailarchive/forum.php?thread_id=9460220&forum_id=271 ?
I read it, but I can't really say I thought about it.
/dev/sequencer is an OSS device. I
There's a "Report Bug..." option in the help menu, presumably
originating in a KDE library somewhere. I don't think it's ever worked
in Rosegarden. Can we fix or remove it?
Chris
---
This SF.net email is sponsored by: Splunk Inc. Do you g
On Saturday 28 Jan 2006 21:36, Alexandre Prokoudine wrote:
> On 1/29/06, Chris Cannam wrote:
> > There's a "Report Bug..." option in the help menu, presumably
> > originating in a KDE library somewhere. I don't think it's ever
> > worked in Rosegarden
On Monday 30 Jan 2006 10:39, Eckhard Jokisch wrote:
> Hi,
> as I see from the sourcecode it is not possible at the moment to have RG
> act as MMC slave.
Where do you see that? MMC slave is implemented and is supposed to work.
Chris
---
This
On Monday 30 Jan 2006 11:25, Eckhard Jokisch wrote:
> > On Monday 30 Jan 2006 10:39, Eckhard Jokisch wrote:
> > > Hi,
> > > as I see from the sourcecode it is not possible at the moment to have
> > > RG act as MMC slave.
> >
> > Where do you see that? MMC slave is implemented and is supposed to wo
[cc'ing rg-devel -- feel free to follow up to only that list]
On Sunday 29 Jan 2006 22:44, Pedro Lopez-Cabanillas wrote:
> Recording sysex events from vkeybd have wrong behavior, it keeps the buffer
> from the former sysex message, and appends the new message bytes at the
> end. It inserts the me
On Monday 30 Jan 2006 12:00, Eckhard Jokisch wrote:
> Hmmm - maybe I don't see the point. I thought if I set RG to "slave" then
> it would wait for external MTC and start running as soon as MTC comes from
> external source. Is this assumption wrong?
No, that's what should happen.
If you set the M
Pedro:
> No. First, registerDataBlockForEvent() is protected, and second: it sets the
> data block itself. I've tried to workaround the issues to only get more
> problems.
Who wrote this code in the first place? Was it Guillaume, or Richard? I had
wondered whether it might be you, but it see
Me:
> Who wrote this code in the first place? Was it
> Guillaume, or Richard?
Nah, silly question. I'm not at a proper computer now
to check the code or the CVS record, but just
thinking about it, the structure is definitely Guillaume.
G? What did you intend to happen on record?
Chris
On Monday 30 Jan 2006 21:40, Pedro Lopez-Cabanillas wrote:
> On Monday 30 January 2006 21:56, Pedro Lopez-Cabanillas wrote:
> > I guess that there should be an explicit
> > call to registerDataBlockForEvent somewere before setDataBlockForEvent()
> > in AlsaDriver.cpp:2470, right?
>
> No. First, reg
Eckhard Jokisch:
> Can you give me any entry-point in the code where
> I can search for the reason?
First thing is MTC_DEBUG in sound/AlsaDriver.cpp. If
that is enabled and MTC slave mode is on, you should
see a constant stream of messages during playback if
you just start the transport from
On Tuesday 31 Jan 2006 21:22, Pedro Lopez-Cabanillas wrote:
> What about calling to DataBlockRepository::clear() at ~AlsaDriver()
> destructor?
Hm, I added a call to that from AlsaDriver::shutdown() (called from
dtor) but it looks like I forgot to commit it. I tested it and I'm
pretty sure it d
On Friday 03 Feb 2006 16:07, D. Michael 'Silvan' McIntyre wrote:
> I vote that if we don't get 1.2 released by February 14th (the same date
> last year we released 1.0) we should form a suicide pact.
Hmm.
Well, I think pretty much all of the high-priority bugs remaining are either
fixed or are o
Silvan:
> MIDI sync stuff is useful, but it's not something the
> majority of our userbase cares about, and it's
> probably reasonable to fix it later,
More to the point, as far as I can tell it works. I
need some more information if I'm going to fix
anything about this.
> As for DSSI, I h
On Friday 03 Feb 2006 20:41, Guillaume Laurent wrote:
> On Friday 03 February 2006 18:23, Chris Cannam wrote:
> > Well, I think pretty much all of the high-priority bugs remaining
> > are either fixed or are only at such high priorities to remind us
> > to look at them a
On Saturday 04 Feb 2006 15:00, Pedro Lopez-Cabanillas wrote:
> clear() is a static member of DataBlockRepository.
Oh yes, so it is.
Chris
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! D
On Saturday 04 Feb 2006 17:17, Guillaume Laurent wrote:
> I've committed an almost complete solution. As noted in the commit
> msg, there are still two problems, the previews don't reappear when a
> segment is grown back, and audio previews aren't clipped when an
> audio segment is shrunk.
OK, loo
On Sunday 05 Feb 2006 11:48, Guillaume Laurent wrote:
> Resize from left works correctly now.
Looks good, with one caveat -- during the drag, long notes disappear the
moment you overrun their left edge, whereas in the end result the notes
just get shortened unless you've dragged all the way past
On Sunday 05 Feb 2006 12:26, Chris Cannam wrote:
> On Sunday 05 Feb 2006 11:48, Guillaume Laurent wrote:
> > Haven't fixed the audio bit.
>
> I'll have a look if I find a moment (though don't let that stop you).
I couldn't see the cause.
If you take the right
On Sunday 05 Feb 2006 12:26, Chris Cannam wrote:
> On Sunday 05 Feb 2006 11:48, Guillaume Laurent wrote:
> > Resize from left works correctly now.
>
> Looks good, with one caveat
Ah, and one other far more serious caveat -- it doesn't work for audio
segments. Actually, re
On Sunday 05 Feb 2006 14:50, D. Michael 'Silvan' McIntyre wrote:
> One thing I notice that doesn't seem consistent is that resizing from
> the right always preserves the events in perpetuity, but resizing
> from the left, if I make a segment smaller from the left, the events
> clipped off seem to d
On Sunday 05 Feb 2006 16:33, Guillaume Laurent wrote:
> Anyway, the problem was that the "tile" rectangle on which we draw
> the previews wasn't clipped by the actual segment rect (only the
> drawn area clip). Fix in cvs.
Yep, looks good -- for shrinking audio segments from the right, anyway.
Th
The first release candidate of Rosegarden-4 1.2.3 is now available as a source
code tarball from:
http://www.rosegardenmusic.com/tmp/rosegarden-4-1.2.3rc1.tar.bz2
Please test and report your findings! We're particularly interested in
hearing about build issues that might suggest a packagi
On Monday 06 Feb 2006 14:26, Chris Cannam wrote:
> The first release candidate of Rosegarden-4 1.2.3 is now available [...]
By the way, I would like to officially retract this statement, which I made on
the 12th of October last year:
> I actually think we should be able to release a 1.
On Monday 06 Feb 2006 16:28, Eckhard Jokisch wrote:
> how can I stop RG to emit tons of this messages?
Well, first find RosegardenGUIApp::slotTestStartupTester ...
Comment out gui/rosegardengui.cpp:4082.
Chris
---
This SF.net email is sponso
On Monday 06 Feb 2006 16:32, Chris Cannam wrote:
> Comment out gui/rosegardengui.cpp:4082.
.. or turn off the "rosegarden" debug channel in kdebugdialog. That will
probably get rid of a lot of messages that you aren't interested in, and it
won't affec
Guillaume:
> Really, I understand you want to call it 1.2 rather
> than 1.1 (even though I don't think there are
> enough changes from the user's point of view to
> justify the jump in minor version number), but 1.2.3 ?
The original reason I wanted to call it 1.2.3 is just
that I've been stari
Silvan:
> Did you click OK from this dialog? It should export
> to a temporary file and run Lilypond against it
Good point though, maybe the dialog has the wrong
title? (i.e. Export Lilypond File, should be Preview
Lilypond File.) I'm not in a position to check at the
mo.
Chris
---
Silvan:
> Is anyone reading/digesting/saving my release
> notes posts?
Um...
> I don't see my own posts, so I'm not even sure
> they went up.
Um...
> Feel free to edit, season, and use it as
> appropriate.
Sorry, where is this supposed to be found?
Chris
On Wednesday 08 Feb 2006 10:20, Guillaume Laurent wrote:
> If we were to migrate to another hosting platform
As I've said before, I have absolutely no interest in moving to another
third-party hosting service. We stay with SourceForge, or we host our own.
> (and we'd switch to subversion along)
On Wednesday 08 Feb 2006 00:11, D. Michael 'Silvan' McIntyre wrote:
> Can't check if up to date because SF is not responding at the moment. I
> last updated right after Chris committed the new AUTHORS and other whatnot.
> I probably am right up to date if the bugs list isn't missing any
> messages
On Wednesday 08 Feb 2006 10:50, Guillaume Laurent wrote:
> Yes, I agree, but the key will be to know whether they'll do a clean
> migration, keeping all history, or a more brutal one. Given that keeping
> all history takes a *long* time
Does it? I've used Subversion, but only for new projects --
1 - 100 of 1555 matches
Mail list logo
