Feature Request: value object


    Feb 13 2007 | 9:15 pm
    It would be great if value could receive a "refer" message to change the value it is referring to, similar to the way coll works.
    For example, using [value #0_myValue] inside a subpatcher works as expected in the context of a larger patch that contains other #0_ objects.
    But once you save it as an abstraction and use it in the same patch, it creates its own instance number, separate from that of the larger patch.
    There are workarounds, but it would be nice if could behave like coll in such cases.

    • Feb 13 2007 | 11:47 pm
      I'll add to a feature request thats been on my mind.
      variable support in expr.
      expr $i1 + var(myVariable)* 2
      also coll support.
      expr $f1+$f2+coll(myColl,myEntry,myAtom)
      basically expr should be like the right side of an assignment line of
      code.
      OR include the same type of thing after # characters
      split 4 #var(myvariable)
    • Feb 14 2007 | 12:47 am
      well, you could create an abstraction that contains a scripted value which is deleted, remade, rewired, when a refer message is sent to it.
      I'd call it dynaValue.
    • Feb 14 2007 | 12:57 am
      > well, you could create an abstraction that contains a scripted
      > value which is deleted, remade, rewired, when a refer message is
      > sent to it.
      True.
      But I would hesitate to use scripting to create internal objects within
      essentially hidden subpatchers.
      I simply don't trust it.
    • Feb 14 2007 | 12:59 am
      hrm, well try it out at least. better than waiting for someone to code the bugger. Outside of scripting I don't see that there's a way, albeit I haven't read the value documentation in forever.
    • Feb 14 2007 | 1:22 am
      > Outside of scripting I don't see that there's a way
      Right now, I use #1 as the value name inside the abstraction (as
      opposed to #0). Then I pass, as an arguement, #0_myvalue.
      In the various instances, the #0 is converted into the instance number
      in the arguement, which is then correct inside the abstraction itself.
      As I said, it is a workaround, and it works fine, but I'm suggesting
      some consistency between data objects.
    • Feb 14 2007 | 9:42 am
      Quote: arne wrote on Wed, 14 February 2007 01:57
      ----------------------------------------------------
      > > well, you could create an abstraction that contains a scripted
      > > value which is deleted, remade, rewired, when a refer message is
      > > sent to it.
      How about defining a global variable in javascript and binding another javascript to it. Like so:
      ------- save as 'value.js'
      autowatch = 1;
      var name = null;
      g = new Global("jsvalue");
      function addValue(name, value)
      {
      if (g[name]) pst("error: value already exists");
      else
      {
      g[name] = value;
      this.name = name;
      }
      }
      function refer(name)
      {
      this.name = name
      if (g[name]) bang();
      else pst("error: value doesn't exist");
      }
      function bang()
      {
      if (name)
      outlet(0, g["" + name]);
      else
      pst("error: is not referring to a value");
      }
      function pst(v)
      {
      post(v);
      post();
      }
      function anything()
      {
      if (name)
      {
      var a = arrayfromargs(messagename,arguments);
      g["" + name] = a;
      }
      else
      pst("error: is not referring to a value");
      }
      ------- save as anything:
    • Feb 14 2007 | 4:09 pm
      On Feb 14, 2007, at 1:42 AM, Mattijs Kneppers wrote:
      > How about defining a global variable in javascript and binding
      > another javascript to it. Like so:
      Whoa.
      I've tended to avoid learning and using javascript, since I seem to
      remember reading on this list that there is a CPU hit in going from
      Max to JS and back again.
      Urban myth? Inconsequential difference?
      What say you, oh javascript master?
    • Feb 14 2007 | 4:33 pm
      depends on what CPU you have. I mean, with a core 2 duo or a woodcrest processor,... don't even worry about it. Not that there was even so much as a chip off my old athlon 3000.
    • Feb 14 2007 | 5:18 pm
      Ha!
      Urban myth.
      On Feb 14, 2007, at 4:09 PM, Arne Eigenfeldt wrote:
      >
      > On Feb 14, 2007, at 1:42 AM, Mattijs Kneppers wrote:
      >
      >> How about defining a global variable in javascript and binding
      >> another javascript to it. Like so:
      >
      > Whoa.
      >
      > I've tended to avoid learning and using javascript, since I seem to
      > remember reading on this list that there is a CPU hit in going from
      > Max to JS and back again.
      >
      > Urban myth? Inconsequential difference?
      >
      > What say you, oh javascript master?
    • Feb 14 2007 | 7:41 pm
      On 14-Feb-2007, at 18:18, evan.raskob [lists] wrote:
      > Urban myth.
      Offhand I'm not sure about JScript, but there is a measurable
      performance hit in switching between Max and Java contexts. In many
      situations the hit would qualify as inconsequential. But it is there
      and as much of an urban myth as Bernhard Goetz.
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      Universal Binaries on the way
      iCE: Sequencing, Recording &
      Interface Building for |home | chez nous|
      Max/MSP Extremely cool |bei uns | i nostri|
    • Feb 15 2007 | 9:22 am
      Quote: arne wrote on Wed, 14 February 2007 17:09
      ----------------------------------------------------
      >
      > On Feb 14, 2007, at 1:42 AM, Mattijs Kneppers wrote:
      >
      > > How about defining a global variable in javascript and binding
      > > another javascript to it. Like so:
      >
      > Whoa.
      >
      > I've tended to avoid learning and using javascript, since I seem to
      > remember reading on this list that there is a CPU hit in going from
      > Max to JS and back again.
      >
      > Urban myth? Inconsequential difference?
      >
      > What say you, oh javascript master?
      Whoa, plz, not so much honor. All I do is studying the cycling documentation and this website http://javascript-reference.info/
      My opinion about the speed issue: when I make something in js I always promise myself to do it in C as soon as I have the time. I never have the time, so I end up using js. I never researched the speed drawback but my patches do run on mac pro 4 x 2,7 ghz computers ;)
      Mattijs
    • Feb 15 2007 | 9:50 am
      I documented the speed issues at one point with Josh Goldbergs class
      last year - no idea how correct this is, but it might be of interest.
      Forgive the obnoxious comments - Half notes for the class, half
      'performance' notes for myself when giving the overview.
      On my Macbook Pro (and on my Powerbook G4), I get that JS is between
      4.5 to 2 times slower depending what you are doing.
      Note that, this is the most simplistic and non scientific test... ever.
      
      On Feb 15, 2007, at 4:22 AM, Mattijs Kneppers wrote:
      >
      > Quote: arne wrote on Wed, 14 February 2007 17:09
      > ----------------------------------------------------
      >>
      >> On Feb 14, 2007, at 1:42 AM, Mattijs Kneppers wrote:
      >>
      >>> How about defining a global variable in javascript and binding
      >>> another javascript to it. Like so:
      >>
      >> Whoa.
      >>
      >> I've tended to avoid learning and using javascript, since I seem to
      >> remember reading on this list that there is a CPU hit in going from
      >> Max to JS and back again.
      >>
      >> Urban myth? Inconsequential difference?
      >>
      >> What say you, oh javascript master?
      >
      > Whoa, plz, not so much honor. All I do is studying the cycling
      > documentation and this website http://javascript-reference.info/
      >
      > My opinion about the speed issue: when I make something in js I
      > always promise myself to do it in C as soon as I have the time. I
      > never have the time, so I end up using js. I never researched the
      > speed drawback but my patches do run on mac pro 4 x 2,7 ghz
      > computers ;)
      >
      > Mattijs
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Interactive audiovisual sampling soft- and hardware
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 15 2007 | 9:54 am
      Hi vade,
      That's interesting. It looks like you attached something, but I can't read it.
      Mattijs
      Quote: vade wrote on Thu, 15 February 2007 10:50
      ----------------------------------------------------
      > I documented the speed issues at one point with Josh Goldbergs class
      > last year - no idea how correct this is, but it might be of interest.
      >
      > Forgive the obnoxious comments - Half notes for the class, half
      > 'performance' notes for myself when giving the overview.
      >
      > On my Macbook Pro (and on my Powerbook G4), I get that JS is between
      > 4.5 to 2 times slower depending what you are doing.
      >
      > Note that, this is the most simplistic and non scientific test... ever.
      >
      > 
      > On Feb 15, 2007, at 4:22 AM, Mattijs Kneppers wrote:
      >
      > >
      > > Quote: arne wrote on Wed, 14 February 2007 17:09
      > > ----------------------------------------------------
      > >>
      > >> On Feb 14, 2007, at 1:42 AM, Mattijs Kneppers wrote:
      > >>
      > >>> How about defining a global variable in javascript and binding
      > >>> another javascript to it. Like so:
      > >>
      > >> Whoa.
      > >>
      > >> I've tended to avoid learning and using javascript, since I seem to
      > >> remember reading on this list that there is a CPU hit in going from
      > >> Max to JS and back again.
      > >>
      > >> Urban myth? Inconsequential difference?
      > >>
      > >> What say you, oh javascript master?
      > >
      > > Whoa, plz, not so much honor. All I do is studying the cycling
      > > documentation and this website http://javascript-reference.info/
      > >
      > > My opinion about the speed issue: when I make something in js I
      > > always promise myself to do it in C as soon as I have the time. I
      > > never have the time, so I end up using js. I never researched the
      > > speed drawback but my patches do run on mac pro 4 x 2,7 ghz
      > > computers ;)
      > >
      > > Mattijs
      > > --
      > > SmadSteck - http://www.smadsteck.nl
      > > Interactive audiovisual sampling soft- and hardware
      > >
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      >
      >
      >
      ----------------------------------------------------
    • Feb 15 2007 | 9:55 am
      Arne Eigenfeldt wrote:
      > As I said, it is a workaround, and it works fine, but I'm suggesting
      > some consistency between data objects.
      Its not a workaround, its the way to do it and tell value to what to
      refer to, and if you need to change the reference you'd use pattr
      instead of value... Has uncountable other advantages as well...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Feb 15 2007 | 10:05 am
      And due to my idiocy, and not using the current index for uzi (for
      some stupid reason I was using counter.. heh), I now have javascript
      being on the order of 20 times slower with outputting ints, and 8
      times slower when just iterating internally.
      Not that one would ever use code like this, but it is interesting
      none the less.
      On Feb 15, 2007, at 4:50 AM, vade wrote:
      > I documented the speed issues at one point with Josh Goldbergs
      > class last year - no idea how correct this is, but it might be of
      > interest.
      >
      > Forgive the obnoxious comments - Half notes for the class, half
      > 'performance' notes for myself when giving the overview.
      >
      > On my Macbook Pro (and on my Powerbook G4), I get that JS is
      > between 4.5 to 2 times slower depending what you are doing.
      >
      > Note that, this is the most simplistic and non scientific test...
      > ever.
      >
      >
      >
      >
      >
      > On Feb 15, 2007, at 4:22 AM, Mattijs Kneppers wrote:
      >
      >>
      >> Quote: arne wrote on Wed, 14 February 2007 17:09
      >> ----------------------------------------------------
      >>>
      >>> On Feb 14, 2007, at 1:42 AM, Mattijs Kneppers wrote:
      >>>
      >>>> How about defining a global variable in javascript and binding
      >>>> another javascript to it. Like so:
      >>>
      >>> Whoa.
      >>>
      >>> I've tended to avoid learning and using javascript, since I seem to
      >>> remember reading on this list that there is a CPU hit in going from
      >>> Max to JS and back again.
      >>>
      >>> Urban myth? Inconsequential difference?
      >>>
      >>> What say you, oh javascript master?
      >>
      >> Whoa, plz, not so much honor. All I do is studying the cycling
      >> documentation and this website http://javascript-reference.info/
      >>
      >> My opinion about the speed issue: when I make something in js I
      >> always promise myself to do it in C as soon as I have the time. I
      >> never have the time, so I end up using js. I never researched the
      >> speed drawback but my patches do run on mac pro 4 x 2,7 ghz
      >> computers ;)
      >>
      >> Mattijs
      >> --
      >> SmadSteck - http://www.smadsteck.nl
      >> Interactive audiovisual sampling soft- and hardware
      >>
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 15 2007 | 10:15 am
      Try this?
    • Feb 15 2007 | 10:29 am
      Quote: vade wrote on Thu, 15 February 2007 11:15
      ----------------------------------------------------
      >
      >
      > Try this?
      >
      >
      >
      >
      >
      ----------------------------------------------------
      Uhh.. nothing. Do you see an attachment in your submitted post? I see nothing.
    • Feb 15 2007 | 10:37 am
      I see one.
      wes
      On 2/15/07, Mattijs Kneppers wrote:
      >
      > Quote: vade wrote on Thu, 15 February 2007 11:15
      > ----------------------------------------------------
      > >
      > >
      > > Try this?
      > >
      > >
      > >
      > >
      > >
      > ----------------------------------------------------
      >
      > Uhh.. nothing. Do you see an attachment in your submitted post? I see nothing.
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Interactive audiovisual sampling soft- and hardware
      >
      >
    • Feb 15 2007 | 11:41 am
      I'm sure that JKC has a more complete explanation, but as people have
      said before this is mostly due to the spitting out ints part of the
      patch. Any data passing thru the Max/js boundary via outlets or
      inlets (same with Java) takes a decent-sized performance hit. If you
      remove the "outlet" call in js, even without overdrive on I get a
      value of ~3x slower than max (max=~55-60, js=~170). For the patch,
      instead of using timer I used cpuclock, because timer depends on the
      max scheduler apparently and I seem to get more consistent results
      with cpuclock (can someone confirm this?)
      So I would never output 1,000,000 numbers-per-bang using js.
      Comparing it to uzi is like comparing the engines of a passenger
      train and a Porsche. Each is only a piece of the puzzle. Instead, I
      would compare the result of a computational for loop in max using uzi
      vs. a computational for loop in js that only spit out the result at
      the end.
      But the patch does show the inlet/outlet penalty pretty well, so it's
      goo to show new users how NOT to use js. Here's a slightly modified
      version, comments appreciated. I might use this in a workshop.
      cheers
      evan
      On Feb 15, 2007, at 10:05 AM, vade wrote:
      > And due to my idiocy, and not using the current index for uzi (for
      > some stupid reason I was using counter.. heh), I now have
      > javascript being on the order of 20 times slower with outputting
      > ints, and 8 times slower when just iterating internally.
      >
      > Not that one would ever use code like this, but it is interesting
      > none the less.
      >
      > On Feb 15, 2007, at 4:50 AM, vade wrote:
      >
      >> I documented the speed issues at one point with Josh Goldbergs
      >> class last year - no idea how correct this is, but it might be of
      >> interest.
      >>
      >> Forgive the obnoxious comments - Half notes for the class, half
      >> 'performance' notes for myself when giving the overview.
      >>
      >> On my Macbook Pro (and on my Powerbook G4), I get that JS is
      >> between 4.5 to 2 times slower depending what you are doing.
      >>
      >> Note that, this is the most simplistic and non scientific test...
      >> ever.
      >>
      >>
      >>
      >>
      >>
      >> On Feb 15, 2007, at 4:22 AM, Mattijs Kneppers wrote:
      >>
      >>>
      >>> Quote: arne wrote on Wed, 14 February 2007 17:09
      >>> ----------------------------------------------------
      >>>>
      >>>> On Feb 14, 2007, at 1:42 AM, Mattijs Kneppers wrote:
      >>>>
      >>>>> How about defining a global variable in javascript and binding
      >>>>> another javascript to it. Like so:
      >>>>
      >>>> Whoa.
      >>>>
      >>>> I've tended to avoid learning and using javascript, since I seem to
      >>>> remember reading on this list that there is a CPU hit in going from
      >>>> Max to JS and back again.
      >>>>
      >>>> Urban myth? Inconsequential difference?
      >>>>
      >>>> What say you, oh javascript master?
      >>>
      >>> Whoa, plz, not so much honor. All I do is studying the cycling
      >>> documentation and this website http://javascript-reference.info/
      >>>
      >>> My opinion about the speed issue: when I make something in js I
      >>> always promise myself to do it in C as soon as I have the time. I
      >>> never have the time, so I end up using js. I never researched the
      >>> speed drawback but my patches do run on mac pro 4 x 2,7 ghz
      >>> computers ;)
      >>>
      >>> Mattijs
      >>> --
      >>> SmadSteck - http://www.smadsteck.nl
      >>> Interactive audiovisual sampling soft- and hardware
      >>>
      >>
      >> v a d e //
      >>
      >> www.vade.info
      >> abstrakt.vade.info
      >>
      >>
      >>
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
    • Feb 15 2007 | 12:03 pm
    • Feb 15 2007 | 3:48 pm