Many data to store: preset or coll?
I am working on an application that should finally store the values of about 80 GUI elements in up to 100 presets and send them out on demand as MIDI data.
I tried the "preset" object briefly, My God, that is a great thing! But I have no experience with Max and the manual states that the coll object is most versatile to store data. Well, I don't understand how coll works, yet, it looks complicated ...
The basic question:
I don't want to show the preset object in the GUI but rather make my own GUI for it. Is "preset" still the way to go or should I go for the coll object?
On 31 mars 08, at 06:36, Peter Ostry wrote:
> The basic question:
> I don't want to show the preset object in the GUI but rather make my
> own GUI for it. Is "preset" still the way to go or should I go for
> the coll object?
The [pattr] objects family is the more versatile for presets. But it's
a bit more difficult to use than [coll]...
_____________________________
Patrick Delges
Centre de Recherches et de Formation Musicales de Wallonie asbl
http://www.crfmw.be/max
On Mar 31, 2008, at 12:53 AM, Patrick Delges wrote:
> On 31 mars 08, at 06:36, Peter Ostry wrote:
>
>> The basic question:
>> I don't want to show the preset object in the GUI but rather make
>> my own GUI for it. Is "preset" still the way to go or should I go
>> for the coll object?
>
> The [pattr] objects family is the more versatile for presets. But
> it's a bit more difficult to use than [coll]...
The pattr help file may be more difficult to understand, but the pattr
objects themselves are probably easier to use than coll. There's a
simple example, called PattrKitty on my Max examples page: http://www.xfade.com/max/examples
Chris Muir
cbm@well.com
http://www.xfade.com
Oh guys, you want to talk me into a desaster. I work just a couple of hours with Max now, I got scared by the [pttr] thingy! ;-)
But I believe you and I think PattrKitty (thanks, Chris) will do it for the first steps if not at all.
May I ask why the other two methods, preset and coll, are not as good? Less presets, too short data strings, not flexible enough, or where are the problems you usually encounter in comparison with [pttr] ?
On Mar 31, 2008, at 1:17 PM, Peter Ostry wrote:
> May I ask why the other two methods, preset and coll, are not as
> good? Less presets, too short data strings, not flexible enough, or
> where are the problems you usually encounter in comparison with
> [pttr] ?
With coll, you have to pack all the data you want to store into a
list, which is fine for small patches, but get unwieldy for larger
patches. I still use coll for many things, but generally not my
patcher UI data.
Preset is fragile, in that as you add things, your old data is no
longer valid. I sometimes use preset for very quick and dirty things,
but not for anything that I will want to modify over time.
Chris Muir
cbm@well.com
http://www.xfade.com
Patrick Delges schrieb:
> The [pattr] objects family is the more versatile for presets. But
> it's a bit more difficult to use than [coll]...
To store 80 GUIs in 100 presets I'd say pattrstorage/autopattr is about
1000*(several magnitudes) simpler than using a coll. I wouldn't know how
to do it with coll (I don't want to know), and I have more than 15 years
of maxin' in my pocket... ;-)
Chris Muir schrieb:
> Preset is fragile, in that as you add things, your old data is no
> longer valid. I sometimes use preset for very quick and dirty things,
> but not for anything that I will want to modify over time.
It's fine as long all objects are in the same (main) patch, and if you
can live with lost data during developement. The GUI is intuitively
simple. But if you need to create your own GUI anyway, just go the pattr
way. pattr rocks - no problem to include data from subpatchers and
bpatchers and poly~s...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com