libossia
libossia copied to clipboard
ossia
[ossia-max][ossia-pd] create new ø.explorer object to query the namespace of all devices
could you @jln- please specify this a little bit more ?
you mean a new method for [ossia] object that returns all namespaces that live in the current Max instance ?
Not sure this was a request of mine. But as I understand it, yes, that would be a way to get all devices in the current Max instance.
Isn't something we could get with a 'namespace + pattern-matching' request ?
Isn't something we could get with a 'namespace + pattern-matching' request ?
currently no, but we could think about it
this will look like a search tool then, [namespace *:///foo( will return all node which name end with foo in all devices, for example ?
as we discussed here https://github.com/OSSIA/libossia/issues/345, I propose for that one, [namespace search 'pattern'(
or maybe an [ø.namespace] model would be more clean than adding long and weird syntax to the [namespace( message.
what was the methods of [j.namespace] ?
I'm not sure we should use [j.namespace] as a model, it was quite complicated, maybe even a bit convoluted...
it worked by creating and combining filters, e.g. filter/set eqViews object Container attribute service value view
maybe there are some existing search query syntaxes now, that we should get inspiration from ?
but, yeah, maybe an [ossia.namespace] (or maybe rather [ossia.explore], [ossia.browse] or [ossia.explorer] ???) would be a better idea
specification hypotheses:
- when placed under a device (including the global device) or node, it returns everything that lays under the provided node (e.g.
/returns the full namespace,ch.3returns everything under this node (as a relative address) - works with "absolute" addresses, e.g.:
myDevice:/returns the full namespace of this particular device (be it 'local' (declared in Max with an [ossia.device]) or remote (which has to be instantiated by an [ossia.client]) - working with wildcards: e.g.
ch.*,ch.{2..5},devi{l,ce}:/,*:/
how does that sound ?
also, we could add an attribute per parameter's attribute, e.g.
-
@name (nothing provided)will return all nodes under the provided address -
@name ant{oine,hology}will return all nodes only for the matching names under the provided address (of course this can be combine with wildcards for the addresses, as @avilleret suggested, e.g.*:///foo-> this would return allantoineandanthologynodes under allfoonodes at any hierarchy levels of any (local or connected devices)
several attributes could be combined, e.g. if we added @unit db this would restrict to only those with this unit (so that's a && between criteria)
if several values are given to an attribute, they are combined (aka ||)
does that sound sensible ?
Sorry for the delay, I bookmarked this but did not have the time to fully get into it. Thanks Pascal!
I'm not sure we should use [j.namespace] as a model, it was quite complicated, maybe even a bit convoluted...
Yes, I agree.
Something that would be good being able to do is what we use to do with [j.receive model:address]. Being able to get the parent model address.
When working with j.namespace something also used in quite some Jamoma models was being to output a full namespace or only model or attribute nodes.
Something that would be good being able to do is what we use to do with [j.receive model:address]. Being able to get the parent model address.
Maybe that could be something that we ask to all ossia.objects ? like (get parent) or something ?
When working with j.namespace something also used in quite some Jamoma models was being to output a full namespace or only model or attribute nodes.
we could do that by filtering with the access attribute for example @access get set bi would return only parameters, since models don't have these attributes
would that make sense ?
concerning the name, ø.namespace does't reflect all what you can do, ø.explore will be more explicit, or ø.browse what do you prefer ? or even ø.search
i'll vote for the last one, and add a feature to show up object that use the found nodes