pvar and bpatcher - alternatives?


    Nov 21 2006 | 6:00 pm
    Hello
    Just a quick one. Im learning to love pvar and linking it to GUI
    objects to separate logic from interface (ive been all about that
    recently). Ive abstracted quite a bit of my own GUi objects into
    bpatchers, and quite obviously pvar wont work on a named bpatcher
    (or, if it should, it throws an error saying patcher doesnt
    understand message 'float', for example).
    Ive found (thanks to JBs help a week or so ago) that using a named
    but unbound pattr connected to the inlet I want to send data, and a
    named (same as pattr) pvar will basically get me what I want (as well
    as state saving too), but just out of curiosity, does anyone have any
    other alternatives?
    If not, is there a way the inlet objects could inform pvar what
    datatypes could be sent to the abstraction/bpatcher?
    Just curious.
    v a d e //
    www.vade.info
    abstrakt.vade.info

    • Nov 21 2006 | 6:31 pm
      i like a lot the use of pattrforward, maybe combined with pattrmarker.
      pattrforward also is able to adress different inlets of objects like
      bpatchers.
      cycling74 should sell 'pattr' tshirts.
      jan
    • Nov 22 2006 | 7:59 am
      vade wrote:
      > Just a quick one. Im learning to love pvar and linking it to GUI
      > objects to separate logic from interface (ive been /all/ about that
      > recently).
      I wanted to love pvar, but it has limitations: only one pvar per object
      works (has been reported, but isn't fixed as far as I know), pvar can
      have multiple oulets but not multiple inlets (needed for a filtergraph
      for example...)
      > but just out of curiosity, does anyone have any other alternatives?
      I am using pattr for single in/out objects, pvar for multiple out
      objects and pattrforward for multiple input objects.
      A pattrbackward or multiple in/out pattr would be a good idea I think...
      The pattr solution is much more flexible than the pvars, but a single
      object which could do all would be nice... (Yes this is a request... ;-)
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Nov 22 2006 | 4:14 pm
      I would probably try to put the gui object connected to a pattr inside an abstraction and control the pattr from the outside with another pattr.
      To do this, the bpatcher has to be named correctly. That might be a problem, depending on how you want to use the gui elements (e.g. add them to a patch dynamically?).
      For some reason I don't like pvar very much. It feels a bit limited.
      Illustration:
      save as 'gui';
      Note that you need the latest pattr incremental update for this to work..
      Cheers,
      Mattijs
      Quote: vade wrote on Tue, 21 November 2006 19:00
      ----------------------------------------------------
      > Hello
      >
      > Just a quick one. Im learning to love pvar and linking it to GUI
      > objects to separate logic from interface (ive been all about that
      > recently). Ive abstracted quite a bit of my own GUi objects into
      > bpatchers, and quite obviously pvar wont work on a named bpatcher
      > (or, if it should, it throws an error saying patcher doesnt
      > understand message 'float', for example).
      >
      > Ive found (thanks to JBs help a week or so ago) that using a named
      > but unbound pattr connected to the inlet I want to send data, and a
      > named (same as pattr) pvar will basically get me what I want (as well
      > as state saving too), but just out of curiosity, does anyone have any
      > other alternatives?
      >
      > If not, is there a way the inlet objects could inform pvar what
      > datatypes could be sent to the abstraction/bpatcher?
      >
      > Just curious.
      >
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      ----------------------------------------------------