Unary Object Review

[Alex Harker]

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

N.B. A unary object is an object that takes a single input and transforms each value in the frame according to a given operation (with one input/output). The current objects map fairly directly onto the contents of math.h in this regard.

1. Are there any objects missing here?

2. Are there any object features missing here?

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

4. Is it an issue to have trig in radians only (and a separate method of conversion)?

5. Would you prefer one variable base log/exp rather than the specific base versions available at the moment?

[Owen Green]

1. Not missed anything yet
2. Ditto
3. No
4. Not for me, but maybe for spatialisation it would make sense to have degrees as well?
5. I like having specific bases

[James Bradbury]

1. atodb? perhaps not useful in the FrameLib context
2. nothing so far
3. No
4. Echoing Owen's sentiment here, spatialisation in degrees option would be simpler for people like me who are familiar with spat messaging
5. I'm not as savvy here, if you mean specific objects for each base then that is much clearer than one object with multiple modes in my opinion.

[Alex Harker]

For atodb you'll be wanting fl.convert~ (which already supports this plus lots of other things including degrees->radians and vice versa)

Your interpretation of log bases is correct, and I think it will stick this way. You can do any log base you like by using the change of base rule, but that requires you to know the maths. Having said that I'm confident that any one who really needs a base that isn't e, 2 or 10 will already know about this.

[James Bradbury]

I had a feeling it somewhere I wasn't looking... thanks for pointing that out.

[Alex Harker]

So it looks like the only item to look at here seems to be the potential use of a degrees mode for trig ops. Is it necessary to add this directly to the trig objects given that fl.convert~ supports conversion, or is that enough?

[st kr]

what is the relationship between the framelib concept and the possibility of bitshifting maths? i can imagine missing this but realise that i might be off the mark here.

regards #5, to be honest, what i would really like is a framelib expr object. much like jit.expr or jit.gen can be used. i come from using max as a bad IDE for the GenExpr language, and sometimes making all these objects is problematic for me. these wishes for other bases would be less of an issue with such an object.

[Alex Harker]

I'm not adding anything to do with bit manipulation, as bit manipulation of double precision values doesn't make any (general) sense. Also bit shifting of ints is equivalent to either multiplication or a power operation, so it can still be done (it's also a binary, not a unary). I have, however, just added the three basic logical operators as unaries/binaries (not/and/or).

I'm afraid I'm not going to make an expr like object any time soon as it doesn't add any new functionality and it isn't easy to do - feel free, however, to take a shot at it. As I mentioned above, change of base is perfectly possible via division/multiplication, so as the preference is for specific bases (rather than a log object that is a binary, or with a base parameter).

[Alex Harker]

I'm going to close this up for now, and go with the fl.convert~ option to support degrees for now. This would be easy to revisit at a later date without breaking pre-existing patches. That'll allow me to move on with the object review...