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 > > ----------------------------------------------------