Code Log

Commit Date  
[r13118] by dmmcintyr

Fix #1361

It looks like this was a purely superficial bug that caused the display to
behave strangely without actually affecting the real setting of any affected
parameters. This bug was courtesy of none other than yours truly, and I have no
idea WTF I was thinking. It looks like I was just skimming API docs in a big
hurry, and I grabbed something that looked superficially correct, and rewrote
several lines as utter garbage.

I didn't study the mechanics exhaustively, and basically just looked for a
better way to rewrite the old Qt 3 code that was still helpfully left in
comments. This looks right, and it passes a cursory test.

Please thrash this and let's be sure it's really working now. In particular, I
didn't even look at the track parameter box before instituting the same sort of
changes over there, and I'm not even sure it was broken before. It most likely
was, but this was just a blind guess.

2012-10-19 12:01:48 Tree
[r13117] by tedfelix

Rename replaceRecordedEvent() to adjustEndTimes().

Also fixed a bug I injected last commit where the recorded channel was not
being preserved for note on events.

2012-10-08 20:27:11 Tree
[r13116] by tedfelix

Better handling of overlapping note-on events.

This partially fixes bug #1350 the "Beethoven Problem". rg still has trouble
recording the full Moonlight Sonata third movement MIDI file.

2012-10-08 15:35:38 Tree
[r13115] by dmmcintyr

Translation tweaks from Holger Marzen

2012-10-07 21:05:49 Tree
[r13114] by tedfelix

Cleanup: Variable renaming, comments, code shuffling, and simplification.

2012-10-03 19:13:26 Tree
[r13113] by tedfelix


2012-10-03 01:21:41 Tree
[r13112] by dmmcintyr

Finish fixing #1357. The rewritten table logic was just totally mangled, so I hacked on it a little until I got it working. It's probably not how I would write this from scratch, but considering how many years it has gone without anybody noticing how totally useless this dialog was, I don't think it matters very much if it's elegant or not.

2012-10-01 23:23:10 Tree
[r13111] by dmmcintyr

Bug #1357: fix the broken layout

2012-10-01 22:23:37 Tree
[r13110] by tedfelix

Move static eventIndex from SequencerDataBlock::getVisual() to class scope.
Comments and simplification.

2012-09-30 16:46:17 Tree
[r13109] by tedfelix

Complete and simplify SequencerDataBlock::clearTemporaries().

2012-09-30 14:01:59 Tree
[r13108] by dmmcintyr

Get rid of unwanted pixels that have been bugging me for years

2012-09-29 19:37:03 Tree
[r13107] by tedfelix

Moved readIndex from within getRecordedEvents() to being a member.
This clears up a potential bug where ghost events might appear after
recording, then doing a File > New, then recording again. readIndex
was not getting cleared and would point to the last position in the
buffer which would cause unexpected events to be read from the buffer
on the next call to getRecordedEvents(). Now m_readIndex is cleared
in clearTemporaries().

Removed mutex that was added in my previous commit. I believe this
lock-free implementation is actually thread-safe. See the
comments for details.

Added comments. Code simplification.

2012-09-27 22:36:12 Tree
[r13106] by tedfelix

Add mutex to SequencerDataBlock for MIDI events. Comments.

2012-09-27 00:21:48 Tree
[r13105] by tedfelix

Comments about using autoreconf.

2012-09-26 22:26:02 Tree
[r13104] by cannam

Meter deflection fix from Robin Gareus

2012-09-26 20:25:33 Tree
[r13103] by dmmcintyr

Tim Munro had doubts about this patch, and it wasn't really intended to be
applied as is so much as to illustrate a point. Ted Felix agreed to investigate
more deeply and work out some decision eventually whether Tim's solution is the
right approach, or maybe there is a deeper issue at play, and Tim's approach is
just scraping mold off the surface of a piece of bread.

It's all well and good for Ted to dig deeper, but I decided to just go ahead and
commit the patch after user Holger Marzen tried it (along with Tim's other
patch) and prounced the result "da fukin' best Rosegarden ever!"

When Ted gets a chance to do some of his famously methodical puzzle solving, he
may end up reverting this patch. In the meantime, one user was really pleased
with it as is, so why not just commit it for now and run with it?

Here's a copy of the discussion for quick reference:

This concerns bug #3560849 reported recently (2012-08-23) by Ted Felix:

1. Launch rg.
2. Studio > Manage Synth Plugins.
3. Configure synth plug-in #1 by selecting a plug-in from the dropdown.
4. Click on "Controls" button for #1. Controls dialog will appear.
5. Close the controls dialog.
6. Close the Manage Synth Plugins dialog.
7. Studio > Manage Synth Plugins.
8. Click on "Controls" button next to #1.
9. Crash.

I think I might have accidentally fixed this a few months ago, while
tackling a similar bug in my own copy of Rosegarden:

1. Launch rg.
2. Studio > Audio Mixer.
3. Click on any one of the plug-in buttons below the sliders.
4. Close the plug-in dialog.
5. Close the Audio Mixer dialog.
6. Studio > Audio Mixer.
7. Click on the same plug-in button as before.
8. Crash.

