How much LookupTable is too much?


I’m intending to make a 2d lookup table, which would be similar to a single LookupTable of length (250 * 100 = 25000). I only ever need to make i once.

Would a LookupTable of length 25000 be absurd? If not, what are the boundaries of absurdity?


You can make it as big as you want, but the CPU cache limits are going to hit at some point, making the look-ups less efficient.


Neat. Thank you.


In general your lookup table length should be based on your error tolerance (or aliasing, in the case of a wavetable). It depends on what’s in the table.


Slightly different question, but a bit similar. I’m trying to create a static array of LookupTables, but the NON_COPYABLE bit is making it really hard. How can I do this?


You can should be able to use the LookupTableTransform<>::initialise() method with the same arguments instead of copy-assignment

Also should note that the array of tables itself isn’t static there, just the function is. If you want a static array that’s only generated once and you can do:

LookupTableTransform<float>* generate_data() {
    const int steps = 100;
    static LookupTableTransform<float> tables[steps];

    if (!tables[0].isInitialised()) {
        for (int s = 0; s < steps; ++s) {

   return tables;


Makes perfect sense. Thank you.

     for (int c = 0; c < steps; ++c) {
        double curveConstant = curveMap(abs(c/100.0));
        if (c < 100) {
          curveConstant = 1/curveConstant;
          [] (float x) {
            // error: curveConstant does not exist in this context
            return 1 - pow(1 - x, curveConstant);
          0.0f, 1.0f, 250

It would appear I’ve been spoiled by JS. Is anything like this possible in c++? And if not, how do people go about creating arrays of things which take lamba functions as arguments?


lol. No friggin way. I just started trying things at random, and it worked.

          [curveConstant] (float x) {
            return 1 - pow(1 - x, curveConstant);
          0.0f, 1.0f, 250


Nice! The [] in C++ lambdas is what’s referred to as the capture group. It can grab local variables by copy or reference:

float curveConstant = ...;

// Captures by copy implicitly since curveConstant is used in the lambda body
[=](float x) {
    return 1.0f - powf(1.0f - x, curveConstant);

// Captures by copy explicitly 
[curveConstant](float x) {
    return 1.0f - powf(1.0f - x, curveConstant);

// Captures by reference implicitly since curveConstant is used in the lambda body
[&](float x) {
    return 1.0f - powf(1.0f - x, curveConstant);

// Captures by reference explicitly
[&curveConstant](float x) {
    return 1.0f - powf(1.0f - x, curveConstant);


Would the reference versions be dangerous if initialize (for some reason) were to call the lamba function asynchronously? I’m thinking the context of the outer function would be over, so it would clean up all its local variables.


They are!

Usually I save reference capturing for non-primitive types that are either large, non-copyable, or need to be updated/called by the lambda itself. When using reference capturing you want to make sure the lambda’s “lifespan” is not longer than what it’s referencing.

If I need them I’ll use references in lambdas that are owned by an object, such as the juce::Slider::onValueChange lambda which (in my code) is only ever evoked by the slider that owns it. The same applies if you were to copy-capture the slider’s this pointer, as long as the slider is the only thing using the lambda then this will be known to always be valid


I’m having a similar problem as the one before.

I just can’t seem to wrap my head around how to initialize static members, or how to tell a context “please don’t delete or copy this thing”.


If you need to do some kind of a Component factory function, allocate the needed Component on the heap and return a pointer or smart pointer to it. What is it that you are actually trying to do, though?


Pretty much something like this:


I couldn’t find a better place to store colors.


OK, sorry, I have no idea what you are trying to do, then.


Create a component that has setColour called for a bunch of ids, then use that components copyAllExplicitColours function to copy them over to specific other components.


If you literally just need to store colors, use a suitable container class. How do you need to access the colors?


You should note that the Component color ids are not even necessarily compatible between different Component types.


I just need a quick way to copy them over to other components with copyAllExplicitColours()

I suppose I could just make a function that takes a component and modifies it though… yeah, that’s a better way.

I keep trying to think of colors as a struct, but they are not.