I set out to sort out the bank editor, but I have to say after two days of
this I think I lack the patience to see this through.
The first thing I did was stop a frequent crash by commenting out in
BankEditorDialog.cpp populateDevice()
// m_programEditor->clearAll();
// m_keyMappingEditor->clearAll();
I don't know why that was crashing, and I don't know to what extent that code
being removed is causing the other symptoms I see.
This dialog has major, major problems.
First, the conversion from KListView to QTreeWidget is broken in some subtle
way I can't figure out. For each available Rosegarden::MidiDevice (which is
just the one "General MIDI Device" in the current scheme of things) we want
to create a top level QTreeWidgetItem of that name, then we want to iterate
through the banks and keymaps belonging to this device and add
QTreeWidgetItems under that parent with a name, type, LSB and MSB contained
in a QStringList.
I can't find anything wrong with the inheritance here in code terms, but there
must be something wrong. On the first pass, in the ctor I think, this comes
up with no device name, blanks for everything except the percussion key map.
If I try to Import... an .rgd file into the existing device, I get an internal
error trying to load into the blank top level item. I have to load into one
of the blank child items instead (a clue), and upon doing that, I get a
complete mess.
Import the Juno-whatever.rgd file (there's only one, I'm not looking at the
names) and you get a structure like
Top Level: Juno-blah
Child 1: Bank 1 blah 0 0
Child 2: Bank 1 blah 0 0
Bank 2 blah 0 1
Bank 3 blah 0 3
Bank 4 blah 0 4
Child 1: Bank 2 blah 0 1
Child 2: Bank 1 blah 0 0
Bank 2 blah 0 1
Bank 3 blah 0 3
Bank 4 blah 0 4
Child 1: Bank 3 blah 0 2
Child 2: Bank 1 blah 0 0
Bank 2 blah 0 1
Bank 3 blah 0 3
Bank 4 blah 0 4
That's not exactly right. Just look at it with your own eyes to see what I
mean. The inheritance seems to be off by one level or something. It's
populating each child level QWidgetItem with all the banks, and winding up
with three layers instead of two.
That's on the the tip of the iceberg with this too. The program editor widget
never gets populated with anything. This might be due to the inheritance
problem, and it's trying to get populated from the wrong level, where there
is no data to populate it with, or it could be due to the two missing
signals.
One signal was an itemChanged(), I think. I corrected the name to Qt4 idiom,
but the object in question (QTreeWidget I believe) doesn't have that signal,
but rather QTreeWidgetItem does. Something is wired up completely
incorrectly there.
Beyond this, I'm sure there are more and more problems. The whole thing is
full of things to click on to cause crashes. Everything you try, just about,
causes a crash for one reason or another, and most of the crashes come up in
MidiProgram's == operator in one way or another.
The way I solved a big problem last time was to selectively comment out huge
blocks of code and work on getting one thing at a time to work from the
ground up. I can't see a path to do that with this, because it's such a huge
and complicated webwork with BankEditorDialog, MidiBankTreeWidgetItem,
MidiDeviceTreeWidgetItem, MidiKeyMapTreeWidgetItem, NameSetEditor,
MidiProgram, and possibly more.
I have concluded that either somebody else is going to have to sort this out
or I am going to have to write a new bank editor from the ground up, just so
I can understand how it works from the ground up, and solve one problem at a
time from the ground up. If I got a working infrastructure to build on, I
might be able to pull in other bits, like the NameSetEditor without totally
reinventing everything, but it's probably just not necessary to go to this
much trouble. Could it possibly really be that bad? More likely, I'm just
not good enough at sorting out complex problems like this, and a good
detective could save me a metric buttload of work.
I'd far prefer to see someone else sort this out. I'm going to quit and find
something else to do before I have to be carted off to the nuthouse. I keep
hoping the key to unlocking this whole thing is something really simple and
obvious, and after fixing that, everything else will start to fall into some
kind of order that makes everything else more apparent, but so far the harder
I dig the more our existing code looks like it ought to work, and
catastrophically does not.
--
D. Michael McIntyre
------------------------------------------------------------------------------
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
