Feature Request #1188
port new types to 0.6
|Assignee:||Théo de la Hogue||% Done:|
We need to port the new types (integerArray and decimalArray) to 0.6 and change the patches accordingly...
maybe a merge will do the trick ?
#3 Updated by Pascal Baltazar about 5 years ago
- Priority changed from Normal to Low
Thinking about it twice, I'm wondering if parameters (and messages/returns) of type integerArray/decimalArray couldn't be replaced by the new jcom.parameterArray, messageArray, returnArray and remoteArray, in mode array (which allows to manage the object with a list of all instances...)
I guess this isn't so easy to discuss remotely, but maybe we should look into that during the next 0.6 workshop ?
#4 Updated by Trond Lossius about 5 years ago
I unfortunately doubt that this is possible, Pascal.
We won't be able to use e.g. the position dataspace unless all three coordinates belong to the same parameter. So we need to permit @type arrayOfSomeKind. With the dataspace there are major performance benefits if we know that all parameter values are decimals, and this was the motivation for splitting the previous @type array into arrayDecimal and arrayInteger.
#5 Updated by Pascal Baltazar about 5 years ago
you're probably right, Trond,
though, I would like that we consider it the next time we meet IRL, because I have the intuition that this would be an interesting way to handle arrays... currently, it is very hard to map to e.g. one of the coordinates of a "multidimensional dataspace" (e.g. y in a xyz position parameter)
using this new array mode of jcom.parameterArray, with of course an updated way to handle "multidimensional dataspaces" across 3 (or more) parameters, would be really great...
anyway, that's almost impossible to explain thoroughly and clearly without discussing this in facetime, that's why I was proposing to discuss that during a workshop... (or possibly by skype, with screen sharing..)
there's no hurry anyway...
#6 Updated by Trond Lossius about 5 years ago
Yes, I can see this being interesting.
I've actually been doing this quite a lot myself already as a means for generative variety of spatial location in installations. But I have typically then made a patch outside of the spatialisation module that use several instances of jcom.ramp, one for each of the coordinates, and then packed the resulting coordinate values before sending them to the module.
We should be able to have a workshop sometime in 2013 (BEK has funding towrds this). Let's make sure this gets on the list of topics to discuss.
Also we should try to have a Jamoma BOD at some point in the not to distant future.
#7 Updated by Théo de la Hogue almost 5 years ago
Here is the discussion we had on the devel list afterward :
do you remember this thread : [jamoma-devel] @type should be floats only ?
The final point was to create two more types integerArray and decimalArray to optimize range and clip processes.
As I'm currently designing this for 0.6, I now have an opinion about this thread but for 0.6 only because what is below cannot be done for 0.5.
First of all, in 0.6 the values are not anymore handled by the Max API t_atom structure but they are handled by the TTValue class.
In the TTValue class there is an unused member pointer :
TTPtr reserved; ///< (unused)
and we could replaced this member by this one :
TTBoolean isArray; ///< is all values are the same type than the first one ?
When a TTValue is created or each time a value is appended to an existing TTValue, it should not be time consuming to update this member
(but maybe I'm wrong here which is the critical part of this explanation … let me know if you see anything wrong).
In my opinion this change on the TTValue class could bring two benefits :
- at C++ level : avoid type checking on the whole TTValue content afterward. If isArray is true, check the type of the first value and you get the type of all the others.
- at Max level : for jcom.parameter|message|return the @type integerArray or decimalArray are useless because we could decide afterward which clip or range process to use during the execution now we have a none time consuming way to now if a TTValue is made of integer or decimal only. So we could finally have no @type array because a TTValue is an array if there are more than one value inside and all the values are the same type.
What do think of this ?
I know this will implies again more changes in patchers for the transition to 0.6 but in my opinion this is really more user-friendly.
#8 Updated by Théo de la Hogue almost 5 years ago
I have no objections.
Every time I read about changes like this TTValue, however, I'm reminded about how I'd like to completely rewrite it...
If I could do it over again I would make a class that represents a single value (TTValueItem). Then TTValue would be implemented as std::vector<TTValueItem>, or a subclass of that, or a wrapper of that, or ...