Optimization with subpatches vs. objects
Does anyone have some insight regarding optimization within Max as related to the use of subpatches versus subpatch-saved objects?
Say I have a patch with three identical subpatches (they do some sort of processing on some input from a UI object and spit it back out). I create an identical copy of the main patch and instead hook up three instances of my object as saved from one of the subpatches.
Which plan is more optimized--the one with just one patch open and the subpatches embedded, or the one with a main patch and three instances of the other patch?
I realize there are probably a lot of considerations with this question, but if there's any insight that would be great. Sometimes it's a real toss-up as to which route to go when designing (and of course other times it's a no-brainer to use one or the other, regardless of optimization).
I like the concept of instances of objects, however, the problem is in presets, pattr, colls, and tables within them... these are NOT uniquely stored unless saved in a separate file, correct? Which makes sense (as the object is unique regardless of the number of iterations, whereas subpatches are EACH unique). But it was a bit of a surprise when I first encountered it, especially as I used #1 arguments in the coll in each iteration... perhaps I'm missing something in that logic...?
I plan to build a control system for lighting or LEDs that could have up to 512 iterations of a multislider or bpfunction editor to control parameters (brightness etc). I'm thinking iterations of one main, generalized control object would be the best way, with each iteration's particular settings spit back out to the main level and stored in colls there rather than individual presets within subpatches. What's the difference in optimization there? 512 iterations of a single file or 512 subpatches embedded in the main file?
--CJ
Well, I can say startup wise, that with the abstractions (instances
external to your patch, separate files), that max has to spend some
time looking for the files on disk, with many subpatchers/loaded
instances, I have seen issues with lots of nested abstractions.
I have no idea quantitatively about abstractions versus subpatchers
and CPU load/burden on max, but qualitatively it seems subpatchers
dont stress max out as much, in my experience.
ymmv etc hth ++
On Jan 17, 2007, at 10:44 PM, Seejay James wrote:
>
> Does anyone have some insight regarding optimization within Max as
> related to the use of subpatches versus subpatch-saved objects?
>
> Say I have a patch with three identical subpatches (they do some
> sort of processing on some input from a UI object and spit it back
> out). I create an identical copy of the main patch and instead hook
> up three instances of my object as saved from one of the subpatches.
>
> Which plan is more optimized--the one with just one patch open and
> the subpatches embedded, or the one with a main patch and three
> instances of the other patch?
>
> I realize there are probably a lot of considerations with this
> question, but if there's any insight that would be great. Sometimes
> it's a real toss-up as to which route to go when designing (and of
> course other times it's a no-brainer to use one or the other,
> regardless of optimization).
>
> I like the concept of instances of objects, however, the problem is
> in presets, pattr, colls, and tables within them... these are NOT
> uniquely stored unless saved in a separate file, correct? Which
> makes sense (as the object is unique regardless of the number of
> iterations, whereas subpatches are EACH unique). But it was a bit
> of a surprise when I first encountered it, especially as I used #1
> arguments in the coll in each iteration... perhaps I'm missing
> something in that logic...?
>
> I plan to build a control system for lighting or LEDs that could
> have up to 512 iterations of a multislider or bpfunction editor to
> control parameters (brightness etc). I'm thinking iterations of one
> main, generalized control object would be the best way, with each
> iteration's particular settings spit back out to the main level and
> stored in colls there rather than individual presets within
> subpatches. What's the difference in optimization there? 512
> iterations of a single file or 512 subpatches embedded in the main
> file?
>
> --CJ
v a d e //
www.vade.info
abstrakt.vade.info
Seejay James wrote:
> Say I have a patch with three identical subpatches (they do some sort
> of processing on some input from a UI object and spit it back out). I
> create an identical copy of the main patch and instead hook up three
> instances of my object as saved from one of the subpatches.
There are three aspects of optimisation: optimised for CPU, optimised
for load time, optimised for control of complexity:
1. CPU, absolutely identical, no difference, it translates to the same
way of machine execution.
2. Load time. if you have duplicated a subpatcher 3 times it would make
your main patch bigger, it has to load more. of course if you have to
load an seperately saved abstraction, it first has to search for it. I
don't know with 3 subpatchers, but with 512 as you suggested, the size
alone for the big one will probably load longer than you have to search
for a couple of abstractions...
3. This is the most important. A duplication of 512 subpatchers would be
a complete nightmare to maintain. Because of that, you would not even
consider to optimise the content of the subpatcher on a direct level
(because you would have to do it 512 times). Whereas optimising a single
abstraction is as simple as opening it, looking at it and do it...
You will be forced to layout your project much more profound if you save
the abstractions. The first rule of optimisation is: encapsulete as is
the second and the third as well. If the patch is simple and
understandable, you took the first steps already. Presets are no problem
anymore with pattr by the way...
In your case I would even consider to accept a very little overhead CPU
wise (if at all noticable) and do it with poly~ (works like a charm
without audio being involved...)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
On Jan 19, 2007, at 3:14 AM, Stefan Tiedje wrote:
> 3. This is the most important. A duplication of 512 subpatchers
> would be a complete nightmare to maintain. Because of that, you
> would not even consider to optimise the content of the subpatcher
> on a direct level (because you would have to do it 512 times).
> Whereas optimising a single abstraction is as simple as opening it,
> looking at it and do it...
I go back and forth on this one. Abstractions are certainly easier to
maintain, but while debugging, subpatchers are easier to work with,
particularly when they contain data.
For example, having several instances of an abstraction that contain
colls (#1_mycoll) and values (#1_myvalue): as the patch is running,
they obviously contain their own data, which I want to see while
debugging. When I open the original abstraction, edit it, and resave
it, all the data is lost in the instances.
I guess I could try to fudge pattr to accept coll-type data, though...
Thanks Stefan, those are some good ideas to ponder. I had figured the CPU would be the same, but wasn't totally sure how Max dealt with the different (apparently actually not-different) means of holding / accessing patch data.
I think the poly~ idea is good, as well as the pattr. I'll just have to see how things turn out with the design--how many features etc. I want to include/maintain.....
Probably would rather have the bottleneck upon load, then run more smoothly during runtime. No problem with loading taking a bit longer than it otherwise might.
Thanks again
-C
> For example, having several instances of an abstraction that contain
> colls (#1_mycoll) and values (#1_myvalue): as the patch is running,
> they obviously contain their own data, which I want to see while
> debugging. When I open the original abstraction, edit it, and resave
> it, all the data is lost in the instances.
Not a problem at all. Just double-click the abstraction you want to
debug, then again on its own coll and you'll got its own data...
f.e
>
> I guess I could try to fudge pattr to accept coll-type data, though...
>
>
>
On Jan 20, 2007, at 2:58 AM, f.e wrote:
>
>> For example, having several instances of an abstraction that
>> contain colls (#1_mycoll) and values (#1_myvalue): as the patch is
>> running, they obviously contain their own data, which I want to
>> see while debugging. When I open the original abstraction, edit
>> it, and resave it, all the data is lost in the instances.
> Not a problem at all. Just double-click the abstraction you want to
> debug, then again on its own coll and you'll got its own data...
Umm, not after I resave the original abstraction, since all instances
of it are reloaded (with empty colls).
It's supposed to work that way. I know. But that doesn't make it
convenient in all situations.
Arne Eigenfeldt wrote:
> Umm, not after I resave the original abstraction, since all instances
> of it are reloaded (with empty colls).
>
> It's supposed to work that way. I know. But that doesn't make it
> convenient in all situations.
If its crucial, you need to save the data of the coll seperately to disk
(could be automated), or completely pattrify the design... coll with an
argument will read in a file if it exists...
When your done
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Quote: Stefan Tiedje wrote on Mon, 22 January 2007 08:43
----------------------------------------------------
> If its crucial, you need to save the data of the coll seperately to disk
> (could be automated), or completely pattrify the design
coll by itself cannot be pattried, as far as I can tell.
It may be possible to dump all its contents and create a single message, and store that, but this seems more work than it's worth.
On Jan 22, 2007, at 12:49 PM, Roman Thilenius wrote:
> put the 512 colls in your main patch, but try to have all other
> stuff around
> the coll in subpatchers to be able to instantiate copies from the
> same origin.
This is certainly a workable solution, but doesn't utilize the
benefits of instantiation.
In the abstraction, every time I add a new coll (#1_another-coll) or
value (#1_another-value), their independence is guaranteed, as well
as their creation, in each instance. I can create 8 instances or 512,
and all the creation and data handling is hidden from me.
If I were to create a separate subpatcher that only contained data
objects, and hand-named each one, I would immediately lose the
flexibility of instantiation, since I have to decide beforehand how
many versions I am going to use.
Just for clarity, I'm working on a huge multi-agent (as in AI) patch
that will have a variable number of instances that will be created
during performance. I use a ton of value objects and colls that
collect data during the program, rather than read data from disk. I
suppose that these could be created via scripting in the original
patcher, but that would be one more headache I'd rather avoid.
Everything will work as expected when the program is running using
the regular method of instances/abstraction. It's just that in this
code/test phase, it's a bit of a slowdown to always have to
reinitialize the system and run the program for a bit after editing
the original abstraction, just to look at the data. This is
particularly the case if the previous data was interesting, and I
wanted to compare my changes using the previous data.
But, as Stefan suggested, if the data was truly critical, I'd best
spend some time creating a system to save and reload the data...
Hello Vade, did you solve this problem? We have a similar PC with a
7950 GX2, with similar problems.
Best Lucas
> Hello
>
> Max 4.6.2, Jitter 1.6.2b2.
>
> Ive been remotely debugging a multiscreen Jitter patch with a client,
> who is running the system on a beefy Alienware Core 2 Duo PC
>
> The PC has 2 video cards, one bad ass Nvidia 7950 with 512Mb ram and
> one dinkier monitoring AGP card. The 7950 has a Matrox Triple head to
> go attached, while the second card has only one monitor. 4 monitors
> in total.
>
> Our patch is designed to run on all three screens from the triplehead
> at once. When we run our patch *windowed* across three screens, it
> runs at full framerate, about 35/40 fps with slab processing,
> jit.gl.sketch calls and texturing across all 3072x768 with quicktime
> playback, while the other monitor is left for the interface.
>
> If we run the main output (3072x768 on the Nvidia) with the
> 'fullscreen 1' message to jit.window, our framemrate drops, the
> machine is basically unusable until render is halted, we move the
> jit.window onto the dinky preview monitor, lower its size, and then
> start playback. Back to 40 or so FPS and everything is working.
>
> We can position the window with border 0, and find the pixel
> coordinates - but I guess my question is - what is different about
> fullscreen 1 on windows with multiple monitors VS OS X? When running
> the same patch on a Mac I do not see those issues?
>
> I think we can work around this (we also had multiple monitor slab
> issues as reported, and it seems that 1.6.2b2 fixes most of the
> issues), but Id like to know.
>
> Is this an OpenGL driver issue, a known Max/Jitter issue, or XP
> voodoo?
>
> Thanks.
>
> btw : I cannot attach the patch for various reasons - thanks for
> understanding.
>
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
jitter mailing list
jitter@cycling74.com
https://cycling74.com/mailman/listinfo/jitter
There is another issue. Over the years it has happened a (really) few times that a patch got corrupted, and although I didn't document any of this, I remember one occasion where all patch chords disappeared. For this reason I decided to work with relatively small files that can more easilly be reproduced when necessary. I have to say that it didn't happen for a long time, so either max has become more stable, or my strategy works.
Concerning loading time, throwing everything into a single collective once the patching is done, solves this issue.
_
johan
> coll by itself cannot be pattried, as far as I can tell.
[sorry off topic] I thought we had to say "pattrified"?