General/Max Wrapper Decisions

[Alex Harker]

There are 3 issues to discuss here:

1 - Parameter and enumeration name style

A - It is impossible for all parameter names and enumeration items to be compressed into a single word with a clear meaning. In this case, some kind of concatenation is necessary. Here are some possibilities - which is your favourite (I should say I am fairly loathe to embrace anything other than lowercase, but I include all obvious options for completeness):

numins

num_ins

numIns

NumIns

B - do you prefer longer (concatenated) names that are clearer or shorter names that might be less clear?

e.g.

triggers

trigger_inputs

2 - Any objections to using slashes (and not hashes) for parameter entry in a max object box?

3 - Any thoughts on the character set for entering fixed value inputs in a max object? (I'm not sure if anyone is using this feature yet - haven't seen any patches doing this)

[st kr]

1) A - num_ins because it is consistent with c74, and clear B - this is an almost impossible task. very difficult to have a blanket rule. the rule should always be: is this as clear as possible? in this example, trigger_inputs wins.

2) i like slashes and dislike hashes :-)

3) i actually do not know what this means. what is 'character set'?

[Owen Green]

I think my answers might be the same as @stkr

[Alex Harker]

Currently there are 4 different options for setting fixed inputs. This are in 3.5 of the docs. If you take a look which one seems preferable? (I feel that /1/ is now too likely to be confused with parameters and probably would favour [1] but I would like some other opinions).

[Owen Green]

Agree – of the options, square brackets are the most preferable. Presumably, if you offer this feature in other environments (e.g. SC?), it could need to be something different

[Alex Harker]

This would work differently in SC - the characters for this are specific to the Max wrapper, so on this one we only need consider Max.

[Francesco Cameli]

1) A- I agree with using num_ins as concatenation. B- I would go for the longer and clearer option. 2) Slashes are great. 3) Square brackets.

[James Bradbury]

1 - Parameter and enumeration name style A - numins. I prefer no underscores in parameters as is largely consistent with native Max objects. B - I dont mind either. At first something like triggers is ambiguous but it becomes familiar with repeated use. Once I'm comfortable long parameters bug me for sake of visual clarity in a patch. 2 - Slash is clearer to me. 3 - No comment

[Alex Harker]

Hmm. Looks like you are in the minority on the underscores James. Visually I prefer them (note that FrameLib is not strictly max only, so it is not always relevant to match max exactly).

The main issue with underscores in max is that max sees them as punctation (not part of a symbol) when text editing, and double-clicking text with an underscore doesn't select across the underscore - it drives me mad, because it is out of step with all other languages/editors and there is no language specific reason for it I am aware of).

[James Bradbury]

Upon reflection I'm going to flip-flop on what I said earlier. For your reasons above underscoring better accomodates the non max environments of FrameLib too. I do agree that underscores are a lot clearer and minor syntax consistency between Max and everything doesnt really contribute a lot to the overall UX.

I never really noticed the underscore selection in max when double-clicking. I suppose I've always had Control+Arrow key at the ready to move to the end or start of a param. I think you might have just ruined Max for me.

[Alex Harker]

You're welcome ;-)

[Alex Harker]

I've asked c74 if they might consider changing it - we'll see what they say. filter design has a stopband_attenuation attribute, which clinches underscores for me...

[Alex Harker]

Results here:

underscores / longer clearer (I'll go with trigger_ins for this particular one).

slashes

[] for inputs

[st kr]

underscores and other such naming conventions are a modern max thing. people like jeremy b and tim p brought in that nomenclature.

the reasons, i think, the underscores and dot-notations highlightings are unlikely to change, are that hundreds of max users have for ages used this very ‘feature’ in the development of cross language libraries - i.e., they name things based on the fact that they will just be able to copy paste parts of descriptions/names in other circumstances, and / or script them in a certain way.

in genexpr however we cannot use dot notation as this has semantic meaning, so the convention is to always use underscores instead. in genexpr everything gets selected when you double-click :) just not in max alone.

[Alex Harker]

HAHAHA David Z just made my day, in the future double-clicking will select across underscores!

[Alex Harker]

Also Pete - it is only codebox in gen that works that way with underscores - gen operators as boxes still work the way that the rest of max does.

[st kr]

indeed, i only ever use codebox :-)

i think dz is wrong. i was pleased to see jeremy b agree with me and matt.

it is yet another thing that dz will change that will ruin the habits of loads of max users. he does not give a shit.

ho hum, i guess that is to be expected since the nightmare that is his max 7 .