From: Chris C. <ca...@al...> - 2005-05-18 10:23:33
|
Sorry, accidentally sent a half-written mail there. On Wednesday 18 May 2005 11:11, Guillaume Laurent wrote: > On Wednesday 18 May 2005 10:59, Chris Cannam wrote: > > On Tuesday 17 May 2005 08:00, Guillaume Laurent wrote: > > > On Monday 16 May 2005 22:17, Chris Cannam wrote: > > > > I'm sorry, but that's just weird. [...] > > > > > > Does it ? I thought it looked ok... > > > > No, sorry, it's just weird. > > OK, feel free to revert it then, right now my version of > compositionview.cpp is in a non-compilable state due to me trying to > get the audio previews in (much harder than I thought). One thing to remember for audio previews -- that will either make things really difficult or possibly slightly easier, but will certainly make them really difficult if it isn't thought about in advance -- is that our main timeline is "musical time" whereas the audio previews are "real time". The ratio between audio preview pixels and on-screen pixels will vary depending on the current tempo, and this may change during an audio segment, so the segment previews will have to stretch and squash accordingly. The trivial way to do it would be just to convert the real time to timeT for each of the peak frames (using the Composition conversion methods) and then convert time to X for each using the ruler scale. Unfortunately the Composition part of this is way too slow to do for each peak, so we'd have to distribute peaks evenly between tempo change points instead. (FWIW we fudge this entirely in 1.0 -- the audio segments are wrong in any situation where they overlap a tempo change. 1.0 just distributes peaks evenly throughout the width of the audio segment. This is something we really need to get right in the rewrite though.) I can probably handle audio previews myself if you like, or at least give them some thought, but my time is pretty tight at the moment as well (I'm also working on a bunch of things at once) so I can't promise any particular timescale. > > Surely all it takes is to draw the box background first, then the > > previews with those pixels within the box appearing in a fainter > > colour, and then the box outline and the text. > > The way the drawing code is currently designed doesn't make it that > simple, and doing it that way would turn it into a big mess. So you _are_ a wuss! I knew it. > Translucency will have to be done at the X level. Oh nonsense. What a waste -- demanding translucency support at the toolkit or server level just for the sake of drawing one poxy little label. Honestly. > Yes. BTW, if you had a few brain cycles to spare on helping me solve > this : > > https://sourceforge.net/tracker/index.php?func=detail&aid=1184540&gro >up_id=4932&atid=104932 > https://sourceforge.net/mailarchive/message.php?msg_id=11661650 > > I'd be most grateful. I'll try to find a few. Bit in the middle of something right now though. Chris |
From: Guillaume L. <gla...@te...> - 2005-05-18 10:53:41
|
On Wednesday 18 May 2005 12:24, Chris Cannam wrote: > > One thing to remember for audio previews -- that will either make things > really difficult or possibly slightly easier, but will certainly make > them really difficult if it isn't thought about in advance -- is that > our main timeline is "musical time" whereas the audio previews are > "real time". The ratio between audio preview pixels and on-screen > pixels will vary depending on the current tempo, and this may change > during an audio segment, so the segment previews will have to stretch > and squash accordingly. Oh great. I'm already having problems simply integrating the current preview generation mechanism with AudioPreviewThread, and now this. *sigh*. For the record, the main problem is that the previews are generated by the model (following the idea that the model handles the raw data, and the view asks it for abstract drawing info). But the AudioPreviewThread needs to know the size of the rect in which the preview will be drawn, and that size is computed by the view at drawing time according to the current zoom level. The model can and does compute rectangles from segments, but it's up to the view to scale them. I guess that I'll have to break my nice abstraction and make the model aware of the zoom level. > > > Surely all it takes is to draw the box background first, then the > > > previews with those pixels within the box appearing in a fainter > > > colour, and then the box outline and the text. > > > > The way the drawing code is currently designed doesn't make it that > > simple, and doing it that way would turn it into a big mess. > > So you _are_ a wuss! I knew it. I'd like to keep my code in a maintainable state, if you don't mind :-). > > Translucency will have to be done at the X level. > > Oh nonsense. What a waste -- demanding translucency support at the > toolkit or server level just for the sake of drawing one poxy little > label. Honestly. Well, since it's there in all new distribs and Qt is about to support it, we might as well take advantage of it. In the meantime I'm not sure I want to indulge into what would be a gross hack. > I'll try to find a few. Bit in the middle of something right now > though. Thanks. -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2005-05-18 11:04:32
|
On Wednesday 18 May 2005 12:54, Guillaume Laurent wrote: > But the AudioPreviewThread needs to know > the size of the rect in which the preview will be drawn, and that size is > computed by the view at drawing time according to the current zoom level. > The model can and does compute rectangles from segments, but it's up to the > view to scale them. I guess that I'll have to break my nice abstraction and > make the model aware of the zoom level. Uh, scratch that, the zooming is handled by the grid, so the model knows about it :-). Well, it always pays to explain a problem to others. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2005-05-18 11:25:48
|
On Wednesday 18 May 2005 11:54, Guillaume Laurent wrote: > For the record, the main problem is that the previews are generated > by the model (following the idea that the model handles the raw data, > and the view asks it for abstract drawing info). But the > AudioPreviewThread needs to know the size of the rect in which the > preview will be drawn This means that (if using the current AudioPreviewThread API) we need to make a new request to the preview thread each time the tempo changes, in order to handle tempo scaling properly. i.e. if the tempo is 120 from the start of the segment up to a point 400 pixels into the segment width, and then changes to 140 until the end of the segment 200 pixels later, then we need to make two requests for previews, one for the RealTime section starting at the start of the segment and extending to the RealTime equivalent of that 400 pixel zone at 120bpm in the current zoom size (with width = 400), and another starting where the first leaves off and extending for the RealTime equivalent of 200 pixels at 140bpm in the current zoom size (with width = 200). > and that size is computed by the view at > drawing time according to the current zoom level. The model can and > does compute rectangles from segments, but it's up to the view to > scale them. Don't forget we need to recalculate audio previews when zooming -- they're calculated to a particular resolution. That's one reason we have the thread, otherwise zooming is slow because we have to wait for the previews. Chris |
From: Chris C. <ca...@al...> - 2005-05-18 11:32:48
|
On Wednesday 18 May 2005 11:54, Guillaume Laurent wrote: > On Wednesday 18 May 2005 12:24, Chris Cannam wrote: > > > Translucency will have to be done at the X level. > > > > Oh nonsense. What a waste -- demanding translucency support at the > > toolkit or server level just for the sake of drawing one poxy > > little label. Honestly. > > Well, since it's there in all new distribs and Qt is about to support > it, we might as well take advantage of it. We're looking for ways to make the previews work better _now_, not in a few years time. When exactly do you expect most of our users to be using Qt4 by? We haven't even begun to think about portability of our code to Qt4 yet! This is a question of usability we're talking about, not just an optional neat trick. Either it's worth doing now, or it's not. There's no point in saying "yes, it's worth doing, but let's leave it for a couple of years". If that's your view then you might as well say it's too hard and not worth the bother at all. And in that case, we're still looking for better ideas for what to do about the previews now. Chris |
From: Guillaume L. <gla...@te...> - 2005-05-18 14:47:41
|
On Wednesday 18 May 2005 13:34, Chris Cannam wrote: > > We're looking for ways to make the previews work better _now_, not in a > few years time. Sure, now more seriously, I'm not sure at all that translucency would be of any help here. Showing a short text over a background of scattered rectangles either makes it illegible, or the text is opaque enough to hide the preview, so IMHO it's either the labels or the previews, but trying to show both will suck. I'd settle for what we have now (a white box with the label inside), with a way to quickly toggle the labels. -- Guillaume. http://www.telegraph-road.org |
From: Alexandre P. <ale...@gm...> - 2005-05-18 15:10:40
|
On 5/18/05, Guillaume Laurent <gla...@te...> wrote: > I'd settle for what we have now (a white box with the label inside), with= a > way to quickly toggle the labels. It's seems to me that we are actually discussing levels of verbosity. Would it be a good idea to introduce 3 levels of assistance's verbosity? 1. No hints at all. 2. Basic hints. 3. Thorough explanation. This would fit the novice-profy scheme in a nice way. But it would also require providing long hints where RG doesn't have them and short ones, where RG has long ones. Alexandre |
From: Silvan <dmm...@us...> - 2005-05-18 18:14:11
|
> It's seems to me that we are actually discussing levels of verbosity. > Would it be a good idea to introduce 3 levels of assistance's > verbosity? Not really applicable in this instance. We're talking about segment labels. I think Guillaume has the right idea about a quick toggle. I disagree about translucency being completely useless though. I think it would look incredibly cool, and sometimes that in of itself is worth doing. (Probably not worth breaking your back over to implement it before it becomes easy though.) -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Guillaume L. <gla...@te...> - 2005-05-30 06:35:19
|
On Wednesday 18 May 2005 20:14, Silvan wrote: > > It's seems to me that we are actually discussing levels of verbosity. > > Would it be a good idea to introduce 3 levels of assistance's > > verbosity? > > Not really applicable in this instance. We're talking about segment > labels. I think Guillaume has the right idea about a quick toggle. It's in CVS. -- Guillaume. http://www.telegraph-road.org |
From: Mike O'C. <st...@vi...> - 2006-12-06 15:48:40
|
ros...@li... Cc:=20 Bcc:=20 Subject: Re: ubuntu release schedule Reply-To:=20 In-Reply-To: <33c...@ma...> > >Rosegarden 1.4.0 is in Debian-etch: > >$ apt-cache policy rosegarden4 >rosegarden4: > Installed: (none) > Candidate: 1:1.4.0-1 > Version table: > 1:1.4.0-1 0 > 990 ftp://ftp.fi.debian.org testing/main Packages > 500 ftp://ftp.fi.debian.org unstable/main Packages > 1.0-1 0 > 500 ftp://ftp.fi.debian.org stable/main Packages > 100 /var/lib/dpkg/status > >It is also in Ubuntu feisty/universe, see > > http://packages.ubuntu.com/feisty/sound/rosegarden > We are in a "soft-freeze" for etch, so this is the version that will almost definately ship. -stew (debian rosegarden maintainer) |
From: Heikki J. J. <hj...@gm...> - 2006-12-07 00:11:04
|
2006/12/6, Mike O'Connor <st...@vi...>: > > > >Rosegarden 1.4.0 is in Debian-etch: > > > >$ apt-cache policy rosegarden4 > >rosegarden4: > > Installed: (none) > > Candidate: 1:1.4.0-1 > > Version table: > > 1:1.4.0-1 0 > > 990 ftp://ftp.fi.debian.org testing/main Packages > > 500 ftp://ftp.fi.debian.org unstable/main Packages > > > > We are in a "soft-freeze" for etch, so this is the version that will > almost > definately ship. > > -stew (debian rosegarden maintainer) > It is nice to hear the voice of the debian rosegarden maintainer in this list :) I would leave the door open for a bugfix release (1.4.1) before the freeze. -- Heikki |
From: Chris C. <ca...@al...> - 2006-12-11 13:39:27
|
On Thursday 07 Dec 2006 00:04, Heikki Johannes Junes wrote: > I would leave the door open for a bugfix release (1.4.1) before the freeze. I'm not sure whether we have enough pure fixes to justify one, do we? On the other hand, I do think we have enough material for a new feature release soon. Call it 1.5.0? Aside from Ubuntu, I'm going to be using a newer-than-1.4.0 version in the next STG, so it might as well have a proper number. Chris |
From: D. M. M. <mic...@ro...> - 2006-12-12 05:14:26
|
On Monday 11 December 2006 8:39 am, Chris Cannam wrote: > On the other hand, I do think we have enough material for a new feature > release soon. Call it 1.5.0? There are some 1.4.0 bugs that really need to avoid going into 1.5.0 if we can help it. Most notably, none of the new track parameters work if saved as part of an autoload, and there's some niggling color index bit that needs rooting out and settling. I haven't even found time to sit down and properly test any of this, let alone try to do anything about it, but this stuff is in there and needs to be teased out. -- D. Michael McIntyre Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ See my new music stand unfolding at http://users.adelphia.net/~silvan/ |
From: Heikki J. J. <hj...@gm...> - 2006-12-11 14:34:32
|
2006/12/11, Chris Cannam <ca...@al...>: > > On Thursday 07 Dec 2006 00:04, Heikki Johannes Junes wrote: > > I would leave the door open for a bugfix release (1.4.1) before the > freeze. > > I'm not sure whether we have enough pure fixes to justify one, do we? We had some set of "just-after-release" fixes, or, "oops" fixes. I mean those fixes, not more. One of those one-liner "oops" included changing key in a staff: minor scales were missing, which I found very annoying. On the other hand, I do think we have enough material for a new feature > release soon. Call it 1.5.0? I agree. I would give it a name that differs from the naming of the development versions. Therefore, 1.6.0. -- Heikki |
From: Chris C. <ca...@al...> - 2006-12-12 16:59:45
|
On Monday 11 Dec 2006 14:34, Heikki Johannes Junes wrote: > 2006/12/11, Chris Cannam <ca...@al...>: > > On the other hand, I do think we have enough material for a new feature > > release soon. Call it 1.5.0? > > I agree. I would give it a name that differs from the naming of the > development versions. Therefore, 1.6.0. Er, actually I was thinking more along the lines of "have we done enough to call it 1.5.0, or should we call it 1.4.5 or something?" Of course the fact that it's labelled 1.5.0-svn internally suggests we probably ought to number it at least 1.5.0. But I do like to feel we can choose our version numbers based on meaningful things, like how much the program has changed, rather than just have them flow inevitably onwards or base them on some artifact of the development process. And let's face it, 1.5 is an attractive number. I like it better than 1.6. Anyone else have an opinion on this, er, hugely important subject? Chris |
From: D. M. M. <mic...@ro...> - 2006-12-12 22:10:17
|
On Tuesday 12 December 2006 12:00 pm, Chris Cannam wrote: > And let's face it, 1.5 is an attractive number. I like it better than 1.6. > > Anyone else have an opinion on this, er, hugely important subject? I think 1.6 is a more attractive number. They're really quite similar, but the 6 has smoother lines, and is less pointy. Kind of like a good woman, or maybe suggestive of the bubbles on top of a mug of good lager. I think my main vote here is that Heikki is right about our need to release early, release often, and not feel like we have to add some prescribed amount of fixes or new features in order to justify doing another release. Our last release wasn't beta tested worth a damn anyway, and neither was the one before that. There probably isn't much point trying to be professional about it, because we don't have the resources to get that kind of testing done. I don't think we have enough resources to maintain some kind of two tiered release schedule either, and should probably just aim to try to come up with some logical number to affix to today's SVN whenever it seems there's something important enough to bother releasing. In this case, our reorganized code tree and new build system, everything else aside. Though we should delay long enough to at least attempt to address the aforementioned problems that shipped with 1.4.0. I might get time to look into that tonight. -- D. Michael McIntyre Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ See my new music stand unfolding at http://users.adelphia.net/~silvan/ |
From: Julie S <msj...@ya...> - 2009-03-26 00:53:02
|
Hello, When running make I get: make: *** No rule to make target `src/sequencer/MmappedControlBlock.h', needed by `src/document/RosegardenDocument.o'. Stop. But the MmappedControlClock.h is missing from my svn checkout. Any help would be nice. Sincerely, Julie S. |
From: D. M. M. <ros...@gm...> - 2009-03-26 01:18:30
|
On Wednesday 25 March 2009, Julie S wrote: > When running make I get: > make: *** No rule to make target `src/sequencer/MmappedControlBlock.h', > needed by `src/document/RosegardenDocument.o'. Stop. Apparently whenever we delete files, we have to re-generate the dependencies file by hand, and apparently just attempting to re-generate the dependencies without first removing the dependencies file does not work. After some blind stumbling (Chris never really explained what to do after he moved the dependencies file out of SVN and created a new target) I eventually got it to build after using this combination: rm dependencies make -f qt4-makefile dependencies make This probably hints that we really need to fix the build system soon. In fact, I might have a quick look at that. -- D. Michael McIntyre |
From: Chris C. <ca...@al...> - 2009-03-26 10:16:38
|
On Thu, Mar 26, 2009 at 1:18 AM, D. Michael McIntyre <ros...@gm...> wrote: > After some blind stumbling (Chris never really explained what to do after he > moved the dependencies file out of SVN and created a new target) Oh, sorry. All you should need to do is remove the dependencies file and re-make. That could fail if you have a personal version of qt4-makefile without the "dependencies" target near the bottom (I added it to all the versions in svn). If that's the case, just copy that target and rule over from the standard one. Chris |
From: Julie S <msj...@ya...> - 2010-12-27 19:48:13
|
Hello All, In July we did an update to general tuplets. In notation editor this tuplet command has been assigned the key "J" which is conflict with our V/so pitched note that is also assigned "J". Therefore, the keyboard shortcut is ambiguous. I noticed this issue some time ago, but just now decided to track it down. There are really no letters left on the 26 English letter alphabet. I suggest we go with the semi-colon ";" as the shortcut. Works nicely here locally. Your thoughts. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2010-12-28 00:38:39
|
On Monday, December 27, 2010, Julie S wrote: > There are really no letters left on the 26 English letter alphabet. I > suggest we go with the semi-colon ";" as the shortcut. Works nicely here > locally. Fine with me. -- D. Michael McIntyre |