Maximum number of variables?

General JUCE discussion
1

Does anyone know the maximum number of double variables that can be used effectively? I was hoping to not use merging arrays (but isn’t a big deal if necessary), I have created a GUI for custom oscillator wavetable. Where I am using an array of double variables.

However, when creating the array with 512 double variables the program is not working effectively. My professor had said this would never be an issue of overpowering, but am going to test with 256 points instead. Just very interested if there’s a general rule.

2

We cannot answer your question with so little context. 512 double variables is a super tiny number, considering that a DAW (such as Cubase, Live or Logic) has to deal with dozens (sometimes hundreds) of tracks, containing hundreds of clips, containing thousands of MIDI notes and automation points.

What exactly are you doing? On which platform?

1 Like
3

What is a “merging array”?

4

Here is a short snippet, it’s in the works. I was having trouble with the actual wavetable it wasn’t updating quick enough I assumed because of too many variables. So, I am going to try again with 256 point wavetable instead. Uhh, if you look up merging array’s in c++ you can combine sorted arrays, etc.

40%20AM
Screen Shot 2019-01-31 at 5.18.40 AM.png2000×1410 127 KB

5

512 doubles is a very small amount of data, unless you have some algorithm that slows down very quickly as the number of data elements increases. You are speaking of plain floating point variables in an array, right? And not 512 plugin parameters or something…? (There have been reports JUCE does slow down with large numbers of plugin parameters especially in debug builds.)

6

Ahh, okay thanks. It must be due to using in the array, the oscillator was still playing just didn’t seem right.

7

Without seeing any code, it is difficult to say what the issue is. Generally speaking, an ‘array’ should not effect your performance, unless, as others have pointed out, your algorithm itself is effected by the number of elements being processed. I don’t think the issue has been looked at enough for you to draw the conclusion ‘must be due to using the array’.

8

double oscillatorBuffer[514] =
{
a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, a1, b1, c1,
d1, e1, f1, g1, h1, i1, j1, k1, l1, m1, n1, o1, p1, q1, r1, s1, t1, u1, v1, w1, x1, y1, z1, a2, b2, c2, d2, e2,
f2, g2, h2, i2, j2, k2, l2, m2, n2, o2, p2, q2, r2, s2, t2, u2, v2, w2, x2, y2, z2, a3, b3, c3, d3, e3, f3, g3,
h3, i3, j3, k3, l3, m3, n3, o3, p3, q3, r3, s3, t3, u3, v3, w3, x3, y3, z3, a4, b4, c4, d4, e4, f4, g4,
h4, i4, j4, k4, l4, m4, n4, o4, p4, q4, r4, s4, t4, u4, v4, w4, x4, y4, z4, a5, b5, c5, d5, e5,
f5, g5, h5, i5, j5, k5, l5, m5, n5, o5, p5, q5, r5, s5, t5, u5, v5, w5, x5, y5, z5, a6, b6, c6,
d6, e6, f6, g6, h6, i6, j6, k6, l6, m6, n6, o6, p6, q6, r6, s6, t6, u6, v6, w6, x6, y6, z6, a7,
b7, c7, d7, e7, f7, g7, h7, i7, j7, k7, l7, m7, n7, o7, p7, q7, r7, s7, t7, u7, v7, w7, x7, y7,
z7, a8, b8, c8, d8, e8, f8, g8, h8, i8, j8, k8, l8, m8, n8, o8, p8, q8, r8, s8, t8, u8, v8, w8,
x8, y8, z8, a9, b9, c9, d9, e9, f9, g9, h9, i9, j9, k9, l9, m9, n9, o9, p9, q9, r9, s9, t9, u9,
v9, w9, x9, y9, z9, a10, b10, c10, d10, e10, f10, g10, h10, i10, j10, k10, l10, m10, n10, o10, p10, q10, r10, s10,
t10, u10, v10, w10, x10, y10, z10, a11, b11, c11, d11, e11, f11, g11, h11, i11, j11, k11, l11, m11, n11, o11, p11, q11,
r11, s11, t11, u11, v11, w11, x11, y11, z11, a12, b12, c12, d12, e12, f12, g12, h12, i12, j12, k12, l12, m12, n12, o12,
p12, q12, r12, s12, t12, u12, v12, w12, x12, y12, z12, a13, b13, c13, d13, e13, f13, g13, h13, i13, j13, k13, l13, m13,
n13, o13, p13, q13, r13, s13, t13, u13, v13, w13, x13, y13, z13, a14, b14, c14, d14, e14, f14, g14, h14, i14, j14, k14,
l14, m14, n14, o14, p14, q14, r14, s14, t14, u14, v14, w14, x14, y14, z14, a15, b15, c15, d15, e15, f15, g15, h15, i15,
j15, k15, l15, m15, n15, o15, p15, q15, r15, s15, t15, u15, v15, w15, x15, y15, z15, a16, b16, c16, d16, e16, f16, g16,
h16, i16, j16, k16, l16, m16, n16, o16, p16, q16, r16, s16, t16, u16, v16, w16, x16, y16, z16, a17, b17, c17, d17, e17,
f17, g17, h17, i17, j17, k17, l17, m17, n17, o17, p17, q17, r17, s17, t17, u17, v17, w17, x17, y17, z17, a18, b18, c18,
d18, e18, f18, g18, h18, i18, j18, k18, l18, m18, n18, o18, p18, q18, r18, s18, t18, u18, v18, w18, x18, y18, z18, a19,
b19, c19, d19, e19, f19, g19, h19, i19, j19, k19, l19, m19, n19, o19, p19, q19, r19, s19, t19
};

9

The assignment isn’t all of the code. Where does this assignment happen? Why are there so many variables to begin with? Would it make more sense to store all of that data in an array to begin with? ie. the code that currently stores a value in a, would instead store the value in oscillatorBuffer[0] directly? or if you want to keep oscillatorBuffer separate from the code that updates a/etc, store the values in another array, that you just copy into the oscillatorBuffer, ie. a simple memcpy type operation, instead of a bunch of individual assignments.

10

That looks quite weird, where are the letters (I am assuming those are variable names) coming from…? Where is that code happening?

11

You know, everything will be changed changed based on grid size. I am writing 1 x 1 to 16 x 16, which can be adjusted in any variation. I thought merging arrays at first but I feel there is more control by proceeding in this direction. I created boolean for every box, so if this box == true do this. I just re-wrote and as of now it seems I am not having an issue.

When creating the statements for the variables I was having issues when I originally attempted, the values were not working properly but would compile and run… was very odd.

12

C++ allows you to do all kinds of mistakes where the code will compile and run, just with wrong results. You should keep compiler warnings pretty high and pay note to the warnings. Also you should run your code initially often under the debugger to catch various errors.

1 Like
13

Those will be points throughout the period of the waveform, nothing complicated.

14

Still, having that many individual variables, that are related, and represent the same kind of thing ‘points in the waveform’, is ‘less good engineering’. I would recommend that you use an array to store the values. Which also allows you to more easily change the number of elements, without having to introduce another variable, and remember to extend this huge assignment statement.

1 Like
15

This was very convenient! I could use the actual values instead, I saw greater control in this kind of technique. This is a whole other idea though, sinewave only.

34%20PM
Screen Shot 2019-01-31 at 12.33.34 PM.png1588×624 83 KB

16

This code might be easier to maintain. You can easily change the number of points, and won’t introduce any typos in the long run. For example, your xInc is using 512, but you are creating 514 points, is that intentional?

const auto NumPoints = 514;
const auto xInc = (2.0 * double_Pi) / (double)NumPoints;
double sineBuffer[NumPoints];
for (auto pointIndex = 0; pointIndex < NumPoints; ++pointIndex)
    sineBuffer[i] = sin(pointIndex * xInc);
4 Likes
17

May I draw your attention to the dsp::LookupTable? :slight_smile:

6 Likes
18

Thanks Daniel! I was just writing a follow up example using a lambda. lol

1 Like
19

I had forgotten but I very much remember so, the issue was with creating conditional statements for the variables. The compiler will ignore the conditions, but will run effectively with the variables and ignore the conditions.

As arrays can not be used in conjunction with conditional statements, this leave me to use input variables to perform the desired task. I had created several mini programs, where this should be working.

I am going to attempt splitting by columns, would just be real nice if it wasn’t necessary. Though, is probably a better approach anyway.

20

Um, what?? Can you share what code made you think that to be the case?