Assignment of midi knob to buttons doesn't work

[GoogleCodeExporter]

I have tried the assignment of midi knob to buttons.
Amsynth seems to have difficulties to detect which button is moving.
Once a midi button has been affected to an amsynth button, it works for a while 
and then, amsynth starts to freeze (qjackctl load display grows to 99% and then 
jackd disconnect).

I use the latest trunk version of amsynth.

I use amsynth under mandriva 2010.1 32 bits.

For the midi side, I use AKAI LPK 25 for the keyboard and the LPD8 for the 
assignable buttons.

YC

Original issue reported on code.google.com by jean.kan...@gmail.com on 30 Dec 2010 at 9:51

• Merged into: #8

[GoogleCodeExporter]

Maybe the problem happens only if you affect a second knob.
With one button only everything seems to go fine.
But with the second assignment, jackd load starts to rise and then jackd  
disconnect.

Original comment by jean.kan...@gmail.com on 30 Dec 2010 at 1:42

[GoogleCodeExporter]

I've tried assigning multiple MIDI CCs to multiple controls and changing them 
continuously, but have been unable to reproduce the problem.
What exact steps seem to trigger the issue?

It's possible that the excessive CPU usage in this case could be the same as 
issue 8 (reverb denormal issue)

If possible, it would be great if you could use 'sysprof' to find out where all 
the CPU is being used. sysprof may be included in your distribution - 
http://sysprof.com

Original comment by nickdowell on 30 Dec 2010 at 2:23

[GoogleCodeExporter]

I thought that an explanation can be that I used a realtime kernel, but no. The 
problem also happens using a "classic" kernel.
So, I installed sysprof (what a great tool, thanks).
Here is a log where amsynth + qjackctl reach a 73% load.
It's quite hard to perform a load snapshot because all the system started to 
freeze.

Original comment by jean.kan...@gmail.com on 30 Dec 2010 at 8:39

Attachments:

• amsynth_sysprof.log.gz

[GoogleCodeExporter]

Many thanks for running sysprof and sending the results - based on those it 
very much looks like the same cause as issue 8 - denormal processing causing 
high cpu usage, especially in the reverb.

Excerpt from sysprof capture:

[76%] __clone
[74%]   start_thread
[74%]     Jack::JackPosixThread::ThreadHandler(void*)
[74%]       JackOutput::process(unsigned int, void*)
[74%]         VoiceAllocationUnit::Process(float*,float*, unsigned int, int)
[45%]           revmodel::processreplace(float*,float*,float*,long, int, int)
[30%]             comb::process(float)
[13%]           VoiceBoard::ProcessSamplesMix(float*, int, float)
[ 5%]             IIRFilterFirstOrder::processSample(float)
[12%]           Distortion::Process(float*, unsigned int)
[ 2%]           SoftLimiter::Process(float*, float*, unsigned int, int)

Original comment by nickdowell on 30 Dec 2010 at 11:17

• Changed state: Duplicate

[GoogleCodeExporter]

There's now a fix for the denormals issue - svn trunk revision 413

Original comment by nickdowell on 31 Dec 2010 at 11:36

[GoogleCodeExporter]

Issue 2 has been merged into this issue.

Original comment by nickdowell on 31 Dec 2010 at 11:40