search

jamoma / JamomaMax

Implementation of Jamoma for Cycling'74 Max:
http://www.jamoma.org
41 stars 9 forks source link

change the @dataspace family behaviour #589

Open bltzr opened 10 years ago

bltzr commented 10 years ago

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)

lossius commented 10 years ago

Moving this to a 0.6.1 milsetone

lossius commented 8 years ago

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.

bltzr commented 8 years ago

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...)

lossius commented 8 years ago

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.

bltzr commented 8 years ago

Well, two things:

  1. I think that, if there is someone that can implement this, it seems that it would be you, rather than Théo, as you're much more into the dataspace code than Théo, AFAIK Is that a very complex one ? I thought this could be solved by looking up to which dataspace the chosen unit belongs, and then setting @dataspace internally (so it doesn't have to be exposed to Max anymore... or maybe as read-only ?)... but probably I'm overlooking problems... And of course, while you're the one able to do it, it's obivously up to you to decide if you want to spend time on this... And I understand that's not part of your priorities..
  2. I don't know the precise status of Jamoma 2.0, but what I know from the experience of releasing 1.0 is that, with such deep changes, there is a lot of work to make all the littles changes required to get to a proper release... So I'm afraid that Jamoma 2.0 release won't happen before a certain number of years... So, I was thinking about this feature for an intermediate release, such as 1.1 or 1.5. Would that make sense ?