Q Light Controller+

Here's what he said when he pointed me to his code yesterday (I had kept the laptop and quassel chat window open to catch any messages while at work, he lives n Australia so it's a bit difficult to find a time of day to talk live during my working week):

<damo22> edo_lap: i pushed a fix that is slightly better in terms of what the bars are doing, but its still broken
<damo22> as in theres something underlying about the bar graph that i dont understand such as its scaling or how to plot it correctly
<damo22> it seems to be computing a lot of bars redundantly, but every time i try to simplify it, it breaks
<damo22> edo_lap: https://github.com/zamaudio/qlcplus is my fork with the patch

Earlier today damo22 and I met on IRC and worked on this again and I think (after testing a while) with today's changes the issue is resolved from a user's point of view.

Bar levels look ok now for mono and stereo sources (tested with jack in linux), and the triggers do what I expect them to do.

I would be interested in testing this on MAC OSX.

I did some testing awhile a back (changed the pwrSum variable to 10*pwrsum to get decent levels on my mac) with some 'pure' sine waves as audio sources to see whether the fourier transform was working correctly and got very mixed results.

I would like to do the same test with your code changes.

I am not great navigating GITHUB. If you don't mind, can you point me in the direction of the code? I think I can mange the compiling part.

Cheers
Mark

Here are some possibilities how to get the patch:

1. Clone damo's fork https://github.com/zamaudio/qlcplus/tree/master to a new directory, checkout his working branch fix-fft and compile as usual.
This way you'll end up with a second code tree, probably not what you want...

So you may prefer

2. Update your working copy, download and apply the diff I've appended to this post, like this:
This should give you just damo's changes on top of your working copy,

HTH

EDIT: 11:45 CEST, I just replaced the diff with the latest version from a few minutes ago

damo continues working on it in this moment, he's not happy yet, somehow he cannot find out how the audio channel data is interleaved if stereo... I cannot help him there, but in the meantime have made a short screencast to show the current state, I've added a jaaa window with similar frequency range to compare:

https://www.dropbox.com/s/5zuukcy5e6so7 ... .webm?dl=0

EDIT: 12:02 CEST, I also replaced the screencast link above to show the most current version of the patch
With this latest change this should be ready for merging, damo thinks the fix is complete now, and renamed the PR accordingly.

I attach the corresponding workspace so you can see what mode and channels I used on which bands...

Thanks for the info.

I have compiled a versions for MACOSX and it seems to be working.

I will do a bit more testing tomorrow when I can find a quiet space.

mlohrey:

Please see updated patch.

I found a bug in my changes and fixed it.
What you were testing was severely rounded to a coarse limit due to integer rounding.

This should be much better and applies to the latest master branch:

https://patch-diff.githubusercontent.co ... /1212.diff

Damien

HI Damien,

Thanks for the that.

It looks to be working really effectively. Levels are great and easy to adjust.

I generated a number of pure sine waves over a range of frequencies and the widget set to the 32 divisions (the max number of bars apparently). It was really accurate.

Now to try it with some lights!

Cheers

Mark

This would need a tone function generator coupled to the line input and do a sine sweep over 40Hz to 5kHz.
This should be seen reflected in the different bars. The bars should overlap, but not that much (depending to the frequency on the input, the signal should overlap 2 bars or stay within 1 bar (bandwidth of 1 bar).

Now if the sine tone changes to triangle, the fluent going from one bar to another, should be very abrupt now. (Harmonics induced by the triangle signal).
Last test: pink-noise -> now all bars should react, showing the same level over all the bars. (Differences will show the quality of your AD-converter inside your computer)

I'm willing to test with the new source code.
If working this would mean a long-standing problem with QLC+ is solved. Cheers to that.

Damien tested with a sine sweep, and so did I.

I even made an updated screencast using the latest version of the patch, but forgot to post it here, although it's using only 10 bars. I've tried with 32 bars too, and it shows just what you expect, a much smaller level in the neighbouring bands in the lower frequency area, for higher frequencies single bars.

The sine sweep comes from an LV2 plugin by Robin Gareus/x42, it has a few fixed test signal presets, and the sweep cannot be adjusted to stop at 5kHz, so the last part of the sweep just does nothing in the widget, obviously.

I put it on YT and embed it here (instead of linking to my dropbox like before...)



I've also tested with different music and it surely reacts very precisely to frequency content as far as I can tell.