User Patch Noise Update

[bfabricius]

Hi @mars and all,

As you know I've been working with the OWL modular for a while now. I really like the concept of the series of programmable devices RT has developed and a I will make sure I can back the ongoing Kickstarter campaign.

One thing I still couldn't figure out though is if there actually was ever a solution to the disturbing noise/artifacts that occur when uploading and running a user patch. I can only get these to go away if I put the OWL into remote control mode.

I would really like to use the OWL in some demo videos in near future but if I have to operate it with OwlControl to make it happen it really kills the fun in it :).

I trust plenty of you guys are using the OWL in live scenarios with your own patches so maybe I'm just missing the point on how to fix it. Numerous attempts trying to with FW v12 and 14 plus resetting and saving to OWL have not fixed the problem. Any help to set this issue aside finally would be appreciated and I apologize if I missed some solution mentioned in any older thread.

Cheers,

[mars]

Thanks @bfabricius!

I think there's been confusion caused largely by the problems some users were having with FW v13 / v14. In essence there was some really extreme noise caused by the firmware, unrelated to the low-level ADC noise that is present on some patches.

For the latter, the solution is to filter the raw parameter values. It would be good to
a) perform smoothing in the framework, rather than making the patch authors do so in each patch
b) implement a consistent method across all types of patches ie Max Gen, Pure data, C++ and FAUST
c) come up with a simple, repeatable metric so that we can compare results and see what works best

for c) it would be great to have a simple patch where the effects of the noise is very audible. Perhaps as simple as a sine wave oscillator with a high resolution frequency parameter. We would also need some way of testing when smoothing has gone too far, e.g. a quickly changing parameter value with no audible zipper noises.

Would appreciate your thoughts on this,

Martin

[bfabricius]

I think there's been confusion caused largely by the problems some users were having with FW v13 / v14. In essence there was some really extreme noise caused by the firmware, unrelated to the low-level ADC noise that is present on some patches.

Ok, this confirms I didnt misunderstand anything. I have experienced both low level noise on factory and user patches and extreme noise on user patches only. I'm currently running FW v14 and I'm experiencing extreme noise on all user patches loaded. Since putting OWL into remote control mode seems to settle things this does lead me to believe it could be something like ADC noise caused by reading potentiometer values but I still don't understand why this is not happening when running factory patches (i can hear ADC noisy like artifacts on some of the factory patches but they are far less prominent than when running user patches). Does this mean all the factory patches have some smoothing built into them already? I haven't tried to check this yet.

For the latter, the solution is to filter the raw parameter values. It would be good to
a) perform smoothing in the framework, rather than making the patch authors do so in each patch
b) implement a consistent method across all types of patches ie Max Gen, Pure data, C++ and FAUST
c) come up with a simple, repeatable metric so that we can compare results and see what works best

for c) it would be great to have a simple patch where the effects of the noise is very audible. Perhaps as simple as a sine wave oscillator with a high resolution frequency parameter. We would also need some way of testing when smoothing has gone too far, e.g. a quickly changing parameter value with no audible zipper noises.

This sounds interesting, we could benchmark a few different algorithms and run them against a patch you described to compare results. I can have a go at something like an exponential filter/exponential moving average if you haven't tried this already. Where in the framework did you have in mind to place this functionality?

Let me know what you think.

Cheers,

[mars]

It used to be that the PatchProcessor kept an array of parameters that was updated at the start of each block with the new values provided by the ADCs. We had a simple IIR filter in place and this worked quite well, at least while we only supported a small number of parameters. With now up to 40 parameters it would no longer be a good model to smooth all parameters, especially since most patches don't use more than 4 or 5.

However it is only the ones tied to analogue values that need to be smoothed. Since we want to support more devices, ie Alchemist, Wizard and Magus, it would make sense to do the smoothing in the device-specific firmware, where we know already what the hardware is.

But to test out algorithms it will be much faster and easier to do so with programs that can be loaded dynamically.

I think it would probably be a good idea to re-introduce basic smoothing for parameters A to E. I can't see that doing any harm in the current situation. I will update OwlProgram to use the same smoothing scheme as back in the day, then we can play around with some different algos.

[mars]

So I meant to say: if you @bfabricius or anyone else wants to submit a test patch that'd be ace! Anything that's relatively uncomplicated and shows up problems with parameter noise or over-smoothing. I think it would be good to have a little collection of patches in Pd, gen~, FAUST and C++ to benchmark against.

[bfabricius]

@mars, ill try building some test patches on the side by just doing what you suggested earlier (high reso parameter on an osc).

I agree in that it would be preferable to keep the smoothing code within the device firmware and not in the path framework and am looking forward to seeing what you can come up with for this.

I have one more question, as a mitigation to my noise problem on user slot patches should i downgrade the firmware for now or are you planning to put the filtering back in this week? i want to use the owl for filming some demos for another project im working on atm.

Ill take closer look at the firmware / owl program code to get a better understanding of the parameter updating. I saw the linear / exponential param updater templates but at first glance these are for scaling a parameters range exponentially and linearly? Im guessing the IIR filter was in the firmware back when you used it?

Cheers and talk soon,
Ben

[mars]

I'll have to recommend to anyone who wants a stable system to use v12 for now. If you downgrade then don't forget to do a Factory Reset and Save to OWL.

There is a template called SmoothValue, with a SmoothFloat specialisation:
https://www.hoxtonowl.com/docs/SmoothValue_8h.html

This will be used if you request a FloatParameter with a non-zero lambda value, specifying you want smoothing:
https://www.hoxtonowl.com/docs/classPatch.html#a8157a3f365cfd5234c87b2135b2d0f77

