From: Chris C. <ca...@al...> - 2005-08-26 07:40:31
|
Guillaume: > So, unless there are any pending issues, are we > ready for a release ? I have some feature bits I had intended to transfer across from the stg branch before now, but I probably won't have time to do so for another week or more -- busy-ness, illness and holidays having all intervened. The main feature is the addition of another ALSA MIDI in and out port for "UI controller devices" that can control mixer levels etc directly for any instrument and receive feedback of level changes (designed for and tested with the Behringer BCF2000 motorised fader MIDI controller). It's not as complete as I'd like yet (when was a feature ever?) -- in particular there's nothing about it in the Studio GUI, which at least means there's nothing new to translate -- and I'm sure Pedro will point out some basic misfeatures, but it is enough to be usable. Chris |
From: Chris C. <ca...@al...> - 2005-09-16 09:42:24
|
Stephen Torri wrote: > The guitar tab editor is ready for another review. I took a look at it the other day but never got as far as writing anything. I may have a moment again in the next few days... I noticed that fingerings and barres now only apear in the chord editor when you release the mouse button, not on click or during a drag, which is a bit unintuitive (perhaps it's working differently for you?). I also managed to crash this editor but haven't got a stack trace for you yet. Is there a set of standard rules for how fingerings and barres "supersede" one another? I mean that when I add a new fingering or barre, others sometimes automatically disappear, and the rule doesn't seem to be as simple as (say) just removing anything else from the same string. (Or maybe it was actually that simple and I was just over tired.) Chris |
From: Stephen T. <st...@to...> - 2005-09-16 16:06:52
|
On Fri, 2005-09-16 at 09:40 +0000, Chris Cannam wrote: > I noticed that fingerings and barres now only apear in the chord > editor when you release the mouse button, not on click or during a > drag, which is a bit unintuitive (perhaps it's working differently for > you?). I also managed to crash this editor but haven't got a stack > trace for you yet.=20 This is my first rule GUI programming project so making it intuitive would be a good requirement to fulfill. I would appreciate someone to review my code and provide comments on how it can be improved. I will see what I can do this weekend to attempt to break it. > Is there a set of standard rules for how fingerings and barres > "supersede" one another? I mean that when I add a new fingering or > barre, others sometimes automatically disappear, and the rule doesn't > seem to be as simple as (say) just removing anything else from the > same string. (Or maybe it was actually that simple and I was just > over tired.) If a barre will hide a note, that is be in front of the note on the fretboard, the fingering should disappear. Its been a few weeks since I have done my work so I should provide something that gives guidance on the editor itself. The main goal that I worked towards was the actual chord selection and subsequent image generation. Stephen Stephen |
From: Chris C. <ca...@al...> - 2005-09-17 13:37:03
|
On Friday 16 Sep 2005 17:06, Stephen Torri wrote: > On Fri, 2005-09-16 at 09:40 +0000, Chris Cannam wrote: > > I also managed to crash this editor but haven't got a > > stack trace for you yet. > > [...] > I will see what I can do this weekend to attempt to break it. Here are some crash traces. Unfortunately I haven't managed to conjure up a fast rule for reproducing these -- generally I find they happen at a not necessarily expected moment usually when dragging out a barre. I did wonder whether they might be associated with drags that are too short to define an actual barre but that are perceived as drags rather than clicks by the code anyway, but I haven't been at all able to convince myself of that. Three traces here. The first one is an unterminating mutual recursion. You see a long stream of lines like Fingering::setNote - string #5, fret #1 Fingering::setNote - string #6, fret #1 Fingering::setNote - string #5, fret #1 Fingering::setNote - string #6, fret #1 Fingering::setNote - string #5, fret #1 Fingering::setNote - string #6, fret #1 Fingering::setNote - string #5, fret #1 Fingering::setNote - string #6, fret #1 Fingering::setNote - string #5, fret #1 Fingering::setNote - string #6, fret #1 Fingering::setNote - string #5, fret #1 Fingering::setNote - string #6, fret #1 on the console, and then: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1234648224 (LWP 5829)] 0xb6bba195 in _IO_file_xsputn () from /lib/tls/i686/cmov/libc.so.6 (gdb) where #0 0xb6bba195 in _IO_file_xsputn () from /lib/tls/i686/cmov/libc.so.6 #1 0xb6baf03f in fwrite () from /lib/tls/i686/cmov/libc.so.6 #2 0xb6d1b6a8 in std::__basic_file<char>::xsputn () from /usr/lib/libstdc++.so.5 #3 0xb6ccd303 in std::basic_filebuf<char, std::char_traits<char> >::_M_convert_to_external () from /usr/lib/libstdc++.so.5 #4 0xb6ccd081 in std::basic_filebuf<char, std::char_traits<char> >::_M_really_overflow () from /usr/lib/libstdc++.so.5 #5 0xb6cccf8c in std::basic_filebuf<char, std::char_traits<char> >::overflow () from /usr/lib/libstdc++.so.5 #6 0xb6d0a89f in std::basic_streambuf<char, std::char_traits<char> >::xsputn () from /usr/lib/libstdc++.so.5 #7 0xb6ccd808 in std::basic_filebuf<char, std::char_traits<char> >::xsputn () from /usr/lib/libstdc++.so.5 #8 0xb6cea3df in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_convert_int<unsigned long> () from /usr/lib/libstdc++.so.5 #9 0xb6ce9e10 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put () from /usr/lib/libstdc++.so.5 #10 0xb6cffa72 in std::ostream::operator<< () from /usr/lib/libstdc++.so.5 #11 0xb6cffdd6 in std::ostream::operator<< () from /usr/lib/libstdc++.so.5 #12 0x085026c3 in guitar::Fingering::setNote (this=0x8c95bd8, stringPos=6, notePos=1, actionVal=PRESSED) at RGbuild/gui/guitar/fingering.cpp:319 #13 0x08502cb3 in guitar::Fingering::splitBarre (this=0x8c95bd8, barrePtr=0x8c5c068, stringPos=@0xbf800494) at RGbuild/gui/guitar/fingering.cpp:450 #14 0x08502a03 in guitar::Fingering::checkNoteEffect (this=0x8c95bd8, stringPos=@0xbf800494) at RGbuild/gui/guitar/fingering.cpp:374 #15 0x08502718 in guitar::Fingering::setNote (this=0x8c95bd8, stringPos=5, notePos=1, actionVal=PRESSED) at RGbuild/gui/guitar/fingering.cpp:324 #16 0x08502c7e in guitar::Fingering::splitBarre (this=0x8c95bd8, barrePtr=0x8c5c068, stringPos=@0xbf8005a4) at RGbuild/gui/guitar/fingering.cpp:446 #17 0x08502a03 in guitar::Fingering::checkNoteEffect (this=0x8c95bd8, stringPos=@0xbf8005a4) at RGbuild/gui/guitar/fingering.cpp:374 #18 0x08502718 in guitar::Fingering::setNote (this=0x8c95bd8, stringPos=6, notePos=1, actionVal=PRESSED) at RGbuild/gui/guitar/fingering.cpp:324 #19 0x08502cb3 in guitar::Fingering::splitBarre (this=0x8c95bd8, barrePtr=0x8c5c068, stringPos=@0xbf8006b4) at RGbuild/gui/guitar/fingering.cpp:450 #20 0x08502a03 in guitar::Fingering::checkNoteEffect (this=0x8c95bd8, stringPos=@0xbf8006b4) at RGbuild/gui/guitar/fingering.cpp:374 [etc] Levels 0-11 are probably irrelevant, the point is that fingering.cpp line 374 calls line 450 calls line 324 calls line 374 and so on forever. The second and third are plain crashes, probably related but not the same. This one looks like perhaps an Event::get on an Event that's already been deleted (if it was a nonexistent property on an existing event, an exception would be thrown instead): FingeringConsturctor::mousePressEvent - press string #6, fret #3 Left border: 20 Left border: 20 Left border: 20 Left border: 20 Left border: 20 Left border: 20 Fingering::setNote - string #6, fret #3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1234648224 (LWP 5797)] 0x0839019b in std::_Rb_tree<Rosegarden::PropertyName, std::pair<Rosegarden::PropertyName const, Rosegarden::PropertyStoreBase*>, std::_Select1st<std::pair<Rosegarden::PropertyName const, Rosegarden::PropertyStoreBase*> >, std::less<Rosegarden::PropertyName>, std::allocator<std::pair<Rosegarden::PropertyName const, Rosegarden::PropertyStoreBase*> > >::find (this=0x11, __k=@0x872158c) at stl_tree.h:1267 1267 _Link_type __y = _M_header; // Last node which is not less than __k. (gdb) where #0 0x0839019b in std::_Rb_tree<Rosegarden::PropertyName, std::pair<Rosegarden::PropertyName const, Rosegarden::PropertyStoreBase*>, std::_Select1st<std::pair<Rosegarden::PropertyName const, Rosegarden::PropertyStoreBase*> >, std::less<Rosegarden::PropertyName>, std::allocator<std::pair<Rosegarden::PropertyName const,Rosegarden::PropertyStoreBase*> > >::find (this=0x11, __k=@0x872158c) at stl_tree.h:1267 #1 0x08390186 in std::map<Rosegarden::PropertyName, Rosegarden::PropertyStoreBase*, std::less<Rosegarden::PropertyName>, std::allocator<std::pair<Rosegarden::PropertyName const, Rosegarden::PropertyStoreBase*> > >::find (this=0x11, __x=@0x872158c) at stl_map.h:468 #2 0x08546378 in Rosegarden::Event::find (this=0x8cc4268, name=@0x872158c, i=@0xbfffdd30) at RGbuild/base/Event.C:130 #3 0x080e49af in Rosegarden::Event::find (this=0x8cc4268, name=@0x872158c, i=@0xbfffdd9c) at Event.h:360 #4 0x08504fe9 in Rosegarden::Event::get<(Rosegarden::PropertyType)4> ( this=0x8cc4268, name=@0x872158c, val=@0xbfffddc4) at Event.h:392 #5 0x085104ba in guitar::Barre::getStart (this=0x8a24018) at RGbuild/gui/guitar/barre.cpp:96 #6 0x08502c08 in guitar::Fingering::splitBarre (this=0x8c892b0, barrePtr=0x8a24018, stringPos=@0xbfffdee4) at RGbuild/gui/guitar/fingering.cpp:436 #7 0x08502a03 in guitar::Fingering::checkNoteEffect (this=0x8c892b0, stringPos=@0xbfffdee4) at RGbuild/gui/guitar/fingering.cpp:374 #8 0x08502718 in guitar::Fingering::setNote (this=0x8c892b0, stringPos=6, notePos=3, actionVal=PRESSED) at RGbuild/gui/guitar/fingering.cpp:324 #9 0x0851b38c in guitar::FingeringConstructor::mouseReleaseEvent ( this=0x8c89068, e=0xbfffe350) at RGbuild/gui/guitar/fingers.cpp:187 #10 0xb78d1b37 in QWidget::event () from /usr/lib/libqt-mt.so.3 #11 0xb783ee1f in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #12 0xb783e514 in QApplication::notify () from /usr/lib/libqt-mt.so.3 #13 0xb71e3e43 in KApplication::notify () from /usr/lib/libkdecore.so.4 #14 0xb77d35b0 in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3 #15 0xb77d123e in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 #16 0xb77e8254 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #17 0xb78511d8 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #18 0xb783f0d1 in QApplication::enter_loop () from /usr/lib/libqt-mt.so.3 #19 0xb7a260c0 in QDialog::exec () from /usr/lib/libqt-mt.so.3 #20 0x082bbb76 in FretboardInserter::handleLeftButtonPress (this=0x8c7b338, staffNo=0, e=0xbfffed00, element=0x0) at RGbuild/gui/notationtool.cpp:2139 #21 0x08194462 in EditTool::handleMousePress (this=0x8c7b338, time=0, height=3, staffNo=0, e=0xbfffed00, el=0x0) at RGbuild/gui/edittool.cpp:137 #22 0x082fda96 in NotationView::slotItemPressed (this=0x8a51870, height=3, staffNo=0, e=0xbfffed00, el=0x0) at RGbuild/gui/notationviewslots.cpp:2738 #23 0x082e6a05 in NotationView::qt_invoke (this=0x8a51870, _id=266, _o=0xbfffeb20) at notationview.moc:969 #24 0xb789b71c in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #25 0x0826a3d6 in NotationCanvasView::itemPressed (this=0x8c96788, t0=3, t1=0, t2=0xbfffed00, t3=0x0) at notationcanvasview.moc:149 #26 0x08269744 in NotationCanvasView::handleMousePress (this=0x8c96788, height=3, staffNo=0, e=0xbfffed00, el=0x0) at RGbuild/gui/notationcanvasview.cpp:288 #27 0x082694d3 in NotationCanvasView::contentsMousePressEvent (this=0x8c96788, e=0xbfffed00) at RGbuild/gui/notationcanvasview.cpp:247 #28 0xb79b1772 in QScrollView::viewportMousePressEvent () from /usr/lib/libqt-mt.so.3 #29 0xb79b10d5 in QScrollView::eventFilter () from /usr/lib/libqt-mt.so.3 #30 0xb789904e in QObject::activate_filters () from /usr/lib/libqt-mt.so.3 #31 0xb7898f7c in QObject::event () from /usr/lib/libqt-mt.so.3 #32 0xb78d1aaf in QWidget::event () from /usr/lib/libqt-mt.so.3 #33 0xb783ee1f in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #34 0xb783e514 in QApplication::notify () from /usr/lib/libqt-mt.so.3 #35 0xb71e3e43 in KApplication::notify () from /usr/lib/libkdecore.so.4 #36 0xb77d35b0 in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3 #37 0xb77d123e in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 #38 0xb77e8254 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #39 0xb78511d8 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #40 0xb7851088 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 #41 0xb783f071 in QApplication::exec () from /usr/lib/libqt-mt.so.3 #42 0x082013d4 in main (argc=3, argv=0xbffffa34) at RGbuild/gui/main.cpp:624 (gdb) This one _might_ be a bit more straightforward: FingeringConsturctor::mousePressEvent - press string #6, fret #2 Left border: 20 Left border: 20 Left border: 20 Left border: 20 Left border: 20 Left border: 20 Fingering::setNote - string #6, fret #2 Fingering::setBarre - fret #3067342436, start #3067342436, end #7 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1234648224 (LWP 5813)] 0x08510c7d in __normal_iterator (this=0xbfffdd9c, __i=@0x4) at stl_iterator.h:593 593 __normal_iterator(const _Iterator& __i) : _M_current(__i) { } (gdb) where #0 0x08510c7d in __normal_iterator (this=0xbfffdd9c, __i=@0x4) at stl_iterator.h:593 #1 0x08510c5c in std::vector<guitar::Barre*, std::allocator<guitar::Barre*> >::end (this=0x0) at stl_vector.h:371 #2 0x08510b2c in guitar::BarreList::erase (this=0x0, bar_ptr=0x8c90118) at RGbuild/gui/guitar/barrelist.cpp:43 #3 0x0850266b in guitar::Fingering::deleteBarre (this=0x8c930e0, barrePtr=0x8c90118) at RGbuild/gui/guitar/fingering.cpp:305 #4 0x08502f6e in guitar::Fingering::splitBarre (this=0x8c930e0, barrePtr=0x8c90118, stringPos=@0xbfffdee4) at RGbuild/gui/guitar/fingering.cpp:520 #5 0x08502a03 in guitar::Fingering::checkNoteEffect (this=0x8c930e0, stringPos=@0xbfffdee4) at RGbuild/gui/guitar/fingering.cpp:374 #6 0x08502718 in guitar::Fingering::setNote (this=0x8c930e0, stringPos=6, notePos=2, actionVal=PRESSED) at RGbuild/gui/guitar/fingering.cpp:324 #7 0x0851b38c in guitar::FingeringConstructor::mouseReleaseEvent ( this=0x8c92e98, e=0xbfffe350) at RGbuild/gui/guitar/fingers.cpp:187 #8 0xb78d1b37 in QWidget::event () from /usr/lib/libqt-mt.so.3 #9 0xb783ee1f in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #10 0xb783e514 in QApplication::notify () from /usr/lib/libqt-mt.so.3 #11 0xb71e3e43 in KApplication::notify () from /usr/lib/libkdecore.so.4 #12 0xb77d35b0 in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3 #13 0xb77d123e in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 #14 0xb77e8254 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #15 0xb78511d8 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #16 0xb783f0d1 in QApplication::enter_loop () from /usr/lib/libqt-mt.so.3 #17 0xb7a260c0 in QDialog::exec () from /usr/lib/libqt-mt.so.3 #18 0x082bbb76 in FretboardInserter::handleLeftButtonPress (this=0x8c7c130, staffNo=0, e=0xbfffed00, element=0x0) at RGbuild/gui/notationtool.cpp:2139 #19 0x08194462 in EditTool::handleMousePress (this=0x8c7c130, time=0, height=1, staffNo=0, e=0xbfffed00, el=0x0) at RGbuild/gui/edittool.cpp:137 #20 0x082fda96 in NotationView::slotItemPressed (this=0x8a55f60, height=1, staffNo=0, e=0xbfffed00, el=0x0) at RGbuild/gui/notationviewslots.cpp:2738 #21 0x082e6a05 in NotationView::qt_invoke (this=0x8a55f60, _id=266, _o=0xbfffeb20) at notationview.moc:969 #22 0xb789b71c in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #23 0x0826a3d6 in NotationCanvasView::itemPressed (this=0x8c99fb8, t0=1, t1=0, t2=0xbfffed00, t3=0x0) at notationcanvasview.moc:149 #24 0x08269744 in NotationCanvasView::handleMousePress (this=0x8c99fb8, height=1, staffNo=0, e=0xbfffed00, el=0x0) at RGbuild/gui/notationcanvasview.cpp:288 #25 0x082694d3 in NotationCanvasView::contentsMousePressEvent (this=0x8c99fb8, e=0xbfffed00) at RGbuild/gui/notationcanvasview.cpp:247 #26 0xb79b1772 in QScrollView::viewportMousePressEvent () from /usr/lib/libqt-mt.so.3 #27 0xb79b10d5 in QScrollView::eventFilter () from /usr/lib/libqt-mt.so.3 ---Type <return> to continue, or q <return> to quit--- #28 0xb789904e in QObject::activate_filters () from /usr/lib/libqt-mt.so.3 #29 0xb7898f7c in QObject::event () from /usr/lib/libqt-mt.so.3 #30 0xb78d1aaf in QWidget::event () from /usr/lib/libqt-mt.so.3 #31 0xb783ee1f in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #32 0xb783e514 in QApplication::notify () from /usr/lib/libqt-mt.so.3 #33 0xb71e3e43 in KApplication::notify () from /usr/lib/libkdecore.so.4 #34 0xb77d35b0 in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3 #35 0xb77d123e in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 #36 0xb77e8254 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #37 0xb78511d8 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #38 0xb7851088 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 #39 0xb783f071 in QApplication::exec () from /usr/lib/libqt-mt.so.3 #40 0x082013d4 in main (argc=3, argv=0xbffffa34) at RGbuild/gui/main.cpp:624 (gdb) Hope this is helpful. Chris |
From: Chris C. <ca...@al...> - 2005-09-17 13:41:30
|
On Friday 16 Sep 2005 17:06, Stephen Torri wrote: > If a barre will hide a note, that is be in front of the note on the > fretboard, the fingering should disappear. Here's one thing that looks odd to me. Say you start with a barre in the bottom space across the middle four strings. Now, if you add another barre across the middle two strings _above_ it (i.e. before it on the fretboard), the original barre stays unchanged. That's no surprise as the original barre is hiding the new one. However, if instead you add a single note on one of the middle two strings above the original barre, the original barre is split, even though it could be assumed to hide the new note as well. Chris |
From: Chris C. <ca...@al...> - 2005-09-17 14:02:33
|
OK, I've made the most basic change to place the fretboard above the staff instead of below. This just consists of assigning a y coordinate in NotationVLayout::scanStaff (search for "Fingering" -- the model is much as you already applied in NotationStaff). A few notes: * The fretboard will have to be rather smaller relative to the staff size for this to work! At the moment it only just fits between the top of the window and the top staff line. Or the amount of space above the staff could be increased... the fretboard probably should be a bit smaller and squarer anyway though. * The x-coord for the fretboard is currently assigned using the default logic in NotationHLayout according to where it sits in the event list. If this isn't what you want, NotationHLayout is similar (but a bit more complicated) to tweak. It may be a good idea for Fingering::getAsEvent to assign a negative SubOrdering value to the event it returns so as to place it slightly before the default positioning for other events at the same time (see e.g. Text::EventSubOrdering in base/NotationTypes.C, where Text events are given a subordering of -70 compared to e.g. -250 for clefs and +10 for rests -- this defines the relative ordering of these events where they appear at the same time). * PropertyName values should usually be persistent (i.e. usually static) constants where possible. (We do sometimes break this rule elsewhere, but it's still a decent rule.) If you look at the PropertyName constructor implementations you'll see that they do a certain amount of work to intern the string values on construction so as to enable fast comparison from integers afterwards. This optimisation is undermined (to some extent) if they are always constructed as temporaries from strings when used. Chris |
From: Chris C. <ca...@al...> - 2005-09-17 14:21:36
|
On Saturday 17 Sep 2005 15:03, Chris Cannam wrote: > A few notes: > [...] * Single-clicking on the fretboard to open the fretboard editor isn't a good idea, as it's inconsistent and surprising within the interface at large, and prevents single-click-based options such as selection. Double-click (and ideally a context-dependent right-button menu option, something we lack in general) would be preferable, with single-click retaining its default action (select). Chris |
From: Stephen T. <st...@to...> - 2005-09-25 22:02:30
|
On Sat, 2005-09-17 at 15:22 +0100, Chris Cannam wrote: > On Saturday 17 Sep 2005 15:03, Chris Cannam wrote: > > A few notes: > > [...] >=20 > * Single-clicking on the fretboard to open the fretboard editor isn't a=20 > good idea, as it's inconsistent and surprising within the interface at=20 > large, and prevents single-click-based options such as selection. =20 > Double-click (and ideally a context-dependent right-button menu option,=20 > something we lack in general) would be preferable, with single-click=20 > retaining its default action (select). >=20 >=20 > Chris I am writing to let you know my time commitment to rosegarden. Sundays are my rest from school work so I am planning taking a few hours each Sunday to work on the guitar chord editor. My plans are to do: 1) Work on requirements and problems a) Eliminate segfaults b) Double click open guitar tab editor (DONE) c) Single click selects fretboard d) Fretboard image made smaller (DONE) e) Set assigned negative SubOrdering value to Fingering::getAsEvent f) Show barre being drawn as the mouse pointer is dragged 2) Add features: a) Double click on select fretboard image will result in guitar tab editor opening with select chord displayed b) Provide ability to drag fretboard from one location to another Did I miss as requirements or problems? I am looking for GUI design problems or requirements that rosegarden users should expect to see. My work is listed in order of priority. Some were so simple that I did them quickly or had done so already. At the end of each sunday I will commit the work to CVS. That way anyone interested in the progress of this list can sync up and review. Stephen |
From: Chris C. <ca...@al...> - 2005-09-26 18:25:58
|
On Sunday 25 Sep 2005 23:02, Stephen Torri wrote: > On Sat, 2005-09-17 at 15:22 +0100, Chris Cannam wrote: > > On Saturday 17 Sep 2005 15:03, Chris Cannam wrote: > > * Single-clicking on the fretboard to open the fretboard editor > > isn't a good idea Actually, I'd like to retract that one, with apologies for the misdirection. I see now that what you were doing was taken from the behaviour of the Text tool. With that tool active, you click once to insert text, and then click once on existing text to edit it. It's entirely reasonable for the fretboard tool to work the same way. What was confusing me was the fact that activating the fretboard tool doesn't yet change the mouse cursor, so I had forgotten the fretboard tool was active. With the default selection tool active, double-clicking on a fretboard should ideally open the fretboard editor. I was thinking you'd somehow coded it up so that single-click with the default tool opened the fretboard editor; I see this isn't the case. So, ideally: * Single-click with fretboard tool on an existing fretboard opens fretboard editor on that fretboard (just as you originally coded -- sorry about that) * Single-click with fretboard tool in empty space opens fretboard editor for a new fretboard (also just as you originally coded) * Fretboard tool needs to change the mouse cursor (to what, I wonder?) just as the text tool and others do * Double-click with selection tool on an existing fretboard does likewise (does this work for text? I can't remember. It should) * Single-click with selection tool on an existing fretboard selects that fretboard (I would expect this to work by default). > b) Provide ability to drag fretboard from one location to another This may not be necessary -- the existing micro-positioning (shift-click-drag) might already work. I haven't had a moment to try it. > At the end of each sunday I will commit the work to CVS. That way > anyone interested in the progress of this list can sync up and > review. That sounds good. I'm very much looking forward to seeing this work ready and integrated. By the way, I have a point of conceptual confusion about the fretboard editor. Let's say you open it and select a known chord through the selection boxes at the top. Then you edit the chord on the fretboard, so as to end up with something totally different. But the name of the chord you started from is still shown above, even though it's now completely different. So what is actually stored in the composition when you apply the dialog? Does it record the formal name of the known chord you started from, or just the modified fingering? Is there any way in the GUI to assign a new name to a modified fingering? (I guess that has to be part of the plan, along with saving them out to file.) I'm just vaguely wondering whether somewhere, deep down in the .rg file, there's always going to be something faintly identifying your completely spurious chord with the nice plain C major you started with when creating it. Chris |
From: Stephen T. <st...@to...> - 2005-09-26 20:08:09
|
On Mon, 2005-09-26 at 19:27 +0100, Chris Cannam wrote: > * Single-click with fretboard tool on an existing fretboard opens=20 > fretboard editor on that fretboard (just as you originally coded --=20 > sorry about that) My code did not do this. I am more for a double-click doing the editing > * Single-click with fretboard tool in empty space opens fretboard=20 > editor for a new fretboard (also just as you originally coded) I can change that back. > * Fretboard tool needs to change the mouse cursor (to what, I wonder?)=20 > just as the text tool and others do > * Double-click with selection tool on an existing fretboard does=20 > likewise (does this work for text? I can't remember. It should) My intent is to edit an existing fretboard by opening the editor via a double-click. > * Single-click with selection tool on an existing fretboard selects=20 > that fretboard (I would expect this to work by default). Ok. > > b) Provide ability to drag fretboard from one location to another >=20 > This may not be necessary -- the existing micro-positioning=20 > (shift-click-drag) might already work. I haven't had a moment to try=20 > it. I will have to try the shift-click-drag and see how it goes myself. > By the way, I have a point of conceptual confusion about the fretboard=20 > editor. Let's say you open it and select a known chord through the=20 > selection boxes at the top. Then you edit the chord on the fretboard,=20 > so as to end up with something totally different. But the name of the=20 > chord you started from is still shown above, even though it's now=20 > completely different. So what is actually stored in the composition=20 > when you apply the dialog? At that event position the chord you modified would be stored. > Does it record the formal name of the known chord you started from, or = just the modified fingering? It records the modified fingering. The naming is used to help you select the original chord in the first place. > Is there any way in the GUI to assign a new name to a modified fingering?= (I guess=20 > that has to be part of the plan, along with saving them out to file.) =20 For now I have all new chords being added via the xml files. I had not gotten that far to consider how I can allow users to add new ones. My original thought was that rosegarden would provide all the original XML files. When the user used the guitar tab editor for the first time it would read the original XML files to populate a single user XML file (e.g. rosegarden_chords.xml). If a user adds a new chord we could simply rewrite the file. if rosegarden_chords.xml is not found - read original xml files - write user rosegarden_chords.xml else - read user rosegarden_chords.xml If new chord added - write user rosegarden_chords.xml > I'm just vaguely wondering whether somewhere, deep down in the .rg=20 > file, there's always going to be something faintly identifying your=20 > completely spurious chord with the nice plain C major you started with=20 > when creating it. I hope you see that the name is not recorded only the fingering is in the .rg file. Stephen |
From: Pedro Lopez-C. <ped...@gm...> - 2005-09-10 18:52:54
|
On Friday 26 August 2005 09:39, Chris Cannam wrote: > The main feature is the addition of another ALSA MIDI in and out port for > "UI controller devices" that can control mixer levels etc directly for any > instrument and receive feedback of level changes (designed for and tested > with the Behringer BCF2000 motorised fader MIDI controller). [...] > I'm sure Pedro will point out some basic misfeatures I can't. I don't have any suitable device to test this. Regards, Pedro |
From: Chris C. <ca...@al...> - 2005-09-10 19:13:41
|
On Saturday 10 Sep 2005 19:53, Pedro Lopez-Cabanillas wrote: > On Friday 26 August 2005 09:39, Chris Cannam wrote: > > The main feature is the addition of another ALSA MIDI in and out > > port for "UI controller devices" that can control mixer levels etc > > directly for any instrument and receive feedback of level changes > > (designed for and tested with the Behringer BCF2000 motorised fader > > MIDI controller). > > [...] > > > I'm sure Pedro will point out some basic misfeatures > > I can't. I don't have any suitable device to test this. You don't have a MIDI device with controller knobs or faders? The feature should be useful with any such -- feedback for motorised faders or knobs with readouts (etc) is only part of it. Chris |
From: Pedro Lopez-C. <ped...@gm...> - 2005-09-10 20:44:58
|
On Saturday 10 September 2005 21:14, Chris Cannam wrote: > On Saturday 10 Sep 2005 19:53, Pedro Lopez-Cabanillas wrote: > > On Friday 26 August 2005 09:39, Chris Cannam wrote: > > > The main feature is the addition of another ALSA MIDI in and out > > > port for "UI controller devices" that can control mixer levels etc > > > directly for any instrument and receive feedback of level changes > > > (designed for and tested with the Behringer BCF2000 motorised fader > > > MIDI controller). > > > > [...] > > > > > I'm sure Pedro will point out some basic misfeatures > > > > I can't. I don't have any suitable device to test this. > > You don't have a MIDI device with controller knobs or faders? My JV-80 has only *one* programmable slider, and it is not motorized, so I can't see the feedback effect. I can use it, for instance, to move the volume slider for channel 1 in the MIDI mixer window and the IPB. It works. About the MIDI mixer layout. The volume sliders are too much little. When you resize the window to make it taller, the volume sliders keep tiny. > The feature should be useful with any such -- feedback for motorised > faders or knobs with readouts (etc) is only part of it. I've used also a software emulation, midicontroller: http://sourceforge.net/projects/midicontrol/ Another emulator, qmidicontrol is too much limited: http://sourceforge.net/projects/alsamodular But these programs only can send control messages, they don't have an input port to test the feedback feature. I'm sure it works as expected. And I can't think now about any missfeatures. Regards, Pedro |