Full bandwidth filters

#1

I've noticed that there are a few requests for filter that go higher than 12kHz. Looking at the built in biquads that reside in the firmware, they seem to limit fc to nyquist/2. I'm not sure why this is. They do sound a bit muffled at full opening.

We could go ahead an make community objects for full bandwidth filters, but that would instantiate the biquad code once per filter, taking chunks out of that fast SRAM.

I just made a test, cloning axoloti-factory/filter/vcf3, and upping the frequency limit to nyquist. It seems to work fine. There is a test case here: https://github.com/Gassolini/axotest/tree/master/objects/filter . That folder contains the cloned vcf3 filter with a modified copy of the f_filter_biquad_A() from axoloti_filters.c, some outlets to watch the filter frequency and the pitch parameter using frac32.u.map.freq to display the hopefully correct frequency (is that mapping a little bit off, topping out at above nyquist). There's a test patch in there for comparing the original vcf3 and vcf3_full_bw. Even these old and battered ears hear and appreciate the bandwidth extension :smile:

I'm wondering if there are any plans to address this in the firmware, or whether we (the community) should just go ahead and add full bandwidth filters to axoloti-contrib?

Building a 24 dB filter with 6dB LP filter
Juno6 emulation
Full frequency filters
#2

i had a little go with this, and monitored the frequencies in Logic Pro, and I didn't think it made much difference really...

sure theres a little boost at 20khz, but given the both versions of the filter, are pretty muted at the 15 mark, when fully open....I can't see that buys much... but perhaps, my changes were incomplete (you just removed the cap, no?)

I kind of assume its the character of this filter, and something to do with the co-efficients, but I dont know, perhaps the limit is there due to this, rather than strictly being about nyquist.

I'll admit, I was lazy, as I didn't want to start downloading from your github etc... not enough time in life, and due to the amount of tests i run... its not practical, too easy to leave a stray object around, that gives me issues later :wink:

why don't you either chuck it in the community lib, as a test (I can delete it later if you wish)... or alternative create it as an embedded object, then you can simply link to a demo patch here.
(both mean a one click try out for others :smile:

it would also be interesting to see then how you tested it... Id suggest running it though to something that can do a frequency analysis. (mosts daws, or max... probably even pd)

I will say, Id prefer we didn't have limits/guards unless absolutely necessary (= ears bursting, speakers exploding, code crashing) ... i.e. if it doesn't sounds nice, then just dial it back a bit... but sometimes musically, you might want the unintended.

#3

Have just tested them. Sound a lot more open that the factory objects. There is a pretty big difference.

I would love non band limitied filters, but substituting the old bandwidth limit I dont think is good idea. Maybe add them instead. I think many all ready using the old one, so changing them entirely would change the way a lot of patches sound.

Anyway, super work Are :wink: I would love non bandlimited version of all the filters :wink:

#4

I just moved the cap to nyquist instead of nyquist/2. As Jaffa confirms it makes a big difference, not subtle - after all there's a full octave more bandwidth (Edit: yes, at best we get to hear half of that octave, and in my case, topping out at 16kHz on a good day, I get a fraction of an octave - but that's actually quite a bit in subjective terms).

The biquad filters use the well known rbj coockbook coefficients, so I don't think there's anything special going on.

I tested vcf3 and vcf3_full_bw side by side in the mentioned test patch. There are FFTs showing the difference, but much more important, my ears tell me what I need to know :smile: I could throw together a test with en external spectrum analyser, perhaps later.

I'm slightly reluctant to add a series of biquad filter objects since they'd pull in the biquad code for each instance, but perhaps this is how we'll have to do it(?) I'd like to hear Johannes and/or your thoughts on that, as in putting full bandwidth versions in the firmware at some point. Axoloti deserves it! :stuck_out_tongue:

I've done as you suggested; made an embedded object of the hacked filter and put in axoloti-contrib/patches/drj/vcf3_full_bw_test.axp for all Axolotians to audition (just sync the libs to get it installed locally).

#5

This test patch with a muxer shows the difference pretty well:
vcf3_full_bw_test.axp (3.8 KB)

#6

Thanks for finding/lifting this limit, I don't think it was intentional.
Yes, code size explosion was the reason to include these filter functions in firmware.

Now the harder part is object migration, I think it is best practice to not impose such changes on existing patches as that will potentially alter the sound of some patches. Arguably in a good way, but the decision should be made by the patch creator.

Object migration is an unsolved problem in Axoloti. But let's start with coexistence. I'd be happy to take a pull request to add your improved filter functions to firmware but let's not replace the old ones, give the new ones a slightly different name.

#7

FB VCF? (fB= full bandwidth) just a name suggestion for the new filter objects

#8

The only biquad functions called by axeloti-factory and axeloti-contrib object seems to be :
init_filter_biquad_A()
f_filter_biquad_A()

There are also _S versions, but these are never called from anywhere that I can find. I haven't studied the code enough to know why they're there (cuold they be removed to save some space, as in commented out until needed?) :
init_filter_biquad_S()
f_filter_biquad_S()

I agree that the old versions should be kept so old patches don't suddenly sound different. They're also valid in the sense that many old synths have a limited bandwidth, so for emulation purposes they're good to have.

How about making the current filter a wrapper for the full bandwidth version. The wrapper would do the nyquist/2 clamping on W0 and then call the full bandwidth version. This would save some code space and ensure that the body of the filter only exist in one place to aid ingerity. The drawback is a few added cycles for the old version. Something like:

firmware/axoloti_filters.c :

// The current version,  limits the normalized frequency to nyquist/2
void f_filter_biquad_A( ... uint32_t filter_W0 ... )
{
  if (filter_W0 > (INT32_MAX / 4))
    filter_W0 = INT32_MAX / 4;

  f_filter_biquad_A_fbw( ... filter_W0 ... );
}

// The full bandwidth version, with an "_fbw" suffix, limits the normalized frequency to nyquist
void f_filter_biquad_A_fbw( ... uint32_t filter_W0 ... )
{
  if (filter_W0 > (INT32_MAX / 2))
    filter_W0 = INT32_MAX / 2;

  ... rest of f_filter_biquad_A code ...
}

Edit: I found there are also some filters in firmware/axoloti_filters.h which would need the same treatment for consistency:
biquad_lp_coefs()
biquad_bp_coefs()
biquad_hp_coefs()

I'm not too familiar with github (I come from Subversion and Perforce), so I'm worried about making a mess there... I'd happily add the .axo objects to the community library though.

@Quincas: that sounds reasonable.

#9

please let US know how they are Coming a long. Would be super Nice to have at least one of each filtertypes low pass, band pass, band notch, hi pass.

Maybe a Full bandwith version of The regular filters. (LP m, BP m, HP m) ... and also maybe a version of The multimode vcf filter in Full range 😄

Anyway, just thinking loud here 😷 Thanks for looking into This.

#10

@DrJustice / @johannes

@DrJustice - got the feeling you were a little uncomfatble with the 'git process involve', would you like me to do this? I don't mind, as its probably only half an hour including testing etc, and I obviously already have the 'environment' etc to do it... would do this evening?

@johannes ... I agree with @DrJustice, can I remove/comment out the _S variants, also there is a another variation on this in axoloti-factory/objects/filters/filter.h again, unused... can i delete this too.
(an obvious 'reminder' this is all versioned controlled, so deleted stuff can always be recovered :wink: )
... Id like to tidy this up at the same time/this evening

p.s. this would all be done in the dev branch, so for 1.0.10, to ensure no breaks

@jaffasplaffa please do not push, you already made your request... if you are not wiiling/able to do the work, then you have to wait till others have time/inclination to do it.

#11

Well, the fork/merge is another shiny red button that's tempting to press... :smile: However, this close to 1.0.10, it may be better if I learn git in a sandbox rather than on a live project. I'm not sure how close 1.0.10 is though - could be enough time for a little messing about(?)

If you do it, would you do all 4 variants with wrappers as suggested? If so, I could do my share of the work by making the new variants of the filter objects once 1.0.10 is released (just simple cloning + changing the biquad calls to the _fbw variants).

#12

X Technobear sometimes you are a douche bag. Like really rude. And sometimes you are cool. This is not one of your cool moments. My Best suggestion to you is:

Take a break if you cant answer people in a nice fashion.!!!!!!!!!

I was not asking you cause i know most of The times you give rude answer. My suggestions was aimed at dr justice, who is really kind person.

So generally @thetechnobear when I post something here it is not aimed at you, cause I am tired of your arrogance. You are wrong a lot of times and that comes more and more clear to me the more I learn about it myself. So please just don't answer my posts cause they are really not aimed at you.

Dr justice: keep up the good work 👍 Your helpfulness and your spirit is greatly needed in this forum.

#13

1.0.10 wont be in the next few days...
if your comfortable to do it, thats cool - as you'll be familiar with the process for the future.
was just an offer, you can also shout, if you run into anything unexpected.

#14

@jaffasplaffa you are the one being rude. @thetechnobear has been extremely helpful and generous both on the forum, and in development, and gets all my respect! Suggesting him to take a break, is so wrong.

#15

I dont care what you think. Both of you are off sometimes. And lately technobear have been giving weird answers to. If someone is wrong, just correct it without all the fuzz talk that is often presented here in this community, also from you, Johannes. I can post some pretty grim answers from you from my inbox if you want to see them again? And I know a few others who had the same feeling with asnwers from you guys.

Both of you are also wrong sometimes.

Ban me if you want. I dont care.

#16

Since I received my 2 axos and started reading on this forum I've detected a couple of things:

  • There are (at least) three very distinct user types operating on this forum: performers, builders and devs. Not saying they are in any way exclusive, but they definitely operate from very distinct viewpoints, using different vocabularies, different priorities and different definitions of progress. Much of the friction I've seen so far seems to come from the fact that we all tackle the same topics, but often operate on different wavelengths.

  • Secondly - we type in English, but I'll brave a guess and say less than half of us are native speakers. Therefore, there'll be a lot of collisions of invisible expectations about tone etc, that make things more dramatic than they might have to be.

I've found a few answers to questions/suggestions by certain builders/devs a bit more impatient and uneducational than I would have hoped, but it's not hard to imagine where that would potentially come from, and I feel the tone is generally humble and forward-looking.

Let's just be aware of the huge user-diversity of this community and perhaps challenge ourselves to be extra careful when dealing with users from another background than our own. We need all flavours of freaks to evolve the Axoloti out into hyperspace.

Just my 2 cents,
S

P.S Sorry for this off-topic remark. I would also like to give a huge thumbs up to @DrJustice for these filter redefs. In brief qualitative testing I can definitely hear a difference.

Building a 24 dB filter with 6dB LP filter
#17