It's likely that some of the CPU overhead is due to being a scripted vs native language. That's not true for everyone but for Justin it would be true. If you know how programming works and you know the language at hand (and often when you don't know it), it's not a big deal - reading it is often easier than writing it. I have to read other's people's code every day, for about 15 years now. It's kind of mind reading, if you know what I mean. Sometimes it is much easier to write a new code instead. I mean it is rarely easy to read someone's code, but changing it as another story. These are of course solely my opinions and I mean no disrespect for both REAPER programmers and nistuj. So my question is: isn't it time to welcome this change and effectively make ReEQ the stock REAPER plugin, keeping a legacy version of what now is ReaEQ? This would mean that we'll have the best of both worlds: a fully fledged, modern EQ with VST optimization and ongoing support that doesn't rely on a volunteering user's free time. ReEQ plainly surpasses ReaEQ in terms of usability and features: it's just a more modern approach to EQ with band soloing, M/S processing, frequency color codeing etc. The only reason that I see not to use ReEQ over ReaEQ are CPU consumption (ReaEQ is ridicoulosly well optimized while ReEQ is bound to JS format limitations) or just plain habit. And I'll go out on a limb and say that whoever is aware of that plugin, probably uses that over ReaEQ. I'm sure most of us are by now aware of the insanely good and useful JSFX plugin called ReEQ by forum member nitsuj.
0 Comments
Leave a Reply. |