pattrstorage save?


    Feb 19 2007 | 9:49 am
    Hi
    i just started using the pattr family - for a long time I used a home
    made system for my presets, based on coll
    with coll one have the option to save the content of the coll with
    the patch, either by typing command-i and choosing this option or by
    sending a message [flags 1 0] to the coll (which i send to my colls
    on closebang)
    is there such an option/possibility with pattrstorage ???
    I of course know I can write the prests file to disk (and even edit
    it in text mode) but on many occasions (mainly when giving my max
    instruments to other musicians, working on their computers, and not
    always very "au courant" of file management) I would prefer to save
    the patch/instrument/data as one file, as one max patch.
    I don't seem to be able to find such an option with pattrstorage - if
    it does not exist I would call it a feature request
    many thanks
    best
    kasper
    --
    Kasper T. Toeplitz
    noise, composition, bass, computer

    • Feb 19 2007 | 10:44 am
      Nope, it doesn't exist at this time.
      jb
      Am 19.02.2007 um 10:49 schrieb Kasper T Toeplitz:
      > I don't seem to be able to find such an option with pattrstorage -
      > if it does not exist I would call it a feature request
    • Feb 19 2007 | 11:05 am
      >Nope, it doesn't exist at this time.
      >
      >jb
      >
      >Am 19.02.2007 um 10:49 schrieb Kasper T Toeplitz:
      >
      >>I don't seem to be able to find such an option with pattrstorage -
      >>if it does not exist I would call it a feature request
      >
      >
      It would be a GREAT idea to add it, just as it is in coll...
      thanks
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 19 2007 | 11:20 am
      It has been discussed internally at various times. Can't say when, if
      ever, it will be implemented, though.
      jb
      Am 19.02.2007 um 12:05 schrieb Kasper T Toeplitz:
      > It would be a GREAT idea to add it, just as it is in coll...
    • Feb 19 2007 | 10:37 pm
      Kasper T Toeplitz wrote:
      > I of course know I can write the prests file to disk (and even edit it
      > in text mode) but on many occasions (mainly when giving my max
      > instruments to other musicians, working on their computers, and not
      > always very "au courant" of file management) I would prefer to save the
      > patch/instrument/data as one file, as one max patch.
      Did you try to include the xml file into a collective? For sure it would
      work with standalones...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Feb 19 2007 | 11:16 pm
      I think it's good to explore pattrstorage, but, I found coll to work much faster. Dunno if that's improved at all. I probably shouldn't be saying this, because, if asked, I would be too lazy to supply examples =)
    • Feb 20 2007 | 9:22 am
      >
      >>I of course know I can write the prests file to disk (and even edit
      >>it in text mode) but on many occasions (mainly when giving my max
      >>instruments to other musicians, working on their computers, and not
      >>always very "au courant" of file management) I would prefer to save
      >>the patch/instrument/data as one file, as one max patch.
      >
      >Did you try to include the xml file into a collective? For sure it
      >would work with standalones...
      >
      standalone is not an option - imagine working with 5 musicians and ,
      for every tried change during rehearsal having to create a standalone
      - I would have to hire an assistant who would only create (and
      install on different computers) new collectives!!!
      I will rather try (today) to find a way with automatic dump of this
      data to a coll (that should be easy) and automatic reload of it at
      loadbang (??? not sure yet if this is ppossible)
      best
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 20 2007 | 9:24 am
      >I think it's good to explore pattrstorage, but, I found coll to work
      >much faster. Dunno if that's improved at all. I probably shouldn't
      >be saying this, because, if asked, I would be too lazy to supply
      >examples =)
      interesting
      however the interpolation option in pattrstorage is really easy to
      handle (with a coll that would mean either a lot of lines or maybe
      going through jitter....
      best
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 20 2007 | 10:20 am
      why not just make the xml file save itself ?
      (not saying that i don't think i would be a nice feature)
    • Feb 20 2007 | 10:43 am
      >why not just make the xml file save itself ?
      >(not saying that i don't think i would be a nice feature)
      you mean something happening with a closebang, saving the file (and
      reopening/loading it at loadbang) ?
      yes of course, but as said on my first mail, i often work with
      musicians, using their own (or my) computers to run patches whose
      portions are written by me. Everybody is not so "fluent" with the
      files management to really take care to where to put files etc etc -
      that's why i often give them parts of patches as independent small
      patches (in patch form, not text), and they combine those.
      so having ONE patch representing a module (which they use a little
      bit as a module of a modular synth) is much more easy than a patch
      AND a text file.
      Sure, one text file is not much. many text files is more
      organisation. but a text file saved in a patch is much easier (and
      then no worries about the given names and pathes)
      since it does exist in coll, I thought it would be not difficult to
      implement in pattrstorage (which is about storage, isn't it??) - and
      i don't see how it could break anythinhg in any existing patch.
      but then i am not a developer!
      best
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 20 2007 | 10:59 am
      It's not a question of it being difficult to implement, but there are
      some considerations in terms of patch size and the fact that the
      current patch format doesn't have any way to include non-patch
      elements -- I would have to convert the XML into #X messages, and
      this would be, although not terribly hard, annoying. Then there's the
      question of character encoding.
      This is not going to happen anytime soon, if ever, so I would either
      look at a solution with the coll object or educate your musicians
      better, so that they can handle a few files...
      jb
      Am 20.02.2007 um 11:43 schrieb Kasper T Toeplitz:
      > since it does exist in coll, I thought it would be not difficult to
      > implement in pattrstorage (which is about storage, isn't it??) -
      > and i don't see how it could break anythinhg in any existing patch.
      >
      > but then i am not a developer!
    • Feb 20 2007 | 11:06 am
      hello kasper,
      how about storing the contents of the psto-xml-file in a coll with
      the patcher, then write it to /tmp on loadbang and read it in with
      psto. i've successfully used this technique with javascripts which
      suffer from the same lack of embeddability ;)
      you can use the outputmode of pattrstorage and/or the dump command to
      get it's contents into the coll automatically.
      just a thought
      /*j
      On 20 Feb 2007, at 11:43, Kasper T Toeplitz wrote:
      >> why not just make the xml file save itself ?
      >> (not saying that i don't think i would be a nice feature)
      >
      > you mean something happening with a closebang, saving the file (and
      > reopening/loading it at loadbang) ?
      >
      > yes of course, but as said on my first mail, i often work with
      > musicians, using their own (or my) computers to run patches whose
      > portions are written by me. Everybody is not so "fluent" with the
      > files management to really take care to where to put files etc etc
      > - that's why i often give them parts of patches as independent
      > small patches (in patch form, not text), and they combine those.
      >
      > so having ONE patch representing a module (which they use a little
      > bit as a module of a modular synth) is much more easy than a patch
      > AND a text file.
      >
      > Sure, one text file is not much. many text files is more
      > organisation. but a text file saved in a patch is much easier (and
      > then no worries about the given names and pathes)
      >
      > since it does exist in coll, I thought it would be not difficult to
      > implement in pattrstorage (which is about storage, isn't it??) -
      > and i don't see how it could break anythinhg in any existing patch.
      >
      > but then i am not a developer!
      >
      > best
      >
      > kasper
      > --
      > Kasper T. Toeplitz
      > noise, composition, bass, computer
      > http://www.sleazeArt.com
      >
      > http://www.myspace.com/sleazeart
      >
      >
    • Feb 20 2007 | 11:33 am
      > so I would either look at a solution with the coll object or
      >educate your musicians better, so that they can handle a few files...
      >
      >
      a solution with coll seems the way to go - educating a musician is
      way beyond what one can handle (and i tried, belive me!)
      best
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 20 2007 | 11:34 am
      >
      >
      >how about storing the contents of the psto-xml-file in a coll with
      >the patcher, then write it to /tmp on loadbang and read it in with
      >psto. i've successfully used this technique with javascripts which
      >suffer from the same lack of embeddability ;)
      >
      >you can use the outputmode of pattrstorage and/or the dump command
      >to get it's contents into the coll automatically.
      >
      exactly what i had in mind - and will try to do it today/tomorrow (etc)
      thanks
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 20 2007 | 11:37 am
      Collectives are not that hard to maintain. Like so many things, the
      first time it may seem a little mysterious (or frightening, or
      exciting...). It becomes routine a lot faster than most other things
      that are mysterious (or frightening, or exciting...)
      It's just one extra step. But yes, I understand that when rehearsing,
      every extra step can be lost time.
      --
      I know that embedding non-Max data inside a patch is tedious. I did
      it for ice.lattice. Yeah, it bloats the patch files, but makes life a
      little easier for users. Jeremy, if you can someday find the time &c.
      to go that extra mile, I'm sure many, many users would be grateful to
      you.
      Unfortunately, the fun things to program aren't always what people
      find useful and the useful things aren't always fun to program. Don't
      you just hate that?
      On 20-Feb-2007, at 11:43, Kasper T Toeplitz wrote:
      >> why not just make the xml file save itself ?
      >> (not saying that i don't think i would be a nice feature)
      >
      > you mean something happening with a closebang, saving the file (and
      > reopening/loading it at loadbang) ?
      >
      > yes of course, but as said on my first mail, i often work with
      > musicians, using their own (or my) computers to run patches whose
      > portions are written by me. Everybody is not so "fluent" with the
      > files management to really take care to where to put files etc etc
      > - that's why i often give them parts of patches as independent
      > small patches (in patch form, not text), and they combine those.
      >
      > so having ONE patch representing a module (which they use a little
      > bit as a module of a modular synth) is much more easy than a patch
      > AND a text file.
      >
      > Sure, one text file is not much. many text files is more
      > organisation. but a text file saved in a patch is much easier (and
      > then no worries about the given names and pathes)
      >
      > since it does exist in coll, I thought it would be not difficult to
      > implement in pattrstorage (which is about storage, isn't it??) -
      > and i don't see how it could break anythinhg in any existing patch.
      >
      > but then i am not a developer!
      >
      > best
      >
      > kasper
      > --
      > Kasper T. Toeplitz
      > noise, composition, bass, computer
      > http://www.sleazeArt.com
      >
      > http://www.myspace.com/sleazeart
      >
      -------------- 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 20 2007 | 11:57 am
      I certainly understand why this might be desirable. I'm just being
      realistic: it's not on the schedule at the moment!
      jb
      Am 20.02.2007 um 12:37 schrieb Peter Castine:
      > Collectives are not that hard to maintain. Like so many things, the
      > first time it may seem a little mysterious (or frightening, or
      > exciting...). It becomes routine a lot faster than most other
      > things that are mysterious (or frightening, or exciting...)
      >
      > It's just one extra step. But yes, I understand that when
      > rehearsing, every extra step can be lost time.
      >
      > --
      >
      > I know that embedding non-Max data inside a patch is tedious. I did
      > it for ice.lattice. Yeah, it bloats the patch files, but makes life
      > a little easier for users. Jeremy, if you can someday find the time
      > &c. to go that extra mile, I'm sure many, many users would be
      > grateful to you.
      >
      > Unfortunately, the fun things to program aren't always what people
      > find useful and the useful things aren't always fun to program.
      > Don't you just hate that?
    • Feb 20 2007 | 3:06 pm
    • Feb 21 2007 | 11:02 am
      >here's a solution using the psto-xml file written into a coll and
      >read back in at loadtime.
      >
      thanks - i think i understood how it works - you write a xml file
      than you immediately read (by text) and dump to a coll.
      some questions to make it clearer:
      _ the path "write /private/tmp/temp.xml" works on my computer as well
      (a mac, with french system). It means it is some path understood by
      ALL computers???
      _ this "private/tmp/" zone is, if i understand well, a temporary
      zone, the xml file is not really written to the hard disk, it just
      stays in some Ram or something?
      _ if so, what happens when you save 2 patches/presets (in the same
      max session) ? from what i saw you can save both - but then how does
      the system know than temp.xml is different from temp.xml ???
      thanks
      & best
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Feb 21 2007 | 11:56 am