pvar + bpatcher issue ?


    Jan 23 2008 | 6:09 pm
    cant [pvar] work with bpatchers ? can a bpatcher become an object [pvar] sees and talks with ?
    i have a srange behaviour :
    sending a bang from a [pvar] to a bpatcher does not work but receiving a bang from the bpatcher to the [pvar] works as expected ...
    check this patch for a clearer idea of what i mean :
    main patch :
    BPatcher :

    • Jan 24 2008 | 7:39 am
      karl-otto von oertzen schrieb:
      > cant [pvar] work with bpatchers ? can a bpatcher become an object [pvar] sees and talks with ?
      > i have a srange behaviour :
      > sending a bang from a [pvar] to a bpatcher does not work but receiving a bang from the bpatcher to the [pvar] works as expected ...
      > check this patch for a clearer idea of what i mean :
      Yes I came acorss this as well, the bang isn't sent to the patch inside
      bpatcher, but to the bpatcher object itself. The pattrforward helpfile
      explains that if you look into the inlets subpatcher. Pattrforward is
      also the solution to this problem.
      Not to compromise my beer with Jeremy, i'll propose today, as feature
      request, that we want a pattrvar object with possibly as many outputs
      AND inputs as the object we connect to...
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Jan 24 2008 | 8:53 am
      herzlichen Dank Herr Tiedje :)
      that solves it indeed .
      i am not sure Jeremy wants us to be too pushy these days , i am sure he has enough on is plate right now, but maybe not enough in his glass...
      so maybe with some beer..
      or some schnaptz ...
      we could ...
      ask for ...
      Stefan, you say it :)
      Quote: Stefan Tiedje wrote on Thu, 24 January 2008 08:39
      >
      > Yes I came acorss this as well, the bang isn't sent to the patch inside
      > bpatcher, but to the bpatcher object itself. The pattrforward helpfile
      > explains that if you look into the inlets subpatcher. Pattrforward is
      > also the solution to this problem.
      >
      > Not to compromise my beer with Jeremy, i'll propose today, as feature
      > request, that we want a pattrvar object with possibly as many outputs
      > AND inputs as the object we connect to...
      >
      > #P window setfont "Sans Serif" 9.;
      > #P window linecount 2;
      > #P message 191 148 55 196617 offset -40 -50;
      > #P window linecount 1;
      > #P message 284 148 92 196617 inx offset -40 -50;
      > #P message 268 127 77 196617 offset -40 -50;
      > #P message 176 127 77 196617 offset -10 -10;
      > #P button 248 233 15 0;
      > #P button 57 83 15 0;
      > #P button 248 155 15 0;
      > #P bpatcher 57 122 104 129 -40 -50 bang_BP 1;
      > #P objectname myBP;
      > #P newex 248 189 97 196617 pattrforward myBP;
      > #P newex 248 212 59 196617 pvar myBP;
      > #P fasten 9 0 0 0 196 209 253 209;
      > #P fasten 8 0 1 0 289 183 253 183;
      > #P fasten 7 0 1 0 273 183 253 183;
      > #P fasten 6 0 0 0 181 209 253 209;
      > #P connect 0 0 5 0;
      > #P connect 3 0 1 0;
      > #P connect 4 0 2 0;
      > #P window clipboard copycount 10;
      >
      > --
      > Stefan Tiedje------------x-------
      > --_____-----------|--------------
      > --(_|_ ----|-----|-----()-------
      > -- _|_)----|-----()--------------
      > ----------()--------www.ccmix.com
      >
      >
      >
      ----------------------------------------------------
    • Jan 24 2008 | 10:06 pm
      Quote: Stefan Tiedje wrote on Wed, 23 January 2008 23:39
      ----------------------------------------------------
      >
      > Not to compromise my beer with Jeremy, i'll propose today, as feature
      > request, that we want a pattrvar object with possibly as many outputs
      > AND inputs as the object we connect to...
      >
      Nice loophole. If you play this right, maybe you can get an additional beer for not mentioning pattrvar for a while :)
      Really though, I like this pattrvar idea better than having a separate pattrforward and that... unnameable object.
      A while back I asked for pvar to support attaching to objects that aren't in the same patch using pattrforward syntax. The difference is pvar doesn't show up in the pattrstorage list. Having the choice seems useful - sometimes I just need remote messaging and don't want to add yet another pattr to a large patch. Maybe pattrvar could handle both cases, with a @visible attribute or something.
      -Adam
    • Jan 25 2008 | 9:11 am
      Adam Murray schrieb:
      > A while back I asked for pvar to support attaching to objects that
      > aren't in the same patch using pattrforward syntax.
      I do have a bad hack in my abhaXions for that purpose, but its based on
      forward and receive. That would not give the nice clear namespace
      differentiation that a pattrvar would give. Have a look at it, its
      actually two abhaXions called svar/rvar...
      Stefan
      svar:
      rvar:
      rvar.help:
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com