User Patch Noise Update

#6

@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

#7

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.

1 Like
#8

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.

#9

@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,

#10

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.

#11

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…

#12

@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.

#13

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.

#14

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.

#15

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

#16

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.

1 Like
#17

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

1 Like
#18

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 :wink:

#19

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,

#20

Thanks very much for your answer there @bfabricius. I had been omitting the reset and save process and managed to get Cloud Delay (for example) working in v12 when I did that. Not v14 though, so I’m staying on v12 for now. In fact, I will mostly stay in PD while developing my patches. As far as the firmware goes, I hope you have time to examine it. I would certainly love to get to the stage of being able to assist in firmware maintenance, but like everyone it seems I have a million other projects going on, so we’ll see. Keep me posted, maybe you’ll inspire me to get going…

1 Like
#21

Just to add another voice to the chorus, because sometimes this matters :slight_smile:
I’m on v12, I’ve been working with different power supplies all week hoping there was one that would reduce the noise enough for me to use the OWL onstage this weekend, because I’d kind of (eh, stupidly) built an arrangement around it. I bought an Ojai (before reading this thread, which amazingly works sometimes) as a last resort, and it’s absolutely no different, this +15-20db F# whine. So today I’m going to buy some cheap shimmer verb to use instead, point being that it remains a bummer it’s not stage-ready.

1 Like
#22

Hi @mars,

bumping this thread since ive looked into OwlWare a bit recently. A friend of mine builds eurorack modules and he has produced a general purpose (programmable) module (small batch, hand assembled) and he doesnt really know what to do with it now. It’s pretty much the same target architecture that the Owl Modular has, with a few minor differences. I’m thinking we might be able to get OwlWare to run on it.

While i was diving into the FW code, I actually remembered this noise issue I am experiencing with my Owl Modular. I was interested why the noise goes away when i run the Owl in remote control mode with OwlControl.

Just to confirm, I can see you are doing this when in remote control

which explains that the paramter values are not taken from the ADC but replaced by the ones transferred via midi cc from OwlControl. Is that right? I havent checked this yet, but Im assuming the OwlControl sensitivity defines the parameter smoothing in OwlControl. At least its more noisy when i have it running at Low than at High sensitivity.

If it is, then I can see that if not in remote control mode you take the parameter values from ADC and smooth them in the leaky integrator in PatchProcessor of OwlWare:

Again Im running an old v14 fw build and i can actually see the parameter values jumping around in OwlControl when not in remote control. This could explain the prominent noise when running a majority of patches (e.g. Bank A / Overdrive ). Im wondering what would happen if i build OwlWare for OWLMODULAR from head in master (since the leaky integrator code is definitively active there). Hopefully that will solve the mystery of the noisy parameters :slight_smile:

Thanks for the help ( I know you probably have other things to do regarding OpenWare but this little experiment is a nice way to get into OwlWare ).

Cheers,
Ben

1 Like
#23

Hi Ben, sorry for late reply!

Yes the smoothing was removed in a code revision, the reasoning was that a new parameter handling method in the patch code would take care of it instead. But this has not turned out as planned: some newer patches use the new FloatParameter constructs (with smoothing) while all older patches and many newer ones still don’t.

Also in hindsight it makes more sense for the device-specific firmware to smooth the parameters it knows comes from the ADC, rather than for the device-agnostic patch to do so.

1 Like
#24

Note by the way that the PatchProcessor in OwlWare only processes the parameters for the statically compiled factory patches. Dynamic patches have their own PatchProcessor in the OwlProgram repo.

1 Like
#25

Not a problem :slight_smile:

Im actually not quite sure what fw version i was using on my OWL modular last, but I traced the noise down to most probably being ADC control values that werent smoothed causing it since when control was delegated to midi the noise disappeared. Could be the filter was not working or that I tried a newer firmware without smoothing and old patches that didnt use FloatParam.