Kasper

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 

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

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)

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

kasper
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

pattrstorage-save

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

> 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


>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...

>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...

It has been discussed internally at various times. Can't say when, if 

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...

It has been discussed internally at various times. Can't say when, if  
ever, it will be implemented, though.

> It would be  a GREAT idea to add it, just as it is in coll...


> 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 

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


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 =)

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 =)


>>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 

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)

>
>>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)

>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 

however the interpolation option in pattrstorage is really easy to 

handle (with a coll that would mean either a lot of lines or maybe 

>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 =)

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....

why not just make the xml file save itself ? 

(not saying that i don't think i would be a nice feature)

why not just make the xml file save itself ? 
(not saying that i don't think i would be a nice feature)


>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 

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 

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.

>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.

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 

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...

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.

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...

> 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!


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.

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 

> 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 

> 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)

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.

>> 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
>
>


> 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!)

>  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!)

>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)

>
>
>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.
>

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, 

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 

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 

On 20-Feb-2007, at 11:43, Kasper T Toeplitz wrote:

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

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?

>> 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

I certainly understand why this might be desirable. I'm just being 

realistic: it's not on the schedule at the moment!

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 

> Unfortunately, the fun things to program aren't always what people 

> find useful and the useful things aren't always fun to program. 

I certainly understand why this might be desirable. I'm just being  
realistic: it's not on the schedule at the moment!

> 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?


>here's a solution using the psto-xml file written into a coll and 

thanks - i think i understood how it works - you write a xml file 

than you immediately read (by text) and dump to a coll.

_ 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 

_ 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 

_ 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 ???

>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.

_ 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 ???

pattrstorage save?