< Back to IRCAM Forum

Possibility of making subgraphs in OM?

OpenMusic
#1

Hi,

I’m currently working my way through the OM tutorials, and have a question relating to tutorial 12:

I understand how the patch works. My experience with OM so far leads me to think that when evaluating in OM, the process of evaluation of the graph of objects in a patch is done according to a pull strategy: The object furthest down (the one requested to evaluate) request values from their upstream neighbours, they ask their upstream neighbours and so on to the top of the graph. The results are then passed downwards again. Such a evaluation pull request probably also has some kind of identifier, and this is what ensures that the OM_RANDOM objects in the (A)-© part of the patch only calculate new values once, but generates a new value again the next time an evaluation is requested.

If this is correct, I’m wondering if any object exists that enables you to create upstream sub-graphs. If such an object existed, and could be inserted just upstream from the three inlets of x-append, the same (A) instance could be used all three times, and one wouldn’t need three instances of it.

I’m aware that I could turn (A) into an abstraction (pardon the Max lingo here) and use three instances of it, but my question is more out of curiosity in terms of understanding how the graph structure and evaluation of graphs happens in OM, and how I might work with them programatically.

Thanks,
Trond

#2

I (or rather Anders Vinjar) found a solution to this: If sections A and D of tutorial 12 are copied and pasted into a subpatch, this subpatch can be connected to all three inlets of x-append. Each inlet will request a new evaluation of the subpatch, and hence we’ll get the same result as in the original tutorial.

So it seems that subpatches are evaluated as separate graphs.

#3

Dear Trond,

Yes , about the downstream/upstream evaluation. Remember, OM is not Max. You should always have in mind that OM is a graphical programming language based on LISP. And this is the nature of lisp. Imagine that all connections could be parenthesized. So , the “upstream” funcitons are somehowe embeded ithe “downstream” ones. By the way , stream is a bad metaphor for Lisp. This of course is more accurate for data flow languages (like in Max). In OM, you don’t have streams, let’s say its bits of functions (or programs) connected to each others.
If you take for instance this “silly” lisp expression :
(om::repeat-n (* 10 (+ 2 3)) 10)
It’s like the repeat-n is the “trunk” of the program, meaning we will have the + evaluated and the * , like if they were leeaves.
and at the end repeat-n…
Well its all evaluated at once in fact.
Hope this helps.

About the tutorial 12, of course we can do simpler. But since the omloop is not yet introduced that’s why you have three repeat-n… What should be understood in this tutorial is the eval-once mode. This is due to the om-random thing.

Best
K