From: Guillaume L. <gla...@te...> - 2001-12-29 17:17:04
|
I forgot : I have to comment that line out out linedstaff.cpp for it to compile : while ((int)m_staffLines.size() <= lastRow) { // m_staffLines.push_back(LineList()); m_staffConnectingLines.push_back(0); } (line 474). This is probably the reason why I don't see the lines anymore, though :-). -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2001-12-29 17:39:02
|
On Saturday 29 December 2001 18:16, Guillaume Laurent wrote: > I forgot : I have to comment that line out out linedstaff.cpp for it to > compile : > > while ((int)m_staffLines.size() <= lastRow) { > // m_staffLines.push_back(LineList()); > m_staffConnectingLines.push_back(0); > } > > (line 474). This is probably the reason why I don't see the lines anymore, > though :-). No, it's not. I've changed the FastVector in typedef FastVector<QCanvasLine *> LineList; to an std::vector and it compiles, but the lines are still gone. BTW, I forgot to send the error message using FastVector : /usr/include/g++-3/stl_construct.h: In function `void construct (_T1 *, const _T2 &) [with _T1 = FastVector<QCanvasLine *>, _T2 = FastVector<QCanvasLine *>]': /usr/include/g++-3/stl_vector.h:321: instantiated from `vector<_Tp, _Alloc>::push_back (const _Tp &) [with _Tp = FastVector<QCanvasLine *>, _Alloc = allocator<FastVector<QCanvasLine *> >]' linedstaff.cpp:475: instantiated from `LinedStaff<T>::resizeStaffLines () [with T = NotationElement]' linedstaff.h:337: instantiated from here /usr/include/g++-3/stl_construct.h:48: no matching function for call to `FastVector<QCanvasLine *>::operator new (unsigned int, FastVector<QCanvasLine *> *&)' It seems that FastVector<> doesn't like to be put in an std::vector and lacks the appropriate ctor for that. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2001-12-29 18:22:54
|
Guillaume Laurent wrote: > the lines are still gone. Yes, that's something quite different. Hold on a minute, I haven't finished yet. > /usr/include/g++-3/stl_construct.h:48: no matching function for call to > `FastVector<QCanvasLine *>::operator new (unsigned int, > FastVector<QCanvasLine *> *&)' > > It seems that FastVector<> doesn't like to be put in an std::vector and > lacks the appropriate ctor for that. Oh, weird. I can't quite work out what constructor it expects -- that error message doesn't make much sense to me. Anyway, I've changed the vector<FastVector<> > to a FastVector<FastVector<> > just to see what happens. Another check-in coming soon. Chris |
From: Chris C. <ca...@al...> - 2001-12-29 18:24:43
|
Chris Cannam wrote: > Anyway, I've > changed the vector<FastVector<> > to a FastVector<FastVector<> > > just to see what happens. Fails to compile, now, with a very similar error to the one you report. Interesting. Oh well, I'll make the same change as you for the moment. Chris |
From: Chris C. <ca...@al...> - 2001-12-29 18:47:10
|
Chris Cannam wrote: > Guillaume Laurent wrote: > >> the lines are still gone. > > Yes, that's something quite different. Hokay, the lines are there now. Note that the rectangles are currently displayed centred on lines, not between them -- that's a simple fix I intend to make, unless you look at it and decide for some reason you like it better this way... Chris |
From: Guillaume L. <gla...@te...> - 2001-12-29 19:22:58
|
On Saturday 29 December 2001 19:45, Chris Cannam wrote: > > Hokay, the lines are there now. Yup, looks great. > Note that the rectangles are > currently displayed centred on lines, not between them -- that's > a simple fix I intend to make, unless you look at it and decide > for some reason you like it better this way... No, the previous way is much preferable IMHO. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2001-12-30 10:25:31
|
Guillaume Laurent wrote: > No, the previous way is much preferable IMHO. I'll sort it out. But it'll be another day or two before I do that or the proper matrix-style vertical line code, because I'm going to make a detour to sort out this tempo-segment thing in the Composition and to make sure mapped events only have real-time timestamps first. In the meantime, note that I've made a couple of fairly fundamental changes to the matrix element. It now stores the layout coordinates separately from the rectangle's canvas coordinates, in much the same way as the notation element does; then the staff maps the layout coordinates onto canvas coordinates according to its origin (which will not in future be at (0,0) as there'll be a staff ruler at the top and a piano keyboard at the left -- you can change the staff's origin just by calling setX/setY on the staff at any point before the call to sizeStaff() happens). This means that (for structural reasons -- it'd be simple to get around this, but probably inadvisable) only the staff can assign the final canvas coordinates to elements. Therefore if you want to position an element outside of positionElements(), or position a rectangle that is not an element, you'd probably be well-advised to make a staff method that contains the basic arithmetic from the centre of the MatrixStaff::positionElements loop and performs that on a single rectangle or element. (getCanvasCoordsForLayoutCoords is your basic tool, even if in this case all it really does is add the staff's m_x and m_y to the given coordinates.) Then the canvas view, or whatever class wants to position the item, should call that. btw, if you fancy doing the piano keyboard thing, check out Midi_PianoRollDrawBackground in rg21's sequencer/src/PianoRoll.c, which draws a nice scalable keyboard. It might be worth stealing the basic sums from there instead of working them out again. Chris |
From: Guillaume L. <gla...@te...> - 2001-12-31 19:01:02
|
On Saturday 29 December 2001 19:45, Chris Cannam wrote: > > Hokay, the lines are there now. Note that the rectangles are > currently displayed centred on lines, not between them -- that's > a simple fix I intend to make BTW I fixed it. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2001-12-31 19:32:50
|
Guillaume Laurent wrote: > On Saturday 29 December 2001 19:45, Chris Cannam wrote: > >>Note that the rectangles are >>currently displayed centred on lines, not between them -- that's >>a simple fix I intend to make > > BTW I fixed it. I think probably wrongly though, looking at the CVS logs. It looks like you've just moved the rectangles, which means the code that calculates pitches from y-coordinates will produce results that don't match the rectangles, so inserted notes will get wrong pitches some of the time. The correct fix is for the LinedStaff to know that it's dealing with a staff on which notes go between the lines, and to displace the lines instead of the rectangles. I strongly suggest leaving it as it is for now though until I get a chance to check this interpretation and make the change, because I know what to expect to go wrong. Chris |
From: Guillaume L. <gla...@te...> - 2002-01-01 17:15:46
|
On Monday 31 December 2001 20:30, Chris Cannam wrote: > Guillaume Laurent wrote: > > On Saturday 29 December 2001 19:45, Chris Cannam wrote: > >>Note that the rectangles are > >>currently displayed centred on lines, not between them -- that's > >>a simple fix I intend to make > > > > BTW I fixed it. > > I think probably wrongly though, looking at the CVS logs. It > looks like you've just moved the rectangles, which means the > code that calculates pitches from y-coordinates will produce > results that don't match the rectangles, so inserted notes will > get wrong pitches some of the time. You're right. When I click in a cell to insert a new note, the pitch is off by 1 half of the time. But for the moment it's good enough for my tests. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-01-01 21:56:59
|
Guillaume Laurent wrote: > You're right. When I click in a cell to insert a new note, the pitch is off > by 1 half of the time. But for the moment it's good enough for my tests. Well, I've made the change I was intending to make in order to fix this (see use of LinedStaff::elementsInSpaces) but it doesn't seem to work correctly. I'm getting a bit too tired to think this through at the moment, so I can look at it tomorrow or you could see if you can see the probably obvious flaw in my reasoning. I'm afraid for the moment this means the notes are back on the lines again instead of between them. Sorry about that. Chris |
From: Chris C. <ca...@al...> - 2002-01-02 14:03:13
|
Chris Cannam wrote: > see if you can see the probably obvious flaw in my reasoning. Yep, it was pretty damn obvious. Chris |
From: Richard B. <bo...@bo...> - 2002-01-02 18:35:44
|
Recording moves a step closer. The gui is now getting recorded MIDI events but it doesn't actually display or store them as yet. At the moment if you connect both record port to MIDI in and play port to MIDI out all recorded events chase through both ports and off to infinity - crashing artsd and usually your X server as well for good measure. Be warned! On the plus side MIDI events sent to the record port (i.e. from any MIDI instruments plugged into your computer) will now show up as a note and octave on the right of the Transport. This is Logic/Cubase stylee. BTW what's happened to our top level "configure"? R |
From: Guillaume L. <gla...@te...> - 2002-01-02 18:46:38
|
On Wednesday 02 January 2002 19:34, Richard Bown wrote: > BTW what's happened to our top level "configure"? What do you mean ? It's supposed to be generated locally. -- Guillaume. http://www.telegraph-road.org |
From: Richard B. <bo...@bo...> - 2002-01-02 19:59:16
|
Oh and BTW it helps if you renice "rosegardensequencer" to something high if you want your asynchronous MIDI events to appear when you expect them! R |
From: Chris C. <ca...@al...> - 2002-01-02 22:33:36
|
Richard Bown wrote: > Recording moves a step closer. Marvellous. Of course, this is one feature I have absolutely no way of testing. In reply to your earlier compile error, may I offer this link one: rosegardentransportdialog.o: In function `_Rb_tree<int, pair<int const, QPixmap>, _Select1st<pair<int const, QPixmap> >, less<int>, allocator<QPixmap> >::_S_color(_Rb_tree_node<pair<int const, QPixmap> > *)': /usr/include/g++/stl_tree.h(.text+0x2b): undefined reference to `Rosegarden::RosegardenTransportDialog::QPaintDevice virtual table' /usr/include/g++/stl_tree.h(.text+0x32): undefined reference to `Rosegarden::RosegardenTransportDialog virtual table' rosegardentransportdialog.o: In function `Rosegarden::RosegardenTransportDialog::~RosegardenTransportDialog(void)': /home/cannam/rosegarden/gui/rosegardentransportdialog.cpp:105: undefined reference to `Rosegarden::RosegardenTransportDialog::QPaintDevice virtual table' /home/cannam/rosegarden/gui/rosegardentransportdialog.cpp:105: undefined reference to `Rosegarden::RosegardenTransportDialog virtual table' collect2: ld returned 1 exit status Undefined virtual tables often suggest to me things like inline virtual destructor definitions (so the compiler can't find the right file for the class because it looks in the one with the destructor in it, and there isn't one) but that doesn't appear to be the case here. Last successful CVS update and build was late this morning. Chris |
From: Guillaume L. <gla...@te...> - 2002-01-02 22:44:46
|
On Wednesday 02 January 2002 23:30, Chris Cannam wrote: > Marvellous. Of course, this is one feature I have absolutely > no way of testing. Neither can I. > Undefined virtual tables often suggest to me things like inline > virtual destructor definitions (so the compiler can't find the > right file for the class because it looks in the one with the > destructor in it, and there isn't one) but that doesn't appear to > be the case here. In Qt this is typical of a missing moc file. Usually a make clean; make -f Makefile.cvs; ./configure solves it. -- Guillaume. http://www.telegraph-road.org |
From: Richard B. <bo...@bo...> - 2002-01-02 23:03:30
|
Guillaume Laurent wrote: > In Qt this is typical of a missing moc file. Usually a make clean; make -f > Makefile.cvs; ./configure solves it. Yep, that's what I did - in fact I checked in the changes after I had the same link error as Chris did with FULL KNOWLEDGE that the pesky thing would go away after a complete rebuild. Oh yes. Oh no. As you don't know what you're missing I shall at some point have to cobble together a virtual keyboard type thing as an aRTS client so you can watch it in action. Look Daddy, now it says "A2" ! R |
From: Richard B. <bo...@bo...> - 2002-01-02 23:42:07
|
BTW addressing the problem G noticed with the load that the sequencer was pulling, I've now put in some sleep time to give everyone a rest every loop through (duh). Playback performance on my machine is unaffected (still good, like the new mandolin piece) and the decrease in load means that the gui behaves much more smoothly (note the pointer movement). Try it and see what you think. If you have playback problems fiddle around with the usleep value. We can probably make this auto-throttle too. Woo. R |
From: Chris C. <ca...@al...> - 2002-01-03 14:53:28
|
Richard Bown wrote: > like the new mandolin > piece Is your "like" a verb or a conjunction? I like it, although essentially I chose it because I wanted a test piece that looks good in the existing application (it's very undemanding to render). Also it's in 2/4, where our other test files are in 4/4, and it has quite a few small changes in tempo, which might make it a good test piece for when we get real-time timestamps in mapped events. The big problem with introducing something like this to the distribution is that we don't currently handle any sort of text event, which means we can't keep the copyright and transcription information from the original MIDI file. For reference, this one is a transcription of a minor Beethoven piece in C major, transcribed by Dave Homans, found at www.classicalarchives.com. The first staff is the mandolin, the other two are piano. Chris |
From: Richard B. <bo...@bo...> - 2002-01-03 16:31:17
|
Chris wrote; > > like the new mandolin > > piece > > Is your "like" a verb or a conjunction? Yes. > I like it, although essentially I chose it because I wanted a > test piece that looks good in the existing application (it's > very undemanding to render). Also it's in 2/4, where our other > test files are in 4/4, and it has quite a few small changes in > tempo, which might make it a good test piece for when we get > real-time timestamps in mapped events. Yes, when indeed. Are we waiting for a release or just going to plow right in at some point? I would go ahead and start to implement storing and displaying recorded events at the GUI but then I'd have to rework this bit when the new timestamps come along so I might hang off as you (Chris) suggested and synchronise the work. > The big problem with introducing something like this to the > distribution is that we don't currently handle any sort of text > event, which means we can't keep the copyright and transcription > information from the original MIDI file. Well it'd be nice to tackle this at the Composition soon along with support for more esoteric MIDI events (Controller messages, SysExs). Testing wise, after getting into horrible looping problems this morning and yesterday when playing and recording using this configuration: Rosegarden (play) ---> MIDI OUT ----> Hardware Synth | (record) | MIDI OUT ^ | | | ---------------------------------------------- I've now successfully tested this config: MIDI Keyboard (OUT) ------> (record) Rosegarden (play) | | v Hardware Synth This works for both Rosegarden playing and recording i.e. when Rosegarden is playing a piece all MIDI events from the keyboard are THRU'd to the Synth along with piece that's playing, when Rosegarden is recording the events are still THRU'd to the synth along with events from all playing tracks but the MIDI events are also captured in Rosegarden. One issue that raised itself this morning is how to synchronise the sounding of the notes to the display on the GUI. The MIDI OUT box on the Transport will need to display what is note is currently sounding and we will undoutedly want pretty little MIDI VU meters on each Track as visual indication of which Tracks are sounding. The sequencer reads a slice of notes to be played and cues them up with aRTS (working slightly in the future of course) - either we arrange for a per note DCOP callback to be made when the note finally goes out (undoubtedly expensive with everything else going on) or we just use simple timing at the GUI to synchronise the sounding of the note with a relevant display item. All good clean fun. Just thoughts. As incomprehensible as ever I imagine. R |