The idea was to have a really flexible but easy to use C++ API to cover value scaling, offset, smoothing, hysteresis, and linear/exponential skew. You request a FloatParameter which then gets automatically updated each block, and you can use the value as a normal float. In reality though this hasn't seen much use.

[markdibarry]

I've uploaded a youtube video of me trying a few different situations demonstrating the noise the Owl pedal produces. I'm using firmware v14. Hopefully this will help users and provide assistance fixing bugs.

It shows me using a Polytune2 with no input into a Scarlett 6i6 with the preamp cranked to show the noise floor. The highest it reaches is -66 db (RMS). This noise level is the same as many of my other pedals when bypassed. They all show -66 db on their own and when chained together using a Strymon Zuma isolated power supply, the highest they reach is -65 db.

The Owl pedal, when powered using USB brings the noise floor up to -40 db, even when bypassed and input/output gain as low as they can go, for a total of 26 db of added noise.

When powered using an isolated power supply (same one used for the Polytune2) and input/output gain bottomed out, the noise floor lowers to -48 db, for a total of 18 db of added noise.

Throughout this, I turn the remote control on and off, saving it to the Owl with no change to the noise floor, ruling out the knobs' ADC as the culprit. The block size also does not seem to have an effect on the noise floor either.

Changing the sensitivity to High, raises the noise floor to -45 db, bringing the total noise added to 21 db.

I then changed patches to another default patch, and then a user patch. The noise varied around 1 db with these changes.

This determines that the lowest amount of noise in an ideal setting is +21 db, which unfortunately makes it hard to recommend for any practical use outside of experimentation. +21 db imho makes it about 18 db too noisy for recording or practical live use. However, I'm not sure if this is a firmware issue or a hardware one. It's a shame, because I'd kill to be able to use some of these effects on my pedal board.

I've also tried firmware v12 with similar results.

[bfabricius]

@markdibarry thanks for that video, interesting to see the results.

I would also agree (without having run any actual measurements) that on both FW v12 and v14 the factory presets are a bit noisy regardless of the pot ADC value handling.

The user slot patches (FW v14) are a whole different story of noisy though, I am hoping that together with @mars we can work on improving this for the future firmware releases. I have yet to try downgrade to FW v12 again to see if the user slot noise improves.

Cheers,

[markdibarry]

Perhaps it's just my pedal, then, since you can see in the video that I'm using v14 and changing between a preset patch and a user slot patch results in an inaudible difference.

[bfabricius]

Yeah thats what I'm hoping to find out eventually... Ive got the modular so Im not sure if there is any difference due to hardware...

[mars]

@markdibarry do you think there could be a ground loop problem with your setup?
We've measured 90dB SNR with the OWL Pedal in the past, on a very nice Rohde & Schwarz analyser. We are about to revive an old Audio Precision System One which will give us the ability to do more in depth testing here in the workshop. I will try to reproduce your test as closely as possible and report back, probably won't happen this week though.

[markdibarry]

Hey mars. Good question, but if you take a look at the video I posted, that isn't the case. I tested it against all of my other pedals and using three different power supplies, all threw similar results. Each time, the Owl pedal showed 20+ db more noise than a normal true-bypass pedal.

[mars]

I've looked at the video again. It's difficult to draw any conclusions without seeing what the signal level is. If you've got the preamp gain cranked all the way up, a moderate signal will presumably go through the roof?

Can you feed some test signal, like a sine wave, into the device? It would be interesting to see how much you can turn the signal up without clipping, set that as your zero reference, then see what the noise floor is relative to that.

[markdibarry]

That's a great idea. That should give a more accurate assessment.

I just tested it and I ran a sine wave through as loud as I could without clipping the preamp, then turned the sine wave down.

TC Polytune 2

bypassed: -79 db

Owl

off, bypassed: -79 db
on, user patch, no effect (in->out): -65 db
on, user patch, gate cutting input: -68 db
on, user patch, pitch effect: -60 db
on, preset patch, phaser: -62 db
on, preset patch, jotReverb: -60 db

[mars]

Thanks for that Mark. They're not great numbers, 60dB SNR is pretty poor. Let me see if I can put a test together here for comparison.

[markdibarry]

Thanks! Let me know what you find out. I'd be excited to use the Owl with my main setup.

[sinewave440hz]

Hi...I've been trying to get the Cloud Delay and Granular Delay patches in the online library to work without the extreme noise issues. I noticed that in v10, activating remote control gives me a clean and usable Cloud Delay patch. I then hopped back to v14 and tried activating remote control, but no joy there. I haven't done all the versions in between yet, but I did re-read this thread and it sounded like Ben was using the remote control workaround successfully on v14 - is that correct @bfabricius? If so, I have follow-up questions

[bfabricius]

oticed that in v10, activating remote control gives me a clean and usable Cloud Delay patch. I then hopped back to v14 and tried activating remote control, but no joy there. I haven't done all the versions in between yet, but I did re-read this thread and it sounded like Ben was using the remote control workaround successfully on v14 - is that correct

Hey @sinewave440hz, first of all I'm glad that I'm not the only one having to deal with the remote control fix for the noise on user slots .

So, yes I currently run v14 fw and manage to suppress noise by activating remote control in owlcontrol. It's a while ago, but i think i switched back and forth between v12 and v14 a few times and the remote control hack worked. you might have to make sure you actually reset and save to owl after the fw upgrade for it to work. i think @mars mentioned the exact order somewhere here in the thread.

im still planning to look into this issue a bit in the firmware, just havent had time yet. maybe downgrading to v10 will help... id love a quick workaround so i can actually use the owl for demos withou remote control.

cheers,