Feature Request #805
|Assignee:||Théo de la Hogue||% Done:|
|Target version:||MVC for 0.6|
currently there is a tag attribute in jcom.parameter
it would be very useful that this attribute accepts lists instead of only one symbol, in order to have multiple tags for one object
it would be also very useful to be able to add tags to jcom.hubs, and potentially to models themselves (which they would propagate to their highest level hub)
some examples below
#1 Updated by Pascal Baltazar over 8 years ago
Why tags ?
Because sometimes you want to sort things based on their functions (or other criteria).
• For example, there are some parameters that I only want to save and recall when initializing my patcher, such as loudspeaker numbers, channel numbers, etc... A simple way to do this would be to have some tag support in jcom.cueManager, and exclude all these parameters marked with the tag "init" from all cues except the init cue(s)
• With the view patchers, and the number of parameters exponentially increasing, it could also be extremely useful to be able to filter out some parameters from user interaction. For example, when I'm creating mappings, there is a bunch of parameters (and modules) that I don't need to see and that clutter my menues and thus my brainspace. A "performance" tag added to each of the user-interaction parameter would help a lot in this regard...
4/ Where tags ?
For now, there are two places I'm thinking of :
• jcom.cueManager : like there is a "names" attribute, and like there could be an "exclude" attribute (as proposed in issue #793), there could also be "includeTags" and "excludeTags" attributes that would allow to select which parameters would go into the cue, in a more general/user-friendly way than having to pick every module and/or parameter that we want to Cue.
• jcom.namespace : here too, filtering out (or in) what's returned from jcom.namespace based on tags would be extremely useful IMO...
#2 Updated by Théo de la Hogue over 8 years ago
- Status changed from New to Resolved
the tag attribute is now a value (I would like to rename it "tags" but it causes a very strange bug when I try that... :(
however it is still not possible to check for one tag in criteria mechanism (because it compares the entire value instead
of checking each element of the value...) so don't try to retrieve al data with one tag in jcom.namespace for example...
but it's possible to use this info in Max via a jcom.receive so it could allow you to prototype some features...