cac-t-u-s / om-sharp-users

A public forum for support / issues / suggestions about OM#
3 stars 0 forks source link

Using loops on OM# #39

Open jlquispec opened 3 years ago

jlquispec commented 3 years ago

Hi! I'm using loops on OM#. There are similar objects that OM but some without documentation.

For this purpose, I don't know if this a correct operation for init-do with collect with reactive mode on . I have notice that for this patch init-do is running at the end so internal memory is cleaned when looping is finished and not before starting the loop.

It is normal that output 'reinitializes memory', when reactive mode is on, be executed at the end?

)

patch file: https://drive.google.com/file/d/1zB02bYoYycHp0UzF1ae5F1z09uE9psjs/view?usp=sharing

jlquispec commented 3 years ago

image

jlquispec commented 3 years ago

I'm sorry. I just found the documentation on loops. https://cac-t-u-s.github.io/pages/loop

I will see if my patch is correctly written.

jlquispec commented 3 years ago

Hi Jean, excuse me for all the questions.

I'm rewrite my patch and read the documentation over loops and memory, but I have a little questions about this topics:

j-bresson commented 3 years ago

Hello,

Reactivity in OM# works at first-level only: in the patch that you see open and where you evaluate from. Abstractions are just functions, they don't "react internally". They also don't have a memory outside their own scope (that is, during the time of their execution).

The loop features are typically used inside an abstraction (although they also work in your main patch, but this would generally be for testing purpose mostly). Therefore, it (also generally) doesn't make much sense using them with any kind of reactive component.

Also, as documented in https://cac-t-u-s.github.io/pages/memory, the collect object behaves quite differently when responding to reactive notifications, or when it is pulled inside a loop or another abstraction.

So,

have it a sense use a init-do object in a context where Output doesn't exist (a main patch for example)?

Not really. That would just allow you to evaluate this box manually.

when I push action in a second inlet of collect object with reactive mode on. is it normal the propagation over 3 outputs?

Mhh.. maybe not, but at the same time it doesn't make much sense to connect anything to the other outputs in the reactive mode. Did anything bad happen to you because of this ?

when I use a collect object inside a external abstraction or internal patch, is it normal that the memory is cleared before starting a new loop automatically?

Yes, for the reason exposed before.

Hope this helps!

Jean

jlquispec commented 3 years ago

Hi Jean!

Thank you very much for your patience in explaining and clarifying some topics!!!

About collect object with reactive mode I haven't any problem now after your explanation. But my question is about the operation of the object while try to understand exactly the documentation about reactive mode. In this little example, I would think that the notification should not be propagated to the third output.

image

j-bresson commented 3 years ago

I would think that the notification should not be propagated to the third output.

I think I see what you mean, but at the same time, if the output is set reactive (by you), and connected to a print through a reactive connection, it would be unexpected that it doesn't react :) I other word, you should just make the thirst output not reactive to prevent it from propagating anything.

j-bresson commented 3 years ago

(you can selectively set inlets and outlets reactive/not reactive using the right/ctrl-click context menu, or by applying the R shortcut on connections rather than boxes. I would generally advise that only the inlets/outlets that really need to propagate events or data be set reactive.)

j-bresson commented 3 years ago

Also (just out of curiosity) do you really need that store box in this patch ? If this is just to display the result of om-random you can just use a simple number box with an inlet. :)