From: D. M. M. <ros...@gm...> - 2009-03-06 03:44:57
|
If any of you background fence sitters are looking for something small but useful to do, we have a ton of broken signals. I just spent a bit of time in one isolated case, and I was able to sort out one of the problems, while leaving the other one with an explanatory comment showing where I had been. It just seems to be a signal mismatch kind of deal, where whatever we converted had one set of signals, and whatever we converted to has a slightly (or radically) different set of signals. Some of these might get quite ugly, but I bet a lot of them are as easy as the one I managed to fix successfully. Just ./rosegarden 2>&1|grep connect to see the warning messages, like these examples: Object::connect: No such signal Rosegarden::CompositionView::contentsMoving(int,int) Object::connect: No such signal Rosegarden::CompositionView::contentsMoving(int,int) Object::disconnect: No such signal Rosegarden::CompositionView::contentsMoving(int,int) Object::connect: No such signal Rosegarden::CompositionView::contentsMoving(int,int) Object::connect: No such signal QTreeWidget::pressed(QTreeWidgetItem*) Object::connect: (receiver name: 'markereditordialog') Then go investigate the signals that actually exist in the new class, and make it all work. It's probably a nice little piddle project for someone who wants to be helpful, but can't spare much time. We can certainly use all the piddling we can get out of you folks out there, so piddle away! -- D. Michael McIntyre |
From: D. M. M. <ros...@gm...> - 2009-03-07 04:03:20
|
If any of you background fence sitters are looking for something small but useful to do, we need to convert all QLineEdit and QInputDialog to LineEdit and InputDialog. It's an easy swap except for changing #include <QLineEdit> into #include "gui/widgets/LineEdit.h" and moving the new include to its proper place in the include groupings. You might also have to edit a few InputDialogs to add a this, or a 0, at the start, as some of our uses of the dialog omit this parameter. -- D. Michael McIntyre |
From: D. M. M. <ros...@gm...> - 2009-03-07 04:18:08
|
If any of you background fence sitters are looking for something small but useful to do, we need to figure out why the following dialogs are coming up with too small a size: Segments -> Set Start Time Segments -> Stretch or Squash Segments -> Split... -> Split at Time I'm sure they share a common thread. There was one other one on the list, but I just fixed that one. Yay me. The one I fixed, the solution won't apply to any of the above though, unfortunately. (Boo.) -- D. Michael McIntyre |
From: D. M. M. <ros...@gm...> - 2009-03-08 18:13:32
|
We have a million of these: QPainter::begin: Widget painting can only begin as a result of a paintEvent QPainter::begin: Widget painting can only begin as a result of a paintEvent I notice it got a lot worse when I loaded a file that had tempo ramps and audio segments in it. I'm not sure which is causing the problem to be so greatly exacerbated. I don't really know anything about what I'm doing with painter-related code, but I've gleaned that in Qt4 everything involving a painter has to be done in paintEvent, or in something called by paintEvent. It seems these warnings are from where we're trying to paint outside paintEvent in one context or other, though I haven't actually located a real example of this yet. It seems a bit tricky to hunt these down, since there's frequently no contextual clue in the debug stream what code is operating to trigger these warnings. They seem to be fairly harmless warnings too, but with so many of them pouring out it fills up my scrollback buffer in no time flat, I'm fairly sure we must be incurring some performance penalty at the least. -- D. Michael McIntyre |
From: D. M. M. <ros...@gm...> - 2009-03-08 19:29:08
|
There are a number of problems with menu items not being enabled/disabled properly. For instance, if there is no segment selected, then Segments -> should be totally disabled except for "Manage Triggered Segments" and some top level menus that lead to submenus that are all disabled. I notice the range-related functions on Edit -> have the same problem. I don't remember exactly how this used to work, and I'm not sure how we broke it, but this is something that's probably fairly simple that needs ironing out. Fix one, and the rest are probably really easy to fix. -- D. Michael McIntyre |
From: D. M. M. <ros...@gm...> - 2009-03-17 03:45:34
|
When you manipulate controllers in the mixer windows, the equivalent controllers in appropriate IPBs are supposed to move in sync. This currently works well for the audio pan controllers, and the MIDI Pan controllers on device 1 instrument 1, and I think most or all volume controllers. Chorus, Reverb in the MIDI mixer, and most Pan controllers except device 1 instrument 1 fail to emit the proper signals, or the signals aren't getting caught, or I don't know what exactly. I was going to try to untangle this today, and I got caught up doing a whole lot of everything else. It would be a good project for somebody looking for something fairly narrowly focused and well-contained. Enough is working that the breakage is probably something pretty simple here. -- D. Michael McIntyre |
From: Chris F. <chr...@go...> - 2009-03-21 12:09:20
|
D. Michael McIntyre wrote: > When you manipulate controllers in the mixer windows, the equivalent > controllers in appropriate IPBs are supposed to move in sync. > > This currently works well for the audio pan controllers, and the MIDI Pan > controllers on device 1 instrument 1, and I think most or all volume > controllers. Chorus, Reverb in the MIDI mixer, and most Pan controllers > except device 1 instrument 1 fail to emit the proper signals, or the signals > aren't getting caught, or I don't know what exactly. > > I've ground to a bit of a halt on this one. I've established that all the slots are connected properly and that the code to emit the signals is being called. The relevant signals are, however, blocked in slotUpdateInstrument() which is called during the MIDIMixerWindow constructor. This is done using blockSignals(true) - took a lot of head scratching to find that ... slot is connected, signal is emitted, slot isn't called ... erm ... They are left blocked because, when trying to read values from the instruments, the relevant controls (eg Reverb - MIDIByte 91 and Chorus - MIDIByte 93) are not found in the instrument. MIDIMixerWindow thinks the controls should be there as it got them from the MIDIDevice using getIPBControlParameters(). I don't know how the MIDIDevice gets setup with one set of controls but it's instruments have another (or rather in this case NO controls at all). This appears to be the root cause. I'm running the app without having started JACK. Does anyone know where the General MIDI device is created? |
From: D. M. M. <ros...@gm...> - 2009-03-21 16:23:52
|
On Saturday 21 March 2009, Chris Fryer wrote: > The relevant signals are, however, blocked in slotUpdateInstrument() > which is called during the MIDIMixerWindow constructor. > This is done using blockSignals(true) - took a lot of head scratching to > find that ... slot is connected, signal is emitted, slot isn't called > ... erm ... > > They are left blocked because, when trying to read values from the > instruments, the relevant controls (eg Reverb - MIDIByte 91 and Chorus - > MIDIByte 93) are not found in the instrument. > > MIDIMixerWindow thinks the controls should be there as it got them from > the MIDIDevice using getIPBControlParameters(). If we're talking about a bare bones scenario with only the factory autoload, using "General MIDI Device" for everything, then these controllers SHOULD be there. > I don't know how the MIDIDevice gets setup with one set of controls but > it's instruments have another (or rather in this case NO controls at > all). This appears to be the root cause. Interesting. Very interesting. > I'm running the app without having started JACK. Does anyone know where > the General MIDI device is created? "General MIDI Device" is supplied for the first available MIDI playback device, and it's defined in the factory default autoload.rg file. This gets loaded and set up at RosegardenDocument::performAutoload() which calls GzipFile::readFromFile() which calls xmlParse() which calls QXmlSimpleReader() with RoseXmlHandler() as its handler. I'm not quite sure from there exactly where the controllers are getting loaded out of the autoload file, as the logic of all of this is a bit confusing at a glance. I hacked the autoload file to force visible and obvious changes confirming this is where the controllers are coming from though. Delete reverb and chorus from the autoload, and they disappear. Volume too, though there's still a fader in the MIDI mixer. We won't worry about that, since deleting pan and volume is a bad idea. Now it gets interesting. We detect all available ALSA MIDI writeable ports and create devices for them on the fly (which behavior is debatable, but for now that's how it works) as needed. The first of these spontaneously-created devices for me is "MIDI soundcard synth 2" (with "General MIDI Device" having an implied 1.) These on-the-fly devices 2..n all have volume, pan, chorus and reverb controllers, and I can't for the life of me figure out where they're coming from. There has to be some code somewhere that defines these four as a minimum for otherwise empty devices, and I sense that might hold a key to unravelling the larger problem here, but I can't find it. -- D. Michael McIntyre |