Re: [yoshimi-user] Contollers bug
- From: Rob Couto <dbtx11@xxxxxxxxx>
- To: Will Godfrey <willgodfrey@xxxxxxxxxxxxxxx>
- Date: Sun, 15 Jun 2014 10:49:55 -0400
On 6/15/14, Will Godfrey <willgodfrey@xxxxxxxxxxxxxxx> wrote:
On Sun, 15 Jun 2014 02:09:06 +0000
Jonathan E Brickman <jeb@xxxxxxxxxxxxxxxx> wrote:
I don't actually do much with routing at this time, so I don't want to
claim to test effectively, but I did find one additional. I tried
clicking the "Controllers" button on the default window, and it caused
Yoshimi to eat most of the CPU and cause xruns untill killed. What does
this button do? I made sure (on the second try) that I had a MIDI
input/controller device running and connected via Jack.
Unfortunately you've hit on a *very* obscure bug I've been trying to track
down
for a while. I kept quiet because nobody else had seemed to have hit it.
The controllers window enables/disables and sets the various controllers
for
each individual part, and this bug *only* affects the window for the first
part
(part 1).
What makes this stranger is that it also depends on the size of Yoshimi's
config file. I have a saved file here that repeatably causes this bug to
surface, and another file that never does.
All of this suggests it's some kind of buffer overrun situation.
This bug does not appear in V 1.0 but does appear in V 1.1, and tracing
back
through the master branch it first appears at the time multiple part output
was
introduced. I don't know if that was the cause, or if it simply exposed a
hitherto dormant problem.
I'm not absolutely sure if it's related but I have a similar stall
condition which happens on any part-- the controllers window takes
several seconds to draw when first being created and to redraw when
(for example) switching back to the workspace where it sits. When it
finally does finish drawing, the PanDpth knob's blue soft-edged
partial circle is a solid gritty complete circle. I profiled and found
it's spending a lot of time in cairo (which draws the nicer knobs) so
here's what I believe happens: PanDpth is defaulting to something
absurd and the knob drawer is furnishing cairo with an absurdly high
angle for the end-point of the blue region. When I click on the knob
without dragging from its default position (east-northeast) it snaps
to 100% (southeast) and redraws instantly, and the tooltip says
6.24e+06 or 2.02e+09 confirming a problem in the default for that
parameter or the way fltk derives from it.
I had a look and fortunately, it's even simpler: in Controller.cpp,
panning.depth isn't mentioned in Controller::resetAll(), so the value
is uninitialized unless you have a config or param.xmz that sets it
(so getFromXML() overwrites the random val) and "your mileage may
vary" was never truer. So I just now added
setPanDepth(127);
to resetAll() and it went away quietly. I hope this solves your
problem, too- it would have seemed to be related to the addition of
multiple out ports because the new knob styles went in around the same
time and it's now drawing an arc as well as rotating the knob's
representation.
But then, I see the value is divided by 64 so maybe 127 isn't right,
and it should default to 64, I don't know. But after playing with it
and sending pan messages from the VK, I can't tell what the knob does,
if anything... and the Reset All Controllers button doesn't seem to
affect it, either. Apparently there are more 'fun' things lurking :(
--
Rob
Other related posts: