## rosegarden-devel

 [Rosegarden-devel] Displaying more than one track in matrix view From: Guillaume Laurent - 2001-12-16 14:25:16 ```I'm a bit dubitative of the idea of showing more than one track in matrix view. The problem is that a "matrix staff" is fairly large (I'm assuming as many lines as piano keys, so 88 lines), so piling several together make something fairly large which won't be comfortable to visualize or edit because you'll keep scrolling up and down constantly. A possible solution is to display only the lines within a specific range around the notes, but then that will complicate editing quite a bit if you want to add notes which are out of that range. -- Guillaume. http://www.telegraph-road.org ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Chris Cannam - 2001-12-16 15:35:22 ```Guillaume Laurent wrote: > The problem is that a "matrix staff" is fairly large (I'm assuming as > many lines as piano keys, so 88 lines) Are there 88 piano keys, or 88 white piano keys? I assume the matrix's lines should be spaced at one per pitch value, rather than irregularly spaced like notation staff lines or white piano keys. Either way, I agree placing one staff above another is not going to be much use. One could potentially interleave them (the line for pitch N on staff M, then the line for pitch N on staff M+1, then that for pitch N+1 on staff M...), which might be more use. Chris ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Guillaume Laurent - 2001-12-17 00:24:35 Attachments: piano_roll.png ```On Sunday 16 December 2001 16:32, Chris Cannam wrote: > Guillaume Laurent wrote: > > The problem is that a "matrix staff" is fairly large (I'm assuming as > > many lines as piano keys, so 88 lines) > > Are there 88 piano keys, or 88 white piano keys? 88 in total if I recall correctly... I'm actually not even sure of that :-) > I assume the > matrix's lines should be spaced at one per pitch value, rather > than irregularly spaced like notation staff lines or white > piano keys. Yes. This is apparently the case looking at Cubase (see attached screenshot). Notice how the matrix grid is alligned with the keyboard. It seems awkward at first, but I can't figure out a better way to do it. > Either way, I agree placing one staff above another is not going > to be much use. One could potentially interleave them (the line > for pitch N on staff M, then the line for pitch N on staff M+1, > then that for pitch N+1 on staff M...), which might be more use. Yuck. How readable would that be ? -- Guillaume. http://www.telegraph-road.org ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Chris Cannam - 2001-12-17 09:55:39 Attachments: rg21pianoroll.png ```Guillaume Laurent wrote: > This is apparently the case looking at Cubase (see attached screenshot). Or indeed Rosegarden 2.1 (see attached screenshot), in which the fine details of the layout are not quite as clear but the overall shape of the thing is still fairly plain. (The bars used to represent notes are the width of a whole piano key, but are centred on y-coordinates that are spaced in half-piano-key steps. The light grey bars correspond to black keys on the keyboard.) I am inclined to think RG2.1's vertical lines (only visible at bar lines) are a nicer default than Cubase's dense grid, although I'd probably go for a compromise (solid lines at bar lines, very light grey lines every TimeSignature::getBeatDuration(). I'm sure Bownie will have one or more opinions on this (and a screenshot of Logic would give us more to go on). >>One could potentially interleave them > > Yuck. How readable would that be ? It wouldn't be very readable in the detail, but it might give you a very nice overview of how and when the various segments interact. Chris ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Richard Bown - 2001-12-17 10:34:48 ```> so 88 lines Erm, well you'd want 127 lines really to fit all the MIDI values on wouldn't you? R ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Guillaume Laurent - 2001-12-17 10:40:06 ```On Monday 17 December 2001 11:33, Richard Bown wrote: > > so 88 lines > > Erm, well you'd want 127 lines really to fit all the MIDI values on > wouldn't you? Er, yes. -- Guillaume http://www.telegraph-road.org ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Chris Cannam - 2001-12-17 15:36:52 ```Richard Bown wrote: > Erm, well you'd want 127 lines really to fit all the MIDI values on > wouldn't you? Really? Does the MIDI pitch range not include zero? Chris ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Richard Bown - 2001-12-17 21:02:21 ```> Really? Does the MIDI pitch range not include zero? Sorry yeah, pitch 0 = C -2 pitch 127 = G 8 R ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Guillaume Laurent - 2001-12-17 10:46:58 ```On Monday 17 December 2001 10:51, Chris Cannam wrote: > I'd probably go for a compromise (solid lines at bar lines, very > light grey lines every TimeSignature::getBeatDuration(). That was my idea as well. > [ several tracks on piano roll ] > > It wouldn't be very readable in the detail, but it might give you > a very nice overview of how and when the various segments interact. But isn't that what the track editor is supposed to show ? Right now segments are just plain rectangles, but most sequencers shows a reduced version of the segments content (audio or piano roll) in the rectangle, and there's no reason we couldn't achieve the same effect. -- Guillaume http://www.telegraph-road.org ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Chris Cannam - 2001-12-17 15:38:04 ```Guillaume Laurent wrote: > But isn't that what the track editor is supposed to show ? That's a fair point. I thought it might be interesting to see two or more tracks effectively sharing the same space but in different colours, but I guess it isn't terribly practical, particularly for editing. Oh well, just a thought. Chris ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Richard Bown - 2001-12-17 12:26:59 ```Guillaume Laurent wrote: > > I'd probably go for a compromise (solid lines at bar lines, very > > light grey lines every TimeSignature::getBeatDuration(). BTW, Logic adjusts the number of horizontal division lines according to the value of the time division (as we currently have displayed on the transport). R ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Chris Cannam - 2001-12-17 15:43:54 ```Richard Bown wrote: > Logic adjusts the number of horizontal division lines according to > the value of the time division (as we currently have displayed on the > transport). You mean the /16 thing (that's probably intended at some point to correspond to the legato setting on the notation view)? How does that work, then? Presumably you wrote /16 because that's a likely default, and presumably that means a sixteenth note (which is what, a semiquaver? That's certainly a sensible default for the legato setting). Does that mean Logic draws a line every semiquaver, or sixteen lines per 4/4 bar? That's a heck of a lot of lines. I suppose one might get away with dark lines on bars, light lines on beats, and very, very, very light lines on the divisions. I take it the division is also what the editing tools snap to when drawing notes and things on the piano roll? Chris ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Richard Bown - 2001-12-17 20:57:22 ```> Does that mean Logic draws a line every semiquaver, or sixteen lines > per 4/4 bar? That's a heck of a lot of lines. No, it depends on the zoom level for this - I think it will render them but only if you're zoomed right in. > I take it the division is also what the editing tools snap to when > drawing notes and things on the piano roll? Yep, although you can override it of course with a modifier. B ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Henry Stanaland - 2001-12-18 09:02:23 ```On Monday 17 December 2001 10:34 am, you wrote: > Guillaume Laurent wrote: > > But isn't that what the track editor is supposed to show ? > > That's a fair point. I thought it might be interesting to see > two or more tracks effectively sharing the same space but in > different colours, but I guess it isn't terribly practical, > particularly for editing. Oh well, just a thought. Well not just the track editor, but the staff view should definately have as many staffs as a user would want. And nother "nicety" would be if you could view the staff as pages rather than on long horizontal line(for those of us whose purpose is the sheet music). That is my last comment though because I wanted to let you know that you haven't heard from me because I've been doing final projects and final exams and I'm flying home for the holidays. I just found out that the airlines won't allow more than one carry on baggage, so I'm not going to take my computer home, thus I probably won't be able to do the work on rosegarden that I intended. I am going to take my hard drive in the hopes that I can find a PC that I can just pop it into and run KDevelop, but I doubt my girlfriend will let me. Anyhows, you'll hear from me in February. And I expect a fully working Rosegarden complete with synced audio....and a nice splash screen :-) Henry ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Chris Cannam - 2001-12-18 12:11:21 ```Henry Stanaland wrote: > Well not just the track editor, but the staff view should definately > have as many staffs as a user would want. Well, it does -- at least, it can show one staff or all of them. I could do with working out a mechanism for allowing the user to choose a subset of staffs though. (Multiple selection on the track editor, something like that.) > if you could view the staff as pages rather than on long horizontal > line And by a happy coincidence, that's one of the things I've been working on over the last few days. (Well, it doesn't strictly divide the score up into pages, but it does put one line of score above another in what ultimately works out to be a single very tall page.) Of course, the more we make the staff layout able to look like the printed page, the more people are going to want it to print properly. It's probably not too difficult to get draft-quality printing, but I really should get around to Lilypond output. Chris ```
 Re: [Rosegarden-devel] Displaying more than one track in matrix view From: Chris Cannam - 2001-12-23 16:38:53 ```Henry Stanaland wrote: > a nice splash screen :-) Actually, there are all sorts of images knocking around on the web that might make amusingly crap splash-screens. http://emc.syr.edu/tour/resized%20photos/rose%20garden.jpg http://snogirl.50megs.com/CollectorsSigns/rose-garden.gif http://www.azstarnet.com/destinations/outdoors/parks/04-o-Rose-Garden.jpg etc, from a quick Google search. Well, maybe not. Chris ```
 [Rosegarden-devel] mute buttons From: Richard Bown - 2001-12-20 09:00:07 ```Ok, the mute buttons now work. I've introduced a new "XmlExportable" class in base/ - it's similar to that in gui/ but it's STL based. Track, Instrument and Composition currently inherit from it and hence have to implement its only virtual method - string toXmlString(). Mute and record buttons are saved out to XML now as are the Tracks and Instruments. Composition currently exports only the current record track but will hopefully soon capture pointer position, tempo, timing division etc. etc. R ```
 Re: [Rosegarden-devel] mute buttons From: Chris Cannam - 2001-12-20 22:07:31 ```Richard Bown wrote: > tempo Tempo changes during the piece, doesn't it? According to the presence of tempo events in the composition's reference segment. There's no point in saving the "current tempo", because it can be deduced at any time given the reference segment and playback pointer position. Similarly there's no point in loading it, because the m_currentTempo field would only be overwritten next time the pointer position changed. It is worth saving and loading the default tempo, but it's probably also worth marking it such. (In fact there already was code to load it in rosexmlhandler.cpp -- I've just removed one of the two. At least, I would have if I could get a connection to SourceForge at the moment.) Chris ```
 Re: [Rosegarden-devel] mute buttons From: Richard Bown - 2001-12-21 08:32:19 ```> It is worth saving and loading the default tempo, but it's > probably also worth marking it such. (In fact there already > was code to load it in rosexmlhandler.cpp -- I've just removed > one of the two. Yeah I saw that but thought I'd bung in the extra code to perplex you. R ```
 [Rosegarden-devel] tempo From: Richard Bown - 2001-12-21 09:36:47 ```I wrote: > Yeah I saw that but thought I'd bung in the extra code to perplex you. Actually, I now notice some weird behaviour with importing MIDI files. When a file is loaded the tempo isn't updated to the new value dictated by the file timing division i.e. glaznov.mid should play at 72 but when loaded plays at 120 - if you stop and restart the proper tempo then applies itself. Also, the glazonov.xml file always appears to load at 120. R ```
 Re: [Rosegarden-devel] tempo From: Chris Cannam - 2001-12-22 14:13:45 ```Richard Bown wrote: > Actually, I now notice some weird behaviour with importing MIDI files. > When a file is loaded the tempo isn't updated to the new value dictated > by the file timing division i.e. glaznov.mid should play at 72 Hang on, can we get this clear here? One of us is misunderstanding the way tempo works in MIDI. My understanding was that the timing division (the one in the MIDI file header) was used solely to work out the relationship between the timestamps recorded in the MIDI file and the actual clock times of the events. For example, loading up glazunov.mid in RG2.1, I see (from the Midi | Set Timebase function) that it has a timing division of 160. I thought this meant that the events have been saved into the file with a delta-time unit such that 160 units equals one crotchet (equals 24 MIDI clocks). But this is only relevant when reading the file, in order to determine the right Rosegarden-unit durations and absolute times for the notes, and in order to make sure the correct notes are used in the score editor and wherever. On its own, it tells you nothing useful about the tempo, and we don't even bother to store it anywhere (because we've already finished with it, having created the events). Tempo is defined by the use of tempo events, normally found in track zero. glazunov.mid has three -- one at the start, for tempo 76, one at crotchet 129, for tempo 96, and one at crotchet 193, for tempo 76 again. So what _should_ happen is that when you play the piece, each time the sequencer wants to send a note, it queries the tempo first: for the first section, it should get 76 back, then during the middle section 96, then back to 76. > Also, the glazonov.xml file always appears to load at 120. Well, 120 is our default tempo for when we haven't seen any tempo events yet. In principle tempo is meaningless unless you're actually playing something, so we might as well show the default. In practice this file has a tempo at time zero, so we should be using it as an effective default anyway. I'll take a look and try to work out why it ain't working right. But please, can you read through my description and let me know if you think I have the wrong idea about all this? It's the basis on which the Composition getTempo stuff is written, so obviously if I'm wrong, it's wrong. Chris ```
 Re: [Rosegarden-devel] tempo From: Richard Bown - 2001-12-22 14:22:14 ```> Hang on, can we get this clear here? One of us is misunderstanding > the way tempo works in MIDI. I agree with your description of how the timing division is used to describe the timing of events regardless of tempo. I think the problem I have is that for some reason I've convinced myself that timing division should also give you a clue to a default tempo for the track - I'm not quite sure how I got this into my head but it's been in there for quite a while (and crept into the code which I think you had to remove). No, you're right. And once I or you, or whoever implements MIDI_SET_TEMPO at line 626 of MidiFile.cpp we should start seeing tempo events being created - presumably in the reference segment? R ```
 Re: [Rosegarden-devel] mute buttons From: Chris Cannam - 2001-12-21 10:53:50 ```Richard Bown wrote: > I've introduced a new "XmlExportable" class in > base/ - it's similar to that in gui/ I don't think there was any particular reason why XmlStorableEvent was in gui, except that (a) all the I/O was in gui, and (b) it uses the Qt classes, which is hardly necessary for export but is very useful for import. Personally I would rather like to see most of the import and export code defined in the same place (at the moment there's too much in rosexmlhandler) and I'd rather like that to be in base/. But I don't really want Qt classes. I'm sure we've been through this before, but since you've just introduced a suitable pattern that we could conceivably use for segments and events as well, is this a good moment to try to thrash out how the rest of the xml I/O should be done? btw, speaking of I/O, anyone suggest a nice simple way to read a hexadecimal integer from a QString (in the same way as toInt reads a decimal one)? I need this in rg21io.cpp, and I keep forgetting to deal with it. I should probably just use the C library. Chris ```
 Re: [Rosegarden-devel] mute buttons From: Richard Bown - 2001-12-21 12:46:02 ```Chris Cannam wrote: > is this a good moment to try to thrash out how the rest of the xml > I/O should be done? It probably is, if not now then soon. With ever the more complicating structure of the file (with Instruments and the beginnings of Environment) we're going to need an angle. Where did we get to with that talk of DTDs and like? What about the heirarchy I've started to introduce with the new elements (Track and Instrument within Composition) ? > btw, speaking of I/O, anyone suggest a nice simple way to read a > hexadecimal integer from a QString (in the same way as toInt reads > a decimal one)? I hate to say it after slagging off QTextStream but, erm, why don't you have a look at QTextStream? R ```
 Re: [Rosegarden-devel] mute buttons From: Chris Cannam - 2001-12-21 16:54:39 ```Richard Bown wrote: > I hate to say it after slagging off QTextStream When were you doing that? I don't think I've ever heard of it. Anyway yes, it looks like that does pretty much what I want (and what a remarkable resemblance to the C++ iostreams API it bears too). On the other hand, strtol(my_qstring.latin1(), 0, 16) is probably simpler even so. (I was thinking of using sscanf, but I'd forgotten that strtol does bases above ten.) Chris ```
1 2 3 > >> (Page 1 of 3)