V3 is poised to gain a swath of new basic math functions like hypot, trunc, round, mod (floored remainder), and a bunch of array iterator APIs.
While some future features may be V3-only, these APIs can be ported back to V2 with some work, which of course takes time away from more features.
Alternatively they could also be implemented in code as a compatibility / polyfill layer and allow V2 to run patterns written for the new API. For example, hypot(x,y) is (x,y) => sqrt(x*x+y*y).
What is most important to you?
New V3 features are the most important - it’s OK if new pattern code written in 2021+ for V3 only works on V3.
Pattern source compatibility is the most important. New patterns should run on updated V2s without any extra work.
I don’t mind as long as there is a compatibility/polyfill code library I can paste in to use new V3 patterns with V2 even if it’s a bit slower.
0voters
I have my own feeling on this, but I want to see how people feel about this.
I’m going to say that your EPE format of storage is the way to handle this. IF a v3 function is used, then when an epe that contains it (and thus has a v3 label/tag) is loaded into v2, it should autoadd the compatibility function(s) (either just those needed, or honestly, keep it simple, just add them all).
So to be clear: spend the dev time adding smarts to epe loading and not backporting to v2 unless it’s trivial to do so.
There are still a lot of applications for which I’d chose the v2. I agree about backporting relatively trivial stuff, although I’m totally ok with v3 features in the world that simply won’t work on a v2, if they can fail in a graceful (non-reset-loop inducing) way.
Was there a decision made on this? I’ve been out of the loop for the past 6 months and currently playing catch up on the differences between the v2 and v3 APIs as I try to get some of the wonderful new patterns in the pattern library running on both v2 and v3 hardware. I’m probably going to try and backport some of the v3 functions, but before I go too far down any rabbit holes I thought I’d check if this has already been done or is planned anyway.
@ChrisNZ ,
I haven’t circled back yet and added this to V2, been focusing on V3 for the moment. I do want to go back and add some of this to V2 and keep the pattern language compatible where possible.
The V3 branch is a bit older now, so yes that would give you a delta. The new functions were added after V3 was released.
You can see this change where the bulk of new stuff was added:
Thanks for clarifying, knowing some further compatibility is coming is good news.
After looking through most of the v3 patterns further, it seems only a few new functions are generally being used so far anyway, and they’ve already been discussed in various places on the forum. For anyone interested, a summary is that hypot() and mod() can be implemented on v2 hardware easily by just including the following at the top of the pattern:
function hypot(a, b) { return sqrt(a * a + b * b) }
function mod(dividend, divisor) { var r = dividend % divisor; return (r > 0) != (divisor > 0) ? r + divisor : r }
If you see a “lastSrc is not defined” error (with no corresponding line number highlighting where the problem is) then the v3 code is probably using one of the new array operations. This will require fixing by hand. For example, the following code:
matrix.mutate((v) => array(height))
Would need to be replaced with:
for (i = 0; i < matrix.length; i++) { matrix[i] = array(height) }