The problem, it seems, is in
"src/gui/application/RosegardenMainWindow.cpp." The conditional
statement at line 7551 is apparently not doing its job, so (I'm
guessing) line 7586 can refer to a parent that probably no longer
exists. I don't know how to fix this right, but my hack involves hard
coding line 7586 to refer directly to "this" rather than to "parent."

I occupy a small corner of the Rosegarden world, using only the
notation editor, along with DSSI-softsynth and LADSPA plugins.
Anything that I do to fix my own copy of Rosegarden could easily damage
some other aspect of the program, and I would never know it, because I
never go there. My understanding of Rosegarden and C++ is limited.

That's a fancy way of saying that I don't mean for the patch that I've
attached to be applied as is. I've included it only because it shows
exactly what I've done to make the problem go away. It's one of about
a dozen patches that I routinely apply to my own copy of Rosegarden
(svn_12984 currently) to make life easier.

The last part of the patch concerning
"src/gui/dialogs/AudioPluginDialog.cpp" is not directly related to this
problem but does involve the LADSPA plugins. It solves the highly
annoying problem of LADSPA-plugin controls initially displaying some
screwy default settings, instead of showing the settings previously
saved in the .rg file. It's the same problem that Holger Marzen has
mentioned a couple of times.


2012-09-24 07:54:52 Tree
[r13102] by dmmcintyr

Excellent bit of detective work from Tim Munro fixes problems with not being
able to enter floating point values into Rotary controls without them getting
mangled horribly:

In long, boring detail, here is what I discovered.

The problem begins in Rotary::mouseDoubleClickEvent

When a rotary widget is double clicked, a spinBox is created by
FloatEdit to manipulate the value directly. A rotary widget in the
logarithmic mode works on the logarithms of the actual minimum, maximum,
and position values, so these logarithms must be converted back into
actual values, in order to keep the spinBox happy. Furthermore,
FloatEdit uses the value of "step" to define the number of decimal
places for the spinBox, as well as to set its step. Beginning at
line 436,

minv = powf(10, minv);
maxv = powf(10, maxv);
val = powf(10, val);
correctly reconstitute the original values, but
step = powf(10, step);
does not.

Rather than tampering with the laws of mathematics, I decided to
redefine step initially as

step = (maxv - minv) / 100.0;

This initial value can then be used to pick a final value for step that
will (probably) yield an acceptable number of decimal places in the

if (step > 1.0) {
step = .1;
} else if (step > .1) {
step = .01;
} else {
step = .001;

Hopping over to FloatEdit::FloatEdit (src/gui/dialogs/FloatEdit.cpp),
another problem shows up at line 56:

double calDP = log10(step);
int dps = 0;
if (calDP < 0.0)
dps = int( -calDP);
looks like it should correctly calculate the number of decimal places,
but it doesn't. step is of type float, but log10() expects type
double. It seems that a very small rounding error is then screwing up
the cast conversion to type int. The following snippets of code
illustrate the problem:

float num = .001;
printf("-log10(num): %f", -log10(num));
-------> -log10(num): 3.000000 (As expected.)

printf("int(-log10(num)): %d", int(-log10(num)));
-------> int(-log10(num)): 2 (Huh?)

double inte;
double frac = modf(-log10(num), &inte);
printf("integer: %f fraction: %f", inte, frac);
-------> integer: 2.000000 fraction: 1.000000 (What the ...?????)

printf("3.0 - (-log10(num)): %e", 3.0 - (-log10(num)));
-------> 3.0 - (-log10(num)): 2.062788e-08 (Oh.)

After returning to Rotary::mouseDoubleClickEvent
(src/gui/widgets/Rotary.cpp), another problem appears at line 471:

if (m_position < powf(10, -10)) m_position = -10;
is equivalent to writing
if (m_position < .0000000001) m_position = -10;
which is almost like writing
if (m_position <= 0) m_position = -10;

But since m_position is a logarithm of the actual value here, it must
be allowed to take on some reasonable negative value, if it is to
represent some positive, fractional actual value.

if (m_position < -10) m_position = -10;
is probably what was originally meant here.


2012-09-24 07:42:34 Tree
[r13101] by dmmcintyr

Small update as a test commit

2012-09-24 07:33:16 Tree
[r13100] by tedfelix

Comments, variable renaming, code shuffling.

2012-09-24 04:09:22 Tree
[r13099] by bownie


2012-09-16 17:34:52 Tree
[r13098] by bownie

Updated to reflect new repository.

2012-09-16 17:32:28 Tree
[r13097] by tehom

Factored away FigParamsForRegion

2012-09-15 17:27:54 Tree
[r13096] by tehom

Refactored and rearranged classes. 6 new files.

2012-09-15 17:27:39 Tree
[r13095] by tehom

Factored two methods into TargetSet

2012-09-15 17:27:16 Tree
[r13094] by tehom

Moved TargetSet into UpdateFigurationCommand

2012-09-15 17:27:04 Tree
Older >