importing presets in a already loaded pattrstorage?
I was wondering if there is there a way to "import" pattrstorage presets
from another file,
merging with some already loaded presets… I searched the forum but
found no hint on this issue..
And really got to a dead end trying to use the "copy" function between 2
(apart from the fact it was not working because of mutual awareness of
object, this was actually an ugly idea anyhow)
Has anyone solved this pb?
pattrstorage uses .xml files which you can edit as text.
You can load such a file with read message to pattrstorage.
Import a file from another pattrstorage implicates to named object identically.
But perhaps it is not you question ?
You would need to edit by hand to merge presets from 2 XML files.
On the other hand, this was the reason for using a more or less human-readable format for the files instead of the old preset-style binbuf, where this kind of merge would have been impossible.
I bet that you could write a ruby script in about 30 minutes to do a merge/renumber-as-necessary between 2 pattrstorage files.
Quote: jln wrote on Fri, 08 February 2008 11:44
> – From your patch, read your friend’s xml presets file;
> – dump all client’s values for every slot and store them in a coll for
> example (using whatever format which seems the more easy to deal with);
> – re-read your presets file;
> – dump the coll (or query the wanted presets) and send it to your
> pattrstorage using ‘insert’ or ‘store’ depending on how you want the
> presets to be merged;
I gave a test with this method and it seems to work. At least, it works in this small example. It needs some improvements if some lists are stored, particularly. You’ll want some dialog window as well, to choose which pattrstorage file to import. Here, the ‘myfriend.xml’ file is merged with ‘me.xml’ as demonstration purpose. Let me know if it works for you or which other option worked for you.
From what I understand the following is happening:
A certain OS doens’t allow special characters in filenames. That’s why
such externals have a different name in the file system. [*~] is
actually called times~. Max uses an alias system to load the correct
externals. these alias-files are called objectmappings and are stored
in the /Cycling ’74/init folder, where they’re scanned at startup.
have a look at audio-objectmappings.txt to see what i mean.
When building a standalone from a patch which contains such an alias-
file you might need to manually include the objectmappings file with
the collective build editor -> Include File command. Now the runtime
should be able to load this.
In my version of max 4.6.3 this doesn’t occur, so either you’re
running a different version of max or somehow your filepreferences are
Well, I solved the problem by putting an *~ object on the patch down
in the corner where it wont bother anybody. It’s just sitting there
obediently making me not get the error now. The standalone works
Weird thing, though: After successfully solving the "no such object"
problem and making a perfectly functioning standalone, I tried making
another one and started getting "error: can’t find Max/MSP Runtime"!
I looked in the Max folder, and low and behold, the RunTime app has
mysteriously vanished! I can’t imagine what happened to it between
this morning when everything was working and now, but I tried putting
a copy of it in the Max folder from a recent backup, and Max still
refuses to recognize it. I searched online and found one instance of
another person with this problem, but no one was able to answer
them. Anyone heard of this happening?
Telephone: 415.861.EARS (415.861.3277)
Mobile: 415.5PAMELA (415.572.6352)
FAX: 415.861.FAKS (415.861.3257)
(I forward my land line to my mobile phone when I’m travelling)
Skype: pamelazed AIM: pamelazdotcom
Pamela Z Productions
540 Alabama Street Studio 213
San Francisco, CA 94110, USA
shipping address (for packages larger than a 10" x 13" envelope):
Pamela Z 2440 Sixteenth Street PMB #171, San Francisco, CA 94103, USA
On Mar 23, 2008, at 3/23/08, 2:30 AM, jasch wrote:
> From what I understand the following is happening:
> A certain OS doens’t allow special characters in filenames. That’s
> why such externals have a different name in the file system. [*~]
> is actually called times~. Max uses an alias system to load the
> correct externals. these alias-files are called objectmappings and
> are stored in the /Cycling ’74/init folder, where they’re scanned
> at startup. have a look at audio-objectmappings.txt to see what i
> When building a standalone from a patch which contains such an
> alias-file you might need to manually include the objectmappings
> file with the collective build editor -> Include File command. Now
> the runtime should be able to load this.
> In my version of max 4.6.3 this doesn’t occur, so either you’re
> running a different version of max or somehow your filepreferences
> are damaged.
If you’re on OSX, maybe it’s a permissions thing? I thought I lost things because of account permissions before.