comparing arrays in ruby (problem)

[tulamide]

tulamide,

By getting index of a certain value (that meets specific criteria), you can easily build a matrix of reference indexes, and then you can get various different kind of values (correlated but from different pools) at thexe indexes. So this is more generalized and scalable approach.

By getting individual values through (more complex?) computation, it's less efficient, and you need to approach each value independently.

In case of this simple equal-loudness autogain compensator - getting single index, gives you a matrix of 4 idenxes, that operate on 2 correlated tables.

As for efficiency, there is no problem if the input value just changes into something else, but the issue get's more pronounced if the input changes live at some speed (each step = full computation), and blue scenery is extensively active.

*

As for second part of your question, look inside the interpolator.

Input - bottom_neighbour / top_neighbour - bottom_neighbour = output - bottom_neighbour2 / top_neighbour2 - bottom_neighbour2

So the output follows the input curve, and the curve doesn't need to have equally spreaded points in this case.

Reference table is always present, array of values to compare too, because it's hardwired.

Yes, if the goal is to access several arrays based on an index, it is mandatory to evaluate an index. Context would have been nice, when asking the question, because I certainly had offered the second solution first then.
Using this while running live input reference might be a little too much ffor green and Ruby. Have you considered the DSP editor? As far as I know, it allows creating arrays, so that could be done in stage 0, and getting an index number from a stream value would just be basic math, which DSP does fast.

[tulamide]

Map, as far as I know, does the exact same thing.

Thanks T . . . I never stopped to think about how Ruby works behind the scenes

Me neither
But always solve a problem first. When it's working, you can always think about improving it. "All roads lead to Rome", as we say. So, please don't think my proposals were trying to top yours. I was just showing alternatives

[tester]

From my experience, providing context is good only in cases, when I'm not sure what I'm looking for and have only a general or vague idea of some concept. In other cases, there is nothing else to say, it's just a quest for precisely specific solution.

As for moving this into DSP, from what I see, it's not necessary. Exported files behave a bit different (better) than schematics within FS app in this regards. Besides, navigating between DSP and greens - would require tick/timer, which isn't better than passthrough via logic of triggers. Another aspect is the size of DSP part, which in this case will be probably very heavy. We will se at the end. Right now, I'm polishing some of the building blocks.

[tulamide]

In other cases, there is nothing else to say, it's just a quest for precisely specific solution.

That's my point. You weren't specific.

Besides, navigating between DSP and greens - would require tick/timer, which isn't better than passthrough via logic of triggers.

I didn't say anything about combining DSP and green. I talked about doing the whole thing in DSP.