From: Richard B. <bo...@bo...> - 2002-01-29 16:54:02
|
Richard Bown wrote: > Saying that there appears to be a rounding error on the > LoopRuler at the moment (look a few bars into glazunov). Fixed. The LoopRuler now appears to correctly span the entire length of the piece. An interesting little problem now can be seen at one end of nocturno.rg - the Segments finish at bar 127 but the piece (and the LoopRuler) doesn't finish until 130. I'm presuming that Segment lengths should be taking into account the differing bar widths? R |
From: Chris C. <ca...@al...> - 2002-01-29 17:42:49
|
Richard Bown wrote: > Ok, this is changed now. [...] appears to be a rounding error on the > LoopRuler at the moment (look a few bars into glazunov). Oh, okay -- I shouldn't worry about getting the details quite right at the moment though as I'm intending to change it again so it gets the bar locations from some helper class, which can then deal with the vari-sized bars found in notation layout. Though it obviously still needed to pick up start and end from the Composition. I woulda done that today (that would have made for some fun merging) except I'm too knackered today -- tomorrow perhaps. Chris |
From: Richard B. <bo...@bo...> - 2002-01-29 17:45:59
|
Chris Cannam wrote: > I woulda done that today (that would have made for some fun > merging) except I'm too knackered today -- tomorrow perhaps. Yeah, would've been great fun. I've just checked in a couple of more tiny changes to get the GUI using the Composition start and end markers. If a document doesn't have them then they get set to the last bar in the piece plus an 10 extra bars for good measure. The results are still a little buggy but at least now the dependence of Composition width on Segment position has been cut. Negative bars should be coming right up I'd imagine.. R |
From: Chris C. <ca...@al...> - 2002-01-29 18:47:46
|
Richard Bown wrote: > Negative bars should be coming right up I'd imagine.. I think there are several places (particularly in notation) where "negative timeT" is taken to mean "timeT doesn't matter, use some suitable value like the end of the segment". One obvious place where this happens is in LinedStaff::positionElements and its subclasses. Are you expecting to have to render in notation segments that contain events at negative times? I'm sure these cases can all be "fixed" to use some other way of indicating no-time, though I'm not sure what's best -- perhaps passing pointers? Chris |
From: Richard B. <bo...@bo...> - 2002-01-29 19:13:13
|
Chris Cannam wrote: > I think there are several places (particularly in notation) where > "negative timeT" is taken to mean "timeT doesn't matter, use some > suitable value like the end of the segment". One obvious place > where this happens is in LinedStaff::positionElements and its > subclasses. > > Are you expecting to have to render in notation segments that > contain events at negative times? Yes I think so, Logic only manages a few bars of negative time so if changing current behaviour is a complete pain we could just say have four or so and just move our working zero. It's just somewhat of a useful feature sometimes i) for count in before recording a performance and ii) if you depserately want to stick something in at the beginning of the piece and you can't be bothered moving everything else further up. R |
From: Chris C. <ca...@al...> - 2002-01-29 21:01:22
|
Richard Bown wrote: > Chris Cannam wrote: >>Are you expecting to have to render in notation segments that >>contain events at negative times? > > Yes I think so, Logic only manages a few bars [...] Well, making a few bars work is probably no easier than just isolating and fixing the few places where negative time is given a special meaning. I think we might as well make it work in general. Chris |
From: Chris C. <ca...@al...> - 2002-01-30 10:00:27
|
Chris Cannam wrote: > isolating and fixing the few places where negative time is > given a special meaning. I've fixed all the ones I can think of right now. btw, take a look at notationstaff.h:98 and :139, and matrixstaff.h:63. Can anyone explain to me why these methods are necessary? (renderElements and positionElements have no-arg definitions in the LinedStaff base class, but the compiler doesn't seem to see them.) I'm probably just being really stupid and missing something very obvious. Another thing: when I first start the app, having given the name of a file to open on the command-line, it comes up with the pencil tool shown as selected on the toolbar but with the move tool actually selected in real life. (The move tool is also annoying because if you double-click with it, it frequently moves the segment as well as opening it. Surely the amount a segment is moved by should be related to the distance you move the pointer between click and release? At the moment it seems to jump the segment so that it starts from the pointer's position as soon as you move at all.) Chris |
From: Guillaume L. <gla...@te...> - 2002-01-30 15:16:13
|
On Wednesday 30 January 2002 10:57, Chris Cannam wrote: > > btw, take a look at notationstaff.h:98 and :139, and > matrixstaff.h:63. Can anyone explain to me why these methods > are necessary? (renderElements and positionElements have > no-arg definitions in the LinedStaff base class, but the > compiler doesn't seem to see them.) I think I recall a subtelty in the scope of the name resolution, namely that only the child class (and not the base one) is considered when the compiler is trying to solve the func name. It's not a compiler bug because MSVC6 rejects this too. > I'm probably just being really stupid and missing something > very obvious. No. I've asked our local C++ guru but he hasn't replied yet. In the meantime I've solved it by renaming the arg less versions to renderAllEvents()/positionAllEvents(). > Another thing: when I first start the app, having given the > name of a file to open on the command-line, it comes up with > the pencil tool shown as selected on the toolbar but with the > move tool actually selected in real life. Strange. I'll look into that. > (The move tool is > also annoying because if you double-click with it, it > frequently moves the segment as well as opening it. The problem is that having two completely different functions on click and double-click just won't work in the general case, since we can't know when a single click is actually the first of a double-click. > Surely > the amount a segment is moved by should be related to the > distance you move the pointer between click and release? Yes, but that won't solve the general case I'm afraid. I don't like this, it makes an inconsistent UI. Editing a segment should happen with the same action regardless of the tool, and with using double-click we can't have it happen from the eraser for instance. > At > the moment it seems to jump the segment so that it starts > from the pointer's position as soon as you move at all.) Yes, it "forces" the segment to the start of the position cursor. May be I can fix that too. -- Guillaume http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2002-01-30 23:38:17
|
On Wednesday 30 January 2002 16:15, I wrote: > > Another thing: when I first start the app, having given the > > name of a file to open on the command-line, it comes up with > > the pencil tool shown as selected on the toolbar but with the > > move tool actually selected in real life. > > Strange. I'll look into that. Fixed. That was because loading a file at startup doesn't use the same method than when invoked from the toolbar / menu. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-01-30 15:38:56
|
Guillaume Laurent wrote: > only the child class [...] is considered when the compiler > is trying to solve the func name. Wow. I think that's the first new thing I've learned about C++ (the language, as opposed to the standard library) for quite a lot of months. And it seems kind of basic. Chris |
From: Richard B. <bo...@bo...> - 2002-01-30 16:01:49
|
Chris Cannam wrote: > Wow. I think that's the first new thing I've learned about C++ > (the language, as opposed to the standard library) for quite a lot > of months. And it seems kind of basic. I suddenly feel ... very very lost. I try not to look down too much. R |
From: Guillaume L. <gla...@te...> - 2002-01-30 16:42:26
|
On Wednesday 30 January 2002 17:00, Richard Bown wrote: > Chris Cannam wrote: > > Wow. I think that's the first new thing I've learned about C++ > > (the language, as opposed to the standard library) for quite a lot > > of months. And it seems kind of basic. > > I suddenly feel ... very very lost. > I try not to look down too much. Here's the FAQ covering the problem : http://www.parashift.com/c++-faq-lite/strange-inheritance.html#[23.5] And a post covering it (there are many) : http://groups.google.com/groups?q=comp.lang.c%2B%2B.moderated+override+overload+inheritance&hl=en&selm=546db7%24k9m%40netlab.cs.rpi.edu&rnum=4 (see the thread as well) The problem is that overloading works only within the current scope. What still annoys me is that I can't remember the reason *why* this was made so, and neither can our C++ guy (and he seats on the C++ committee). -- Guillaume http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2002-01-30 16:59:56
|
On Wednesday 30 January 2002 17:41, I wrote: > The problem is that overloading works only within the current scope. What > still annoys me is that I can't remember the reason *why* this was made so, > and neither can our C++ guy (and he seats on the C++ committee). OK, now I do : this is to prevent the addition of a method in the base class "hijacking" a method in a child class. Suppose you have class Base { virtual void foo(int); }; class Child { virtual void foo(int); }; And then in the code you call Child::foo() passing it a double for instance, or anything which can be converted to an int. This works fine. But then if at some point you add void Base::foo(double); then all your calls too Child::foo(double/float) would go to Base::foo(double) without warning. To prevent that, overloading works only within the current scope. -- Guillaume http://www.telegraph-road.org |
From: Richard B. <bo...@bo...> - 2002-01-30 17:37:00
|
Because I'm feeling frivolous I spent today implementing VU meters on Midi tracks. Little velocity-flavoured bar graphs on the side of the TrackButtons. Works nicely with external MIDI devices but because the output isn't sync'd with the actual note playback those using aRTS synth instruments will notice the bar graphs being a little ahead of the playback - serves you right really. Actually the VU meters will play just ahead of the sequencer anyway as they're not accounting for the sequencer's playback latency. Quite frankly this behaviour isn't too annoying anyway and for the sake of the effort involved in syncing it up it can definitely wait, possibly forever. Not sure about the colours yet and I'm yet to implement the PeakHold flavour but have fun anyway. R |
From: Richard B. <bo...@bo...> - 2002-01-30 18:01:03
|
I'm pretty sure the answer is "No" but is there something double-buffer wise we haven't switched on for the main QCanvas or clients? It's a shame that the Segment redraw is visible when the pages flip or when you scroll. I imagine the trick is to wait for Qt3 and see what happens then. R |
From: Guillaume L. <gla...@te...> - 2002-01-30 18:08:49
|
On Wednesday 30 January 2002 18:59, Richard Bown wrote: > I'm pretty sure the answer is "No" but is there something double-buffer > wise we haven't switched on for the main QCanvas or clients? The answer is "No" indeed. The QCanvas uses double-buffering by default, and we haven't changed that. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-01-30 19:08:29
|
Richard Bown wrote: > Because I'm feeling frivolous I spent today implementing VU meters on Midi > tracks. Little velocity-flavoured bar graphs on the side of the TrackButtons. Oh, very cute. Yes, a bit irritating that it lags with the internal synth but it's still well worth having (if only so you know which track is which). My only serious complaint is that it makes the track buttons look a bit spare and irregular when there's nothing playing. Perhaps if the VUs were at the right, increasing leftwards rather than rightwards? Or would that be too wacky? Or perhaps just if there was a small frame around each. Chris |
From: Guillaume L. <gla...@te...> - 2002-03-25 22:34:11
|
Speaking of 0.2 tasks, we never finished this thread (my fault, I never replied). On Friday 18 January 2002 09:04, you wrote: > Guillaume Laurent wrote: > > On Thursday 17 January 2002 11:55, Chris Cannam wrote: > >>"triplet mode" [...] not much use > > > > I'm not sure I agree. Tuplets are most likely to be used as triplets, and > > for the other cases we could have a small combo or slider next to the > > tuplet icon which would let the user change its value. > > Well, first, what happens if you enter triplet mode, insert > one or two notes, then leave triplet mode? > > Second, "a small combo or slider" is unlikely to be sufficient. > A tuplet group has two parameters: the "beat" of the group, and > the number of beats you want to make the group really last. So > for example, six quavers might be intended to be played in the > time of four (or some other number of) quavers, in which case > you label them with a 6; or they might be in the time of two > crotchets, in which case you label them with a 3. Both cases > should sound much the same. Or they might (obscurely) be in > the time of three dotted crotchets, in which case their durations > will increase rather than decrease and they'll be labelled 2. > > You can deduce the label from the beat (it's the number of beats > in the group as written, rather than as played) and you can > deduce a set of possible beat values if you already know the > written duration of the whole group, but not otherwise. You > can't deduce the number of beats (or duration) of the group > as played; only the user can tell you that. And even then you > have to know the beat first, before you can offer the user a > reasonable choice of values. > > At least, I think that's how it should work. Check out the > tuplet dialog in RG2.1, of course. As I asked before: how would > you make "advanced" tuplet groups in other apps? > > This is really much the same problem as we have with dots. We > opted for the simplest way to allow users to add a single dot > to a note, because we couldn't think of an easy way to allow > them to add any number of dots. But that means we've lost > sight of the fact that it's really difficult to think of a > sensible GUI for double-dots, because most of the obvious ones > would require changing the duration of a note after it's been > inserted, and that isn't possible. (For double-dots this isn't > the end of the world -- once I've implemented Transforms | > Collapse Notes, which I've been meaning to for ages, you'll be > able to make them by inserting a dotted note and a very short > note and then collapsing them.) > > > Chris > > > _______________________________________________ > Rosegarden-devel mailing list > Ros...@li... > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-03-25 23:18:06
|
Guillaume Laurent wrote: > Speaking of 0.2 tasks, we never finished this thread (my fault, I never > replied). And are you planning to? I'm working on tuplets at the moment and I think I have a vague idea of how it's going to work. The mechanics behind it all are tricky enough, so at the moment I'm concentrating on getting the plain triplets working. (I know it looks like the mechanics are done because we can load some very complicated tuplets from glazunov.rg and play them fine, but editing is another thing entirely.) Rather encouragingly though, I was playing around with a copy of Finale the other day and I managed to crash it by clicking a few times at random in triplet mode. I wasn't even trying to do any very advanced tuplets. So I guess if nothing else we can aim to do better than that... Chris |
From: Guillaume L. <gla...@te...> - 2002-03-26 23:00:15
|
On Tuesday 26 March 2002 00:16, Chris Cannam wrote: > Guillaume Laurent wrote: > > Speaking of 0.2 tasks, we never finished this thread (my fault, I never > > replied). > > And are you planning to? Not really, as I finally concluded that I couldn't think of a better idea of a design for that. -- Guillaume. http://www.telegraph-road.org |