[ossia-max] Ossia.init

[navid]

An ossia.init object/feature to be implemented (similar to j.init):

Expected Functionality:

"ossia.init args1", where arg1 = name of the model, and where the init object couldd be places anywhere.

ossia.init should accept the name of the model in question and send out a bang as soon as the model has been initiated.

Why is it needed?

example 1: in autoregister @false

Let's say we are using ossia-max in autoregister "@false" mode. In this case, loadbang can't be used for initiation of certain processes that rely on ossia. Certain processes might need to be put into motion as soon the device has been registered and the model has been initiated.

example 2: n autoregister @true

A big patch is being opened, as soon as the preset.model has been initiated a location/file.text wil need to be sent to it to be opened. One should not need to use loadbang > deferlow > delay tactics for this. ossia.init would be far more elegent, consistent and reliable.

[vincentgoudard]

A few thoughts on this :

• rather than a bang, I would rather like ossia.init to output a 1 if model is ready, 0 if not.
• ossia.init should be bang-able, so that if it instanciate after the model it watches, you can fetch its init state
• ossia.init should have a right outlet that output the model's address, similarly to a remote, because design-pattern wise, it is a remote. Following this, you can provide a pattern-matching model address (either brace or wildcard) and you'd get the init state output alongside the model's address on right outlet.
• All the above could also apply to ossia.parameters initialization state.

[vincentgoudard]

Why is it needed ?

— because Max is an open-ended, dynamic environment where everything can depend on everything, and any new object can be added/removed at any point in time.

[navid]

Why is it needed?

— because Max is an open-ended, dynamic environment where everything can depend on everything, and any new object can be added/removed at any point in time.

@vincentgoudard I like some of your previous comments and thoughts here. Thank you
To be clear: I stated "why is it needed? then I proceeded with two examples to explain the context within which they would be needed ;) so ths got miscmmunicate i think.

[navid]

Think of ossia.initialized as a loadbang object that is tied to a specific model name: so it sends out a bang once, when that model has been initialized. refer to jamoma's "j.initialized" object as an example.

• rather than a bang, I would rather like ossia.init to output a 1 if model is ready, 0 if not.
• ossia.init should be bang-able, so that if it instanciate after the model it watches, you can fetch its init state

This additional feature, if anyone has a use for it, is not bad. So I don't see why not while myself don't have a use for this extra feature. If I read you correctly: we could send "ossia.initialized arg1=model.name" a bang and it will return either a 1 or 0 as an answer. cool :)

• ossia.init should have a right outlet that output the model's address, similarly to a remote, because design-pattern wise, it is a remote. Following this, you can provide a pattern-matching model address (either brace or wildcard) and you'd get the init state output alongside the model's address on right outlet.

cool again. I don't see why not.

• All the above could also apply to ossia.parameters initialization state.

[vincentgoudard]

To be clear: I stated "why is it needed? then I proceeded with two examples to explain the context within which they would be needed ;) so ths got miscmmunicate i think.

@navid Sure! I totally upvote your request and was only trying to fuel it with more arguments !
This and what you mentionned in #814 are important topics, which are now overlooked in ossia and limiting.
Sorry if that wasn't clear and/or if you thought I was criticizing your remarks — all the opposite! :)

[vincentgoudard]

... or think of ossia.init as an ossia.remote to an internal parameter of your model that is its initialization state ?

[navid]

... or think of ossia.init as an ossia.remote to an internal parameter of your model that is its initialization state ?

yes. as put precisely so.