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 http://www.sleazeArt.com

    • 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 http://www.sleazeArt.com
    • 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 http://www.sleazeArt.com
    • 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 http://www.sleazeArt.com
    • 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 http://www.sleazeArt.com
    • 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 http://www.sleazeArt.com
    • 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 http://www.sleazeArt.com
    • 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| http://www.dspaudio.com/ http://www.castine.de
    • 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 http://www.sleazeArt.com
    • Feb 21 2007 | 11:56 am