you can open a patcher without a GUI, using the (shroud {patchername}) message into the [pcontrol] object (see [pcontrol] reference).

you can move the window outside the screen, or shrink it to a minimum size, and it is gone. :)

Thanks! Those are some good tips.

hm but seriously, is there something like the 'puredata -nogui' terminal command?

Also i was wondering, as updating UI elements are big part of max's CPU usage especially if you have a complex project with lot's of patchers and subpatchers...

maybe it's a silly questions, but

1, if a subpatcher is not opened, then will max use any resource updating it's "unseen UI" elements? 2, if the patcher is in presentation mode, will that update only the presentation mode UI elements or also the patching mode UI elements?

Somehow sounds obvious it will update only those on the screen, but on the other side i can imagine a scenario when the system needs to update "FLONUM" for instance, even if that's in a closed subpatch, so better to use a "FLOAT" object...

So any of you know if that's better CPU usage if I use for example a "FLOAT" object instead of "FLONUM" even if the subpatch will be closed?

1.) i believe yes, at least that was true for max v 4.xx, and i would be really surpised if that changed with juce.

2.) same question, same answer.

of course one could have made the objects this way, that a fader simply does not move when not seen by the user, but the question remains how maxmsp should keep track of what is seen and what not. :)

and what should maxmsp do when an object is half seen and half covered? if you know what i mean.

basic rule is ... never use any gui objects (including the message object) in the final version of your abstractions and subpatchers.

thanx Roman, what's the best not UI object for message object?

https://cycling74.com/forums/ui-objects-and-efficient-coding

@Finecutbodies perhaps [zl reg]? But seriously, a "nogui" option would indeed be great. I know projects where the main reason for choosing PD over Max was this missing feature (there are situations where you simply can not ask the user to "move the patch away from the screen", specially if you're designing an application where the sound engine should be hidden from the end-users).

Cheers, Ádám

yes [zl reg] or simply [t] if you dont need the "set" input.

i once tried to make a no gui message abstraction which recreates the behavior of [message], but it never got 100%complete, there is still a bug for the "append" and "prepend" messages. and i must say, it contains so many objects, i doubt it is faster than using the gui external. :)

-110

köszi Ádám, thx guys!

with "t" you cand send lists, but "pack" or "pak" could work well :)

@Finecutbodies :-)

BTW, I don't think that Max would draw the UI objects that are not displayed. At least, this is the impression that the SDK in C gives (specially, section 11.8 of the SDK for 5.1.7 describing the paint()) method. Since a non-visible UI object doesn't belong to any active view, calling their paint() methods shouldn't cause any actual drawing. But perhaps somebody from C'74 could make this clear.

HTH, Ádám

How about using sprintf as a non-UI alternative to message? It can take arguments and can cover lots of the same features. Any downsides to this approach?

Sure, that's a good alternative, too. However, I still don't see the problem with message. In fact, GUI objects get only redrawn when they change (again, the SDK says that a GUI object needs to set a flag when it needs a redraw, otherwise its graphic representation will be cached and when the patch itself is redrawn, the content of that cache would be used). So, unless you always change the displayed content of the message, you really don't need to care.

@Siska Ádám: Well, if that's what the SDK says, then I guess the Cycling '74 guys abide by the same rules with their built-in stuff. Also, it makes perfect sense not to redraw a GUI object unless it changes. There is just so much talk on this forum about GUI objects causing performance problems, that it's hard to tell what is true and what is false.

you are right, for message you only have to care when you are using variables. but this happens quite frequently that people use it like that, so i´d recommend to use pack instead.

for message you only have to care when you are using variables

I'm not sure what you mean by this. If, by using variables, you refer to the case of, for example, set $1-kind-of messages, they will not redraw (at least, they're not supposed to redraw if the object was designed in accordance to the guidelines of their own SDK) when they receive a variable. A redraw would only be invoked when you change their actual content. To stick to my example, if you change its content to, let's say, prepend $1 from the original set $1.

BTW, this thread is becoming quite off-topic ;-) Perhaps a new one should be started for this issue, if anybody still interested in it. For my part, I would be more interested in hear a voice from C74 about the original question. Whether they had any plans to create a true nogui mode for Max, which would indeed be fantastic.