Nikolas K

I am wondering, is it better to make some functions (with no need for accurate time precision), using ordinary max objects OR wright them in a JS file?

I have a GUI bpatcher, with its inputs and stuff, that I want to dynamically create a lot of its instances (80? 100?) , and I am thinking of the loading time (the time that Max "lags" as its making the instances).

My thinking is that every max objects carries a lot of "unnecessary" code that adds to the loading time,

But if the same functionality is made in a JS , loads one file thus reducing the overall loading time.

I do not need much time accuracy for this, I know that the JS always runs on the low priority queue, but my concern is only for the loading time it needs.

Any suggestions or comments on this? Since my bpatcher is already build with max objects, I do not want to start converting unless it is worth it.

I am wondering, is it better to make some functions (with no need for accurate time precision), using ordinary max objects OR wright them in a JS file?
I have a GUI bpatcher, with its inputs and stuff, that I want to dynamically create a lot of its instances (80? 100?) , and I am thinking of the loading time (the time that Max "lags" as its making the instances). 

My thinking is that every max objects carries a lot of "unnecessary" code that adds to the loading time,
But if the same functionality is made in a JS , loads one file thus reducing the overall loading time. 

Any suggestions or comments on this? Since my bpatcher is already build with max objects, I do not want to start converting unless it is worth it. 

js-vs-max

Does the patch start up slow as hell already? If not, why to bother to rewrite in JS? If it does, it makes sense to try JS out.

(Captain Obvious on the premature optimization problem.)

In my experience, the native object performance is not a problem in 95% of situations—my feeling suggests that they even run faster than the JS, but that could be due to low/high priority stuff.

I just conducted an experiment, creating a about 200-300 interconnected objects and trying to delete them all at once and then redo this. Here a some conclusions:

1) Messing with the objects doesn't affect timing events—logical, as UI stuff works in the low priority.

2) UI gets sluggish with a lot of object in the patch, but if you encapsulate them it'll become responsive again.

3) When you duplicate the subpatch containing a lot of objects, the lag gets noticable, but not so bad.

1) If you're concerned only with the DSP lags, then no worries—the overdrive saves you from the lags in audio when modifying non-MSP objects.

2) Yes, you can speed up the dynamic patch loading responsiveness by rewriting functionality in the JS unless it has heavy initialization routines, due to reducing total objects/patchcords number.

Does the patch start up slow as hell already? If not, why to bother to rewrite in JS? If it does, it makes sense to try JS out.
(Captain Obvious on the premature optimization problem.)

I just conducted an experiment, creating a about 200-300 interconnected objects and trying to delete them all at once and then redo this. Here a some conclusions:
1) Messing with the objects doesn't affect timing events—logical, as UI stuff works in the low priority.
2) UI gets sluggish with a lot of object in the patch, but if you encapsulate them it'll become responsive again.
3) When you duplicate the subpatch containing a lot of objects, the lag gets noticable, but not so bad.

So my guesses:
1) If you're concerned only with the DSP lags, then no worries—the overdrive saves you from the lags in audio when modifying non-MSP objects.
2) Yes, you can speed up the dynamic patch loading responsiveness by rewriting functionality in the JS unless it has heavy initialization routines, due to reducing total objects/patchcords number.

Its not the UI response that bothers me, its "responsivness" is fine (for now at least!), or any DSP lag, just the loading time of the multiple UI bpatchers.

The overdrive is ON because there is stuff that need to be more accurate but the DSP is turned off during the UI bpatcher creation.

The JS initialization should be very light, set 5-6 values more or less. So, I think I will try the JS approach and post results, hopefully in a couple of days!

Its not the UI response that bothers me, its "responsivness" is fine (for now at least!), or any DSP lag, just the loading time of the multiple UI bpatchers.
The overdrive is ON because there is stuff that need to be more accurate but the DSP is turned off during the UI bpatcher creation. 

The JS initialization should be very light, set 5-6 values more or less. So, I think I will try the JS approach and post results, hopefully in a couple of days! 

I re-did a patcher in JS (most of it) that loaded over 100 times, and got a better loading time!

It wasn't the UI bpatcher stated above, but a DSP patch loaded on the standalone launch.

While I didn't do any DSP change on it, I only put its non-"high-priority" functions in the JS and

the patch is now the 1/3 of its original size (could probably get more optimized), and the 100 instances load about 40-50% faster.

I guess the DSP objects make for the most of the loading time, since every instance has a couple of buffers initialized,

so I am quite sure that a JS approach to the controlling guts a patch can decrease loading time.

So, on the Max vs JS battle, to conclusion so far is that if a patcher is loaded dynamically, JS can save you time!

Once I change the UI I will post again the new results!

I re-did a patcher in JS (most of it) that loaded over 100 times, and got a better loading time!
It wasn't the UI bpatcher stated above, but a DSP patch loaded on the standalone launch.

While I didn't do any DSP change on it, I only put its non-"high-priority" functions in the JS and
the patch is now the 1/3 of its original size (could probably get more optimized), and the 100 instances load about 40-50% faster.
I guess the DSP objects make for the most of the loading time, since every instance has a couple of buffers initialized,
so I am quite sure that  a JS approach to the controlling guts a patch can decrease loading time.

So, on the Max vs JS battle, to conclusion so far is that if a patcher is loaded dynamically, JS can save you time!
Once I change the UI I will post again the new results! 

JS vs Max