2 UI-related feature requests


    Apr 10 2007 | 11:33 am
    To the Cycling elves, as you are feverishly working on Max 5:
    Feature Request #1: Ability to group/ungroup clusters of UI (or any?) objects.
    Feature Request #2: When selecting a patcher to use in a bpatcher,
    allow one to select a named object in that patcher, to whose size the
    bpatcher snaps to.
    Thanks,
    Dan
    --
    Dan Nigrin
    Defective Records
    202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major
    Malfunction
    http://www.defectiverecords.com

    • Apr 10 2007 | 12:12 pm
      Is max 5 under heavy development right now?
    • Apr 10 2007 | 2:32 pm
      Yes, they're working on max 5 now. I don't really know much about it, pity.
      I might use the first requested feature, and it certainly wouldn't hurt people who don't use it.
      The second feature I have more doubts about. What you want to do can be made in a way (for example, an empty jsui object with a getSize function in it. Use the output to script the bpatcher size) I tried it out, here's the jsui, save as sizer.js:
      function getSize(){
      outlet(0, sketch.size);
      }
      and then use a bpatcher with this in it:
      I agree, it's a lot more work, and you'll have to make the jsui the same size as the gui element. However, i'm not entirely sure if just convenience is enough reason for a separate object or function in Max (yes, idealist).
      I wouldn't mind if cycling made the second feature also (i'd use it), but I don't think it will be high on their priority list. There are a couple other things about bpatcher which are more important in my opinion.
    • Apr 10 2007 | 2:57 pm
      I'm fairly certain the 2nd feature is already implemented as JS in jamoma.
    • Apr 10 2007 | 3:35 pm
      >I wouldn't mind if cycling made the second feature also (i'd use
      >it), but I don't think it will be high on their priority list. There
      >are a couple other things about bpatcher which are more important in
      >my opinion.
      Thanks for the little JSUI hack, nice trick.
      My thought re: this feature request was that it would hopefully be a
      relatively easy thing for Cycling to implement. I agree it's simply
      for convenience, but in general, when I find myself doing things over
      and over again in Max, it strikes me that the overall usability will
      increase a lot if that little convenience is there...
      Thanks,
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major
      Malfunction
      http://www.defectiverecords.com
    • Apr 10 2007 | 3:55 pm
    • Apr 14 2007 | 4:36 am
      Dan Nigrin schrieb:
      > Feature Request #1: Ability to group/ungroup clusters of UI (or
      > any?) objects.
      Yes agreed...
      > Feature Request #2: When selecting a patcher to use in a bpatcher,
      > allow one to select a named object in that patcher, to whose size the
      > bpatcher snaps to.
      I don't see the need of that.
      > My thought re: this feature request was that it would hopefully be a
      > relatively easy thing for Cycling to implement. I agree it's simply
      > for convenience, but in general, when I find myself doing things over
      > and over again in Max, it strikes me that the overall usability will
      > increase a lot if that little convenience is there...
      Is it possible, that you didn't come across prototypes yet?
      Whenever I have a bpatcher that I use more often, I create a bpatcher
      prototype, and that is much much more convenient than your request...
      But for the bpatcher I have a feature request: an object that allows to
      resize objects inside the bpatcher according to the size of the
      bpatcher: for example have a slider adapt to the size of the bpatcher.
      Then if the first request for grouping is implemented, this could be
      enhanced to the spacing of the group...
      This is probably also possible with js though...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Apr 14 2007 | 10:52 am
      Quote: jamez wrote on Tue, 10 April 2007 06:12
      ----------------------------------------------------
      > Is max 5 under heavy development right now?
      ----------------------------------------------------
      no jamez, they make max 6 first.
      i have a request too: a small update to the rangeslider
      which lets us set a 24 bit background color instead of that
      shit pixel look.
      when i think about it, this ugly look of rangeslider once
      caused a 110-ish breakthrough in things GUI design.
      i started abusing other objects, makeing god use of ubutton,
      and working with lcd.
    • Apr 14 2007 | 10:56 am
      > But for the bpatcher I have a feature request: an object that allows to
      > resize objects inside the bpatcher according to the size of the
      > bpatcher: for example have a slider adapt to the size of the bpatcher.
      > Then if the first request for grouping is implemented, this could be
      > enhanced to the spacing of the group...
      >
      > This is probably also possible with js though...
      thats possible with sending messages to (named) objects.
      didnt someone here do such bpatchers sliders around 200 or so?
    • Apr 14 2007 | 11:55 am
      >>Feature Request #2: When selecting a patcher to use in a bpatcher,
      >>allow one to select a named object in that patcher, to whose size
      >>the
      >>bpatcher snaps to.
      >
      >I don't see the need of that.
      >
      >Is it possible, that you didn't come across prototypes yet?
      >Whenever I have a bpatcher that I use more often, I create a
      >bpatcher prototype, and that is much much more convenient than your
      >request...
      Prototypes would help me if I always wanted to use a bpatcher with
      the same size, and using the same patcher that it is linked to. What
      I find myself doing is using lots of bpatchers, of all different
      sizes, and all of which use different underlying patchers. So a
      prototype won't help.
      >But for the bpatcher I have a feature request: an object that allows
      >to resize objects inside the bpatcher according to the size of the
      >bpatcher: for example have a slider adapt to the size of the
      >bpatcher.
      This is sort of the inverse of what I am asking for; you want to
      resize the underlying objects based on the size of the bpatcher, I
      want to size the bpatcher based on the underlying named object (or if
      request #1 is satisfied, named group of objects).
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major
      Malfunction
      http://www.defectiverecords.com
    • Apr 14 2007 | 1:31 pm
      Did you have a look at Matt Aidekman's jsui objects ? If I remember well, there's something called bpatch tab which may help. I wanted to have a closer look at it to make some panels which would fit the size of a patcher but don't have the time these days. I think Matt's solution could be a good start if not the solution.
      Best,
      Julien.
      Quote: Dan Nigrin wrote on Sat, 14 April 2007 13:55
      ----------------------------------------------------
      >
      > This is sort of the inverse of what I am asking for; you want to
      > resize the underlying objects based on the size of the bpatcher, I
      > want to size the bpatcher based on the underlying named object (or if
      > request #1 is satisfied, named group of objects).
      >
      > Dan
    • Apr 14 2007 | 1:41 pm
      Sorry. Couldn't find the site while writing the message but finally found it. Here :
      Best,
      Julien
      Quote: jln wrote on Sat, 14 April 2007 15:31
      ----------------------------------------------------
      > Did you have a look at Matt Aidekman's jsui objects ?
    • Apr 14 2007 | 2:45 pm
      At 3:31 PM +0200 4/14/07, jln wrote:
      >Did you have a look at Matt Aidekman's jsui objects ? If I remember
      >well, there's something called bpatch tab which may help. I wanted
      >to have a closer look at it to make some panels which would fit the
      >size of a patcher but don't have the time these days. I think Matt's
      >solution could be a good start if not the solution.
      Thanks - I've looked at Matt's stuff before, but will re-look at again.
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major
      Malfunction
      http://www.defectiverecords.com
    • Apr 16 2007 | 9:07 am
      Roman Thilenius schrieb:
      > thats possible with sending messages to (named) objects.
      >
      > didnt someone here do such bpatchers sliders around 200 or so?
      It was about getting the size of the bpatcher if you change it while
      patching, not about resizing the internal sliders, thats trivial once
      you have that info...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Apr 16 2007 | 9:08 am
      Dan Nigrin schrieb:
      > Prototypes would help me if I always wanted to use a bpatcher with the
      > same size, and using the same patcher that it is linked to. What I find
      > myself doing is using lots of bpatchers, of all different sizes, and all
      > of which use different underlying patchers. So a prototype won't help.
      But what is the advantage, to type in the name of an object is so much
      more time consuming than just adjusting the size, and moving the
      viewpoint with cmd-shift with the mouse, also no need to prepare the
      patcher with anchors...
      Maybe you come across the problem that you're changing the origin of a
      patcher while developing, therefore there is the command "restore
      origin" in the view menu...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Apr 16 2007 | 11:55 am
      At 11:08 AM +0200 4/16/07, Stefan Tiedje wrote:
      >Dan Nigrin schrieb:
      >>Prototypes would help me if I always wanted to use a bpatcher with
      >>the same size, and using the same patcher that it is linked to.
      >>What I find myself doing is using lots of bpatchers, of all
      >>different sizes, and all of which use different underlying
      >>patchers. So a prototype won't help.
      >
      >But what is the advantage, to type in the name of an object is so
      >much more time consuming than just adjusting the size, and moving
      >the viewpoint with cmd-shift with the mouse, also no need to prepare
      >the patcher with anchors...
      The advantage would come for me when I frequently adjust the size of
      the "target" object (the one I want to be displayed in the bpatcher)
      as I am developing. So just naming that object, and specifying it
      once in the proposed bpatcher inspector field where I could supply
      this name) would always keep the bpatcher size "in sync" with the
      size of the object, with no extra work...
      >Maybe you come across the problem that you're changing the origin of
      >a patcher while developing, therefore there is the command "restore
      >origin" in the view menu...
      Yes, but see above - even if I don't move the origin when editing the
      patcher, I still have to do frequent resizes of the bpatcher
      currently...
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major
      Malfunction
      http://www.defectiverecords.com
    • Apr 16 2007 | 7:54 pm
      Quote: Stefan Tiedje wrote on Mon, 16 April 2007 03:07
      ----------------------------------------------------
      > Roman Thilenius schrieb:
      > > thats possible with sending messages to (named) objects.
      > >
      > > didnt someone here do such bpatchers sliders around 200 or so?
      >
      > It was about getting the size of the bpatcher if you change it while
      > patching, not about resizing the internal sliders, thats trivial once
      > you have that info...
      >
      > Stefan
      yeah i got t hat wrong, but now i dont get dan
    • Apr 17 2007 | 1:07 am
      >yeah i got t hat wrong, but now i dont get danZs request anymore. :)
      >
      >what is so much work about resizing a bpatcher by hand? ...
      I use many bpatchers, often very close together (e.g. vertical faders
      used in a "mixing board" kind of layout). I don't like to have my
      bpatcher's bounds extend far beyond the UI elements contained in the
      underlying patcher, because then it makes precise alignment between
      those multiple bpatchers more difficult. Therefore, I like to keep
      my bpatchers very "tight" around the underlying graphic elements.
      Doing that precisely is a pain, and I often make mistakes of a pixel
      or two, and that screws up the look of my layouts. Thus my request.
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major
      Malfunction
      http://www.defectiverecords.com
    • Apr 17 2007 | 2:39 am
      At 9:07 PM -0400 4/16/07, Dan Nigrin wrote:
      >Doing that precisely is a pain, and I often make mistakes of a pixel or two, and that screws up the look of my layouts. Thus my request.
      While this isn't really what you asked for, don't forget text mode. If you're handy with a text editor, particularly one like BBEdit which has good search & replace, you can make wholesale changes fairly easily.
      If you look at a line that creates a bpatcher:
      first two numbers after the bpatcher are position [e.g. 200 234]
      second two are size [160 150]
      third two are offset [-10 -55]
      Name of patcher [PatcherName.pat]
      flags [0]
      Patcher args [arg1 arg2]
      -C
      --
      Chris Muir | "There are many futures and only one status quo.
      cbm@well.com | This is why conservatives mostly agree,
      http://www.xfade.com | and radicals always argue." - Brian Eno
    • Apr 17 2007 | 9:02 am
    • Apr 17 2007 | 9:32 am
      okay, so i see now why this request.
      danmed true Dan that it is getting difficult with many
      very small bpatchers.
      since i use a non-apple mouse on some machines i know
      how it can hurt when pixel-excat editing doesnt work,
      especially in maxmsp and photoshop i regulary shout at
      my mouse when it refuses to let me move something to
      "1217/433"
      the suggested method to edit the bpatcher size using a
      text editor seems close to a perfect solution ... but
      it brings up the question how search-and-replace in
      "text mode" could be done more easy while programming
      in max in general.
      i would use (external) text editing much more often if
      it would not always require you to save as text, close
      the patch, edit the text in bbedit, open the patch again
      and save it over its last version ... thats 5 annoying
      steps man ..
      if there would be a funtion inside maxmsp called
      "seach for "20" in all lines starting with "#P bpatcher" "
      that would make things easier.
    • Apr 17 2007 | 12:41 pm
      I agree with Roman, that although Chris' suggestion to use a text
      editor to tweak the bpatchers' sizes is a good one, it's too clunky
      for me to think about using on a regular basis.
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major
      Malfunction
      http://www.defectiverecords.com
    • Apr 18 2007 | 11:23 am
      Dan Nigrin schrieb:
      > I agree with Roman, that although Chris' suggestion to use a text editor
      > to tweak the bpatchers' sizes is a good one, it's too clunky for me to
      > think about using on a regular basis.
      I think this whole request should be easily achievable with js, place
      two named objects, lets say upleft and loweright, let the js find their
      positions, then resize its parent according to that info. No more
      restore origin necessary after that....
      I would not trigger the resizing on loadbang though, this is only
      necessary while patching, once its set, its fine, trigger with a global
      [r esizebpatchers] or something...
      I am not fluid enough in js to do it in five minutes, but with the
      existing examples it should be possible to hack it together...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Apr 18 2007 | 10:09 pm
      Quote: Stefan Tiedje wrote on Wed, 18 April 2007 23:23
      ----------------------------------------------------
      > I think this whole request should be easily achievable with
      > js, place two named objects, lets say upleft and loweright,
      > let the js find their positions, then resize its parent
      > according to that info.
      Further: connect a patchergs object to the js object.
      Then the named object(s) to use as size reference could then be inherited from @TL and @BR attributes supplied to the bpatcher. So you're not dependent on specific names...
    • Apr 19 2007 | 10:05 am
      John Pitcairn schrieb:
      > Further: connect a patchergs object to the js object. Then the named
      > object(s) to use as size reference could then be inherited from @TL
      > and @BR attributes supplied to the bpatcher. So you're not dependent
      > on specific names...
      but naming two objects in the main patcher once, is much less hassle
      than adding arguments to a bpatcher...
      And specific names don't hurt at all for this purpose...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com