pattrstorage save?

Feb 19, 2007 at 9:49am

pattrstorage save?

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

http://www.myspace.com/sleazeart

#30337
Feb 19, 2007 at 10:44am

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

#96806
Feb 19, 2007 at 11:05am

>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

http://www.myspace.com/sleazeart

#96807
Feb 19, 2007 at 11:20am

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…

#96808
Feb 19, 2007 at 10:37pm

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

#96809
Feb 19, 2007 at 11:16pm

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

#96810
Feb 20, 2007 at 9:22am

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

http://www.myspace.com/sleazeart

#96811
Feb 20, 2007 at 9:24am

>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

http://www.myspace.com/sleazeart

#96812
Feb 20, 2007 at 10:20am

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

#96813
Feb 20, 2007 at 10:43am

>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

#96814
Feb 20, 2007 at 10:59am

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!

#96815
Feb 20, 2007 at 11:06am

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

#96816
Feb 20, 2007 at 11:33am

> 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

http://www.myspace.com/sleazeart

#96817
Feb 20, 2007 at 11:34am

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

http://www.myspace.com/sleazeart

#96818
Feb 20, 2007 at 11:37am

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

#96819
Feb 20, 2007 at 11:57am

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?

#96820
Feb 20, 2007 at 3:06pm

#96821
Feb 20, 2007 at 3:59pm

#96822
Feb 21, 2007 at 11:02am

>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

http://www.myspace.com/sleazeart

#96823
Feb 21, 2007 at 11:56am

#96824

You must be logged in to reply to this topic.