Open bltzr opened 10 years ago
Moving this to a 0.6.1 milsetone
This didn't happen, and now it's to late for 1.* versions as it will break backwards compatibility. It could be reconsidered for 2.0, but I'm closing this issue for the time being.
Well, I don't think this would break anything... the only thing would be that all objects would complain in the Max window that there is no such attribute as @dataspace Everything should still work the same, assuming that @unit has been provided (and not providing an unit won't make any sense when using dataspaces... which is one cause why I think this is redundant, BTW) Should we reopen this issue ? And maybe affect it to another milestone (even if 1.1 seems a good idea...)
Do you think that it is at all realistic that this issue will ever be addressed for Jamoma 1.0, considering that Theo is not at GMEA any more? If not it would be good that we started cleaning up by rejecting and closing issues for Jamoma 1.0.
Jamoma 2.0 for Max, when that happens, is very likely to emerge as a new repository, so issues from this repo won't automatically continue to be valid for Jamoma 2.0.
Well, two things:
According to what was discussed in Bergen: (see https://github.com/jamoma/Jamoma/wiki/Workshop-BEK-March-2014-Thursday#attributes) • We agreed to make an implicit declaration of the dataspace depending on the unit used. We then need to make sure that all unit names are unique, as there is currently some overlap between midi and gain (see note above about midi time & gain). • If possible, the proposal would be to have the dataspace only change at the object instantiation. This would mean it would be impossible to send something in Hz after you have set a dataspace to gain. • We would need the ability to set the unit_internal used for calculations separately from the unit that is input and output. (maybe this last one can be postponed)