GUI objects wishlist
Hi all,
This is probably a rant or a wishlist that makes no sense to most people but given all the advanced features that max has for creating attractive User Interfaces I would like to know the opinion of the community regarding the following features I would personally love to see in Max.
1.- Advanced comments or similar object. The comment object is great for what it is supposed to do (documenting patches) but sometimes I use them for UI elements. I would love to be able to have some slightly advanced features like being able to align text in a more sophisticated way. For example align left, center, right and justify text. Being able to rotate the direction of text would be a plus. I am aware of externals that do this but it would be a lot more efficient if it was implemented on the comment box with easy options on the inspector.
2.- Align options as implemented in vector graphics software (i.e. inkscape or illustrator). I know that the grid helps a bit in the graphical distribution of objects and Nathanaël Lécaudé's excellent maxtoolbox also allows for x and y equal spacing of objects but imagine if you could align objects not only to the left but center and right. Also spacing based on empty space between objects on either axis or based on the center of the objects. This would allow for good distribution of objects regardless of the font sizes.
3.- Something I posted about a while back and didn't seem to make much sense to anyone but grouping of objects would really, really make patching easy. I know that subpatchers help in organising things that act as a unit (say a function to process some input and give a result) but often you need something that requires some additional interaction.
For example take an Sfplay~ object. You would normally need at least a toggle to start stop playback and a 'read' message. This three objects might appear in many different sections of the patch either as part of it or just during patching to test things out. Imagine if you could just drag any of the three objects and have all of them moving together. Someone on a previous thread suggested a 'Encapsulate to bpatcher' option, but this requires the creation of additional files on the file system. In a way there are toolboxes that more or less address this issue like the new vizzie modules or Jamoma. However these only provide pre-set functionality that although cover basic (or very specific) needs (like my sfplay example) do not allow for any random objects to be grouped together.
I would like to know the opinion of the community regarding this. I reckon some might say that this is superfluous functionality that is not needed but I really think that it would make patching UIs a lot faster/easier. My first point could probably just be implemented as an external but the desired align/group things seem to me to be core things that would need to be implemented at the core for them to function correctly.
Any thoughts?
- Miguel
When arranging UI objects in _presentation_ mode, it would be good if one could group and ungroup a set of objects, so it's easy to move them around (and other editing functions) as a group etc without altering their relation with each other. This would probably save a lot of time when tweaking the user interface of a patch. I'd envisage that the grouping would only be apparent in presentation mode, and would not effect objects in 'edit' mode. Hope that makes sense...
T
Hi Terry,
If implemented as a global feature this could (possibly) be independent in edit and presentation mode. I still think that grouping during edit mode would help in patching but this would be a killer in presentation mode. If all these things existed you could group a series of objects, copy them (as a group) and then have the advanced align options to position them on your UI.
In any case, if implementation of grouping can not be done independently for edit and presentation modes it would indeed make more sense in presentation.
I've seen some impressive UI designs made by other people that are perfectly symmetrical in presentation mode and can't imagine how long it might have taken them to accomplish this. At the moment when I do that myself I have to take the size of the patcher, do some math and then input coordinates for each individual object in the inspector. This of course takes a lot of time...
Not so much a part of the GUI but the interface as a whole - right-click MIDI learn option as standard on rotaries and faders! This might sound lazy but increased portability of synth builds is quite important I feel...
what do you mean "by perfectly symetrical".
arent we just talking about arranging and aligning a bunch of objects? (which needs
a few seconds for 100 knobs?)
btw, i usually use tracing images in the background to my GUI objects for easy moving
to the easy position using mouse and arrow keys.
-110
Zooming with the mouse wheel would be most appreciated.
It might be a good idea to have the inspector window and the file browser combined - like another tab in the Inspector for the file browser. Then you could have it permanently docked to one side. Really handy to get to everything. And when the inspector loses focus I'd prefer it to default back to the patcher windows properties or back to the file browser tab but not grey out.
MIDI learn on sliders and dials is a great idea.
Patching in Max is already great - shortcuts, autocomplete, grids, segmented patch cords, maxtoolbox but those few things would be good especially scroll wheel zooming.
Have answered my own request. Here's a nice and simple MIDI learn subpatch for anyone who has ever wanted one but failed to get around to building one:
Hi Roman,
Arranging 100 knobs is easy and fast as you mention, but not when you have various objects that function as a group. Take the following patch as an example (change to presentation):
If I want to have more of these modules I can't distribute or align everything as a whole. I know I can make it into a bpatcher and then have one unique block on my main patch but then I have one more patcher file to manage. Even if I want to do this, when creating the interface that will be in the bpatcher I am limited in my options to arrange things. Say I want to make sure that all objects are centered within the background panels in the example above. I need to do this by hand/eye.
An example of the flexibility I am talking about would be the following:
Also being able to accurately set the distance between the objects is something that needs to be done by hand/eye. As mentioned previously, Maxtoolbox helps greatly with this but sometimes has issues when the objects are of different sizes.
Using tracing images as you suggest works but involves editing an image file in an external program that allows advanced align/group of objects, importing it to fpic, probably sending it to background and then locking the background. Doing this also means that when you move objects around they will not snap to the grid anymore as you now have something covering it.
mouse wheel zoom as suggested by grizzle would also be great. I have no personal interest in MIDI learn as I rarely work with MIDI and mr_mapes has already posted a solution.
I love working with Max and all the nice shortcuts, presentation mode, etc. are great and allow to create very usable and attractive interfaces. It just seems to me that beefing up some of this things would make patching a lot faster.
All best
- Miguel
I found out how to do Mac like zooming on Windows 7 and Vista (aero)
- http://absurdlycertain.blogspot.com/2010/05/mac-style-wheel-zoom-exposeswitcher-on.html - an easy autokey script (just copy and paste it into an autokey file and save it to the desktop).
It is an OS zoom rather than a patch zoom so things look blurry the more you zoom in but it's a start.
Can anyone get the scroll wheel into Max. I tried the obvious [hi] and various mousing objects but it didn't see the scrollwheel. Ideally ctl + scrollwheel -> zoomFactor -> thispatcher would be perfect.
any ideas?
mxj.autobot might have scroll-wheel detect?
I'd love control-scroll to zoom, and scroll-wheel for patch vertical scroll, or vice-versa. Settable in Preferences. Also some UI elements could really benefit from it, like waveform~...
Just wanted to bump this, with regards to grouping (esp. in presentation mode).
With all the great productivity and learning improvements in Max 5 & 6, grouping seems such an obvious omission,
Cheers
Roger
This should be doable with thispatcher scripting. However, you would need to name _everything_.
My biggest problem is that I cannot dynamically assign scripting names. This makes even simple tasks a big mess.
Some things I would love to see in Max, particularly to use in Presentation mode:
1. Right-click and Contextual Menus support capable of doing "MIDI Learn" like functions.
2. A kind of "virtual patchbay" GUI object, where "end-users" could connect modules, like in Reason or... Max's editing environment! ;-)
I'm sure there are many other things, but these two came immediately to my mind.
I've always wanted a bpatcher-like version of poly~ - where you have x number of bpatchers that get created or destroyed on command so you could implement a track or mixer style interface like in a DAW that expands or contracts in "channel" count as the user desires.
They would either add on or tile to the right or below the original one and could either be in their own pane with scrollbar or just make the max patcher "bigger" (when you have more "channels" than will fit on your screen, you just scroll the patcher to the right or down). It would be important though for them to not lose their internal state when a new one is added or removed like poly~ does.
I wrote something like this with scripting once in Max 4, but it was a disaster to maintain. might be easier now with presentation mode, but still seems like a pain to do with scripting. And some similar stuff for multi-track data display can be accomplished with FTM now that their ftm.editor object is relatively complete.
A dedicated object like this, I think, would make Max a much more serious platform for writing more complex end user software.
@Arvid : heh i made exactly this thing in Max5 :) but as you stated, it's a disaster to maintain, and it's very specific so it can't be easily redone for something else. so i concur.
As for the rest, i can only once again concur, especially with the one-click midilearn (there are workaround, made my inefficient own, i think i saw something cool once maybe in the ircam FTM, but really it's not the same thing) and grouping.