jit.jen example, cryptic?

    Oct 30 2011 | 1:41 am
    attached picture shows jit.gen.maxpat
    on the left is jit.gen object and to its right its insides.
    next to it my understanding of the internals of the gen. cleary wrong...
    0. whats the equivalent jit.op code ?
    1. what is [* amp] ? can we use variables(?) in max objects now?
    2.[bug?] i cannot access help files inside the jit.gen subpatch (whats the correct term again?)
    3. message [param amp pi] is not connected to any object. what is it?
    4. the help file description states that "the patcher and code describes how each cell of jit.matrix will be processed by jit.gen".
    is there code? is 'code' the keyword for gen internals?

    • Oct 30 2011 | 2:01 am
      0. Within a gen patcher, the ops are much simpler:
      [jit.op @op +] becomes [+]
      [jit.op @op + @val 1.] becomes [+ 1]
      1. Only in gen patchers. The 'amp' variable is available because it is defined by the [param amp] object. Also a few defined constants can be used, such as pi, sqrt2, e, log10e etc. See the Gen reference vignettes for the full list.
      2. There is no inline help for objects in gen patcher yet, that will come soon. Have a look at the references (under the ? tab of the jit.gen help patcher).
      3. See (1). A [param] object becomes a value that can be modified from outside the gen patcher, in this case by sending the (param amp $1) message to the jit.gen object.
    • Oct 30 2011 | 2:11 am
      thanks for the tips,
      so whats the correct unGen patch?
      doesn't deliver.
      regarding the simplified gen specific operators. from my understanding jit.op multi plane abilities are lost and gen will treat only a single plane. is this correct? or is [+ pass *] possible?
      thankx again, i understand you are still working on the docs
    • Oct 30 2011 | 2:13 am
      Hi Yair,
      The difference you're seeing is actually one of the benefits of jit.gen and the extra precision afforded by Gen patchers. Your input matrix type is char. jit.op's output will also be char, so everything will be clamped to [0, 255]. Within a Gen patcher, there is no such restriction on the range of values so negative values are permissible. Code in the sentence you cite is referring to GenExpr, the text language for Gen patchers
      Under Max help, there's a Gen vignette. Have a read through the Gen Overview and Gen Expr pages. If you have questions about it, please fire away.
    • Oct 30 2011 | 2:26 am
      oh, its float32 inside, didn't catch this as jit.cellblock [my main jitter debugging tool] is not available inside gen object. strange new world...
      anyways, to be a nag, i see no diff in CPU between them.
      with jit.gl came a few cpu Vs gpu examples who made a big impact on me. please include a few of those with Gen. it will be a good selling point/.
      @wesly, i'll get there asap
    • Oct 30 2011 | 2:30 am
      hi Yair, have you looked in the jitter-examples/gen folder? There are some benchmarking patches as well as some Gen patchers that run in both CPU and GPU with jit.pix and jit.gl.pix.
      I see a 10% difference in CPU usage, but that's using activity monitor. Really, this is not a very good way to benchmark. There's the pwindow, fpsgui, copy and conversion into the float32. It's better to specifically measure the jit.ops v. jit.gen. See the benchmarking examples for a way to do this.
    • Oct 30 2011 | 2:50 am
      not thoroughly, i did a search for jit.gen* but missed all the rest.
      on my win7/64bit/i7-920 its 4-11 times faster (especially impressive if you crank the dim up to 1920x1080).
      but these benchmarks are incomplete as they don't challenge jit.gl strategies.
      my understanding is gen code should be equal to GPU code with the added benefit of ability to translate GLSL code to some new and old max object [swiz, mix, etc].
    • Oct 30 2011 | 6:32 am
      I am really looking forward to that inline help for gen. Currently, some help patches are missing and some nodes are linked to non-gen help patches (e.g., standard operators).