New LadderFilter class

General JUCE discussion
1

Hello @fabian and @jules !

I just saw a new class on develop called LadderFilter, provided in the DSP module. Nice addition :wink:

A few questions :

  • Is it a good idea to use constexpr as much as possible in the JUCE base code, since it is incompatible with VS2015 ?
  • I see also the use of std::vector and std::array there. Does that mean that we shouldn’t use the JUCE Array class anymore as well in the future ?
  • static_cast<Type> () or Type () ?

Thanks, and see you soon guys at ADC !

1 Like
2

Hi @IvanC,

  • the DSP module requires a C++14 compiler so constexpr should be fine here (unlike in other JUCE modules)
  • std::array is used instead of a raw array, it doesn’t really compete with juce::Array. I personally prefer std::vector to juce::Array because it uses size_t.
  • I know @jules doesn’t like raw casts even for trivial type conversions but he’d probably agree that using static_cast everywhere in this particular class would make it less readable.
2 Likes
3

Hello @zsolt ! So I guess this is class is your work :wink:

  • For the constexpr stuff, I was writing a remark because I saw on the JUCE base code that VS2015 isn’t supposed to handle it correctly. And indeed, in some specific contexts, it doesn’t work as expected. That’s the reason why the GridDemo in the demo JUCE app for example can’t be compiled with VS2015. However, I have been using the DSP module with VS2015 for a while (I use VS2017 now) so I was wondering if something was wrong somewhere. I think that the DSP module shouldn’t be compatible with VS2015 to be consistant everywhere for example

  • OK so that’s a signal to say “stop using juce::Array and use the std variants instead from now” I guess :slight_smile:
  • I’m still writing static_cast everywhere since my days in London :joy: I agree it makes the code less readable in general :wink:
4

Not sure why I’m being blamed here for wanting static_casts! I’ve always gone for old-style casts for really obviously primitive conversions.

5

Any chance of JUCE containers ever moving to size_t so we don’t have to cast all the time?

6

We might add some overloads one day to help with this.

(But using an unsigned index type is apparently something that a lot of C++ gurus nowadays consider to have been a regrettable choice in the standard library)

7

Yeah, I can see losing some functionality due to handy things like using a -1 index as shorthand for “at the end or the container”. Overloads alone would make a huge positive difference.

8

How come? It does seem weird to allow negative indexes, so what are the arguments against?

I can see size_t itself being a slight nuisance because it has varied types, depending on the target platform.

9

in my experience unsigned ints have proven to be quite annoying in math operations when sometimes you just want to e.g. do a simple -1 temporarily as a part of an expression and you end up in positive max for the type, I find using unsigned error prone and requiring special attention.

2 Likes
10

Unsigned’s are slooooow (https://youtu.be/yG1OZ69H_-o?t=2534)
And also a PITA.

Scott Meyers also wrote an article a long time ago why he prefers signed array indices but I can’t seem to find it now.

Of course if you use algorithms for everything then the problem goes away


2 Likes