Binary Object Review

[Alex Harker]

Please take a look at the list of binary objects and provide answers/thoughts on the following questions:

N.B. A binary object is an object that takes two inputs and transforms each value pair in the input frames according to a given operation (with two inputs/ one output). The current objects map fairly directly onto the contents of math.h in this regard. There must be a rationale for how to treat mismatched lengths of input frames.

1. Are there any objects missing here?

2. Are there any object features missing here? (is anyone missing a different mode of dealing with mismatched input lengths)

3. Any issues with info documentation, either general, or specific to a given object?

4. Parameter Names / Enumeration Names

• I think mode is probably a bit general and unhelpful as a parameter name - can anyone think of a preferable one (or do you like mode)? This is relevant for other objects as the parameter mode gets used a lot for different things.
• triggers could be more explicit (e.g. trigger_inputs and the names of the enums could be changed to be less max-only orientated given that frame lib won't also be hosted in a graphical language (e.g. "both, first, second"), although in this case a binary operation always has a clear left and right operand (as for instance the right operand of a non-commutative op like divide is notable different to the left one) - thoughts?
• padding - perhaps shorter is better (pad) or more verbose (e.g. pad_value / paddingvalue).

[Owen Green]

1. Modulo? I have an abstraction but...
2. Not yet
3. Not yet
4. • Agree, I don't like mode but can't think yet of a better one
   • No opinion
   • Pad

[Alex Harker]

What does "not yet" mean? You can't think of any, or it depends on something else?

[Alex Harker]

Is "mismatch" better than "mode"?

[Owen Green]

That I haven't come across missing features or documentation issues yet.

Mismatch is better than mode

[Alex Harker]

Modulo is now a thing (can't think how I missed that). How do people feel about words vs symbols (e.g. fl.%~ or fl.==~)? This could also be solved with name aliasing, but name aliasing requires the whole package to be installed. I could also alias back to the long names if I wanted to prioritise the short symbolic ones....

[James Bradbury]

Symbols are clearer than words to me. Splitting hairs, it also saves a bit of patching space and is much clearer.

1. no
2. no
3. no
4. pad and no formed opinion on points a),b) as of yet

[Rodrigo Constanzo]

Not much to chime in here other than to say I prefer symbols over words for % and logical stuff.

[Alex Harker]

That pete dowling has some aliasing files in his personal package version, but he hasn't chimed in yet. Perhaps I can convince him to contribute them to the group for now. It seems like perhaps the default names should be symbols and they should be aliased to words for the nerds.

[st kr]

regarding #4, i think whatever happens as long as it is totally consistent across the framelib then that is good. so at the moment 'mode' gets used for different things, which is bad. i agree 'mode' is probably too general. the problem with 'mismatch' is that it is a leading word: mismatch of what? i guess we are looking for a good, short word that is illustrative of two frames of different lengths meeting eachother. duh :-)

"padding" is better than "pad", even though it is longer, because is is less vague. pad is a bad word in audio related enterprises in this way. 'pad' could simply be misread by someone, 'padding' not, even if at first a user might not know what it is.

thanks to owen for catching modulo.

i have sent alex my framelib 'init' folder which does all the mapping of symbols painlessly. hopefully alex can use that for testing. i think symbols are good simply because max users are used to them.

[Alex Harker]

Looks like using a number links out to a numbered issue, which clearly isn't what you mean here...

• I feel like you've answered your own question about mismatch, so I'm not sure if you still object - it's what is in my current version.

• sorry, pete 'pad' won out so far here - I realise it might be confused as a pad mode, but the info makes clear the meaning and keeping object boxes compact is another concern. I'll add the init folder into the next release as a symbol solution for now.

[Alex Harker]

OK - I'm also closing this one - for those following at home the results were:

• Added modulo object

• Parameter name changes:

mismatch (pad_in / pad_out) / trigger_ins / pad

[st kr]

really sorry to revisit this alex, but it seems alpha 0.8 has brought me out in a rash. i am having big problems now that i use it with "trigger_ins". it is just that this exact feature in max is natively @triggers, and my brain seems to feel that is more appropriate now. however, i would understand the case that it should only be the more explicit underscore version if it is an issue of general and non-max usage. just thought i should say. is there any scope for making max versions have aliased more max centric names?

[Alex Harker]

It's almost like we discussed this already (#29) and you said 'in this example, trigger_inputs wins.' There is zero chance of having parameter names aliased specifically for max. I am not going to pursue consistency with a language which itself is often inconsistent. My aim is internal consistency. I could go for triggers, but the consensus on the other thread was for something longer. At some point things must be locked down to a final decision.

[st kr]

yes sure, but my response was to actually having used it in practice rather than just talked about it. i know it was me suggested / agreed/ whatever trigger_ins. i just thought it worth discussing it further having actually experienced using it.

i feel you have time yet for final decisions :)

p .