It seems like message boxes don't show through on a parent when they're in a Graph-on-parent area. Is that correct or am i doing something wrong? Right now i'm showing a Midi Note Number in a Number box. Want to change that to display the alphabetic Note Name and Octave Number in Message Boxes instead.

Parent:

Child:

I don't see anything in the documentation that explicitly says it doesn't. I see that the manual says that Graph-on-parent is an easy way to create interfaces that include sliders, buttons, number boxes, toggles, colored backgrounds. It doesn't mention messages, which leads me to believe it doesn't display messages. But perhaps there's a way? (Not seeing anything on this in the forums neither.)

Thanks!

I believe graph-on-parent shows only user-interaction objects. Message boxes aren't user interfaces.

I'd use a symbol box (ctrl-4) instead.

hjh

@ddw_music Gotcha. Makes sense. Symbols should work equally as nicely. Thanks!

You can also make labels for parameters or any other object like fader button etc.

Only thing is, that it's hard to get # into a message, so I replaced # with *.

@jaffasplaffa You can get hash into a message that will appear in a symbol box.
Unfortunately due to a legacy hack Gui's translate it to a $ in their label.
A bug report was opened in 2007 and never closed.
If you look in the Gui properties you will see the # in the label........ but of course that's not useful.

You will have to add a symbol box to the Gui instead..... hash_in_message.pd
You can size the fader 18 high and put the symbol box on top...... or to the side or wherever you wish.
Giving the symbol box send and receive names removes its inlet and outlet and it looks much prettier.
David.

Message boxes aren't user interfaces.

A message box is a button with text in it.

@jancsika said:

A message box is a button with text in it.

Ok, fair -- then, if they are clickable, what's the reason for excluding them from graph-on-parent? (That is, the exclusion is either deliberate or accidental -- if deliberate, there should be a reason; if accidental, probably it should be fixed at some point.)

hjh

@jancsika it's not ~only~ that though. They are more like objects than gui elements.
mainly the inability to edit them in run-mode is the reason that they would basically be equivalent to a bang with a label (which internally can be used to "bang" the appropriate message)

@ddw_music Who knows.

What I do know is that it appears to be a single line change in line 142 of Vanilla's g_editor.c:

            (glist->gl_goprect && (ob->te_type == T_TEXT)));

becomes

            /* ignoring 80-char line-wrapping style for the moment */
            (glist->gl_goprect && (ob->te_type == T_TEXT || ob->te_type == T_MESSAGE)));

I made a Purr Data merge request to go ahead and add this:

https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/609

If you're interested in Vanilla's history of intentions, perhaps you can jump on the mailing list and ask them.

If you do that, let me know if they decided to make this change-- if not I'll add a warning that this is a feature only available in Purr Data.

bang with a label

The label for a bang isn't a clickable part of the widget, is tricky for displaying spaces and doesn't support multi-line text.

And to be honest, I don't see any good reason to avoid displaying regular objects inside a GOP, either. That could be very helpful for tutorials for example-- it's way easier to clear out a GOP on loadbang than to dynamically create and manage objects in a toplevel canvas. (Edit: but trickier to implement to deal with displaying the connections.)

@jancsika I can only think of one reason to display [message( in a gop.
To be useful one would have to set the message and then bang it through.... when one can simply use a gui box instead for display purposes.
But it would allow a user choice whether to use the generated message or not.
It's fairly easy to work around that though with a bang.

I think they are the only clickable non-objects that are not included in the GOP?
Maybe it has something to do with the fact that they change size dynamically with the contained message.
David.

Interesting to see different possible reasons.

I suppose the best would be to let the user decide on a per-object basis, no? To add a "display in g-o-p" property whose default would be true for objects currently graph-on-parentable and false for others. (Then one may wish to be able to set properties for multiple objects simultaneously...)

(As a silly aside: Speaking as an American, the acronym of graph-on-parent has proven lately to be rather unfortunate, though in Pd's early years, nobody would have predicted it could get so far out of hand.)

hjh

@whale-av

Thanks for the suggestion. I already got a pretty nice system, which uses labels for showing parameter data and values. I don't want to remake everything, to be honest.

I cross my fingers for the hash to be implemented for messages in the future. If not, I can live without

Maybe it has something to do with the fact that they change size dynamically with the contained message.

Ah, good catch. I think that should be easy fix in Purr Data, but that make make it difficult in Pd Vanilla.

@ddw_music said:

(As a silly aside: Speaking as an American, the acronym of graph-on-parent has proven lately to be rather unfortunate, though in Pd's early years, nobody would have predicted it could get so far out of hand.)

I probably shouldn't go there, but I have a similar reaction...