No gui mode?

Jun 23, 2013 at 7:29am

No gui mode?

Is there any way to run Max without its UI? I’m thinking along the lines of Pd’s -nogui mode or something similar so I can create a more detailed UI using openFrameworks/Processing and communicate over OSC?

Thanks

#253788
Jun 23, 2013 at 12:24pm

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

#253802
Jun 23, 2013 at 12:53pm

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

#253804
Jun 23, 2013 at 2:33pm

Thanks! Those are some good tips.

#253810
Jun 24, 2013 at 8:29am

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

#253848
Jun 24, 2013 at 8:34am

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?

#253849
Jun 24, 2013 at 8:45am

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.

#253850
Jun 24, 2013 at 8:55am

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

#253852
Jun 24, 2013 at 9:02am
#253854
Jun 24, 2013 at 9:06am

@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

#253859
Jun 24, 2013 at 3:02pm

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

#253927
Jun 24, 2013 at 3:11pm

köszi Ádám, thx guys!

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

#253928
Jun 24, 2013 at 3:42pm

@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

#253931
Jun 25, 2013 at 3:18am

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?

#253987
Jun 25, 2013 at 3:44am

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.

#253989
Jun 25, 2013 at 4:24am

@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.

#253994
Jun 25, 2013 at 4:27am

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.

#253995
Jun 25, 2013 at 4:50am

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.

#253998
Jun 25, 2013 at 4:55am

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.

#254001

You must be logged in to reply to this topic.