heirarchical pattr usage method

Mar 16, 2007 at 4:29pm

heirarchical pattr usage method

Before I launch into a direction that ends up being not ideal, I figured
I would ask the hive mind what the best solution is for hierarchical
pattr storage. The right way to go doesn’t readily jump out at me.

Example:

I have an eq that is in a larger channel strip. I want to save groups
of eq settings, so that they can be recalled, but also want to save
settings for the entire channel strip, which recall the eq settings but
also other settings.

I don’t see any examples with this kind of functionality prototyped.

Thanks.

barry


barry threw
composition : sound : programming
http://www.barrythrew.com
bthrew(at)gmail(dot)com
857-544-3967

Today, Noise is triumphant and reigns sovereign over the sensibility of men.
- Luigi Russolo, The Art of Noises

#30862
Mar 16, 2007 at 4:45pm

Well I know with pattrstorage you can see and create a hierarchy
of controls (spanning many baptchers) and then save different
states. But what it sounds like you want to do is also have
pattrstorage control a hierarchy of other pattrstorages and recall
all their respective presets. Yes?

—– Original Message —–
From: Barry Threw
Date: Friday, March 16, 2007 10:32 am
Subject: [maxmsp] heirarchical pattr usage method

> Before I launch into a direction that ends up being not ideal, I
> figured
> I would ask the hive mind what the best solution is for
> hierarchical
> pattr storage. The right way to go doesn’t readily jump out at me.
>
> Example:
>
> I have an eq that is in a larger channel strip. I want to save
> groups
> of eq settings, so that they can be recalled, but also want to
> save
> settings for the entire channel strip, which recall the eq
> settings but
> also other settings.
>
> I don’t see any examples with this kind of functionality prototyped.
>
> Thanks.
>
> barry
>
> —
> barry threw
> composition : sound : programming
> http://www.barrythrew.com
> bthrew(at)gmail(dot)com
> 857-544-3967
>
> Today, Noise is triumphant and reigns sovereign over the
> sensibility of men.
> – Luigi Russolo, The Art of Noises
>
>

#99281
Mar 16, 2007 at 4:57pm

Here was the source of my confusion…

If you have an mother patch, and child patch, an autopattr in both
patches, and a pattrstorage in the mother patch; that pattrstorage can
see all named objects in the child patch.

However, if you place a pattrstorage object in the subpatch, all named
objects are hidden to the mother pattrstorage, and only the preset
setting for the child pattrstorage is visible to the mother.

I didn’t figure this out until just now.

b

apalomba@austin.rr.com wrote:
> Well I know with pattrstorage you can see and create a hierarchy
> of controls (spanning many baptchers) and then save different
> states. But what it sounds like you want to do is also have
> pattrstorage control a hierarchy of other pattrstorages and recall
> all their respective presets. Yes?
>
>
>
>
>
> —– Original Message —–
> From: Barry Threw
> Date: Friday, March 16, 2007 10:32 am
> Subject: [maxmsp] heirarchical pattr usage method
>
>> Before I launch into a direction that ends up being not ideal, I
>> figured
>> I would ask the hive mind what the best solution is for
>> hierarchical
>> pattr storage. The right way to go doesn’t readily jump out at me.
>>
>> Example:
>>
>> I have an eq that is in a larger channel strip. I want to save
>> groups
>> of eq settings, so that they can be recalled, but also want to
>> save
>> settings for the entire channel strip, which recall the eq
>> settings but
>> also other settings.
>>
>> I don’t see any examples with this kind of functionality prototyped.
>>
>> Thanks.
>>
>> barry
>>
>> —
>> barry threw
>> composition : sound : programming
>> http://www.barrythrew.com
>> bthrew(at)gmail(dot)com
>> 857-544-3967
>>
>> Today, Noise is triumphant and reigns sovereign over the
>> sensibility of men.
>> – Luigi Russolo, The Art of Noises
>>
>>
>


barry threw
composition : sound : programming
http://www.barrythrew.com
bthrew(at)gmail(dot)com
857-544-3967

Today, Noise is triumphant and reigns sovereign over the sensibility of men.
- Luigi Russolo, The Art of Noises

#99282
Mar 18, 2007 at 11:13pm

Ok. Checking to make sure I’m doing this the best way.

Again, I want to have a number of pattrstorages in subpatches, saving
settings of channel strips, and a main pattrstorage that sets the preset
number for all channels.

I would like the pattrstorages in each channel strip to share data, and
I would like preset data, if changed in any strip, to update the like
numbered presets in all strips.

My major question is, Why don’t like named pattrstorages share data?
The method I have to use is kind of a cludge, which is saving the preset
to a file upon each preset storage, setting all the channel
pattrstorages to autowatch, and then sending a reload bang for them to
update their data to the client objects.

In my thinking, all like named pattrstorages should update their client
objects automatically whenever the preset changes, and they should all
share the same data without having to read it from an external file, or
at least there should be an option for this method of operation.

Is there a setting or something I am missing that will make this
situation (which seems to me like it would be very common) work better?

Thanks,

b


barry threw
composition : sound : programming
http://www.barrythrew.com
bthrew(at)gmail(dot)com
857-544-3967

Today, Noise is triumphant and reigns sovereign over the sensibility of men.
- Luigi Russolo, The Art of Noises

#99283
Mar 18, 2007 at 11:45pm

Because a named pattrstorage isn’t like a named coll — the name is
the pattrstorage’s SCRIPTING NAME. A pattrstorage’s contents are
context-specific, in any case; the whole point of the object is that,
depending on where it’s located in the patcher hierarchy, it will
manage different stuff!

jb

Am 19.03.2007 um 00:13 schrieb Barry Threw:

> Why don’t like named pattrstorages share data

#99284
Mar 19, 2007 at 12:13am

Understood. I actually get why it is nice to have it operate this way.

Just pointing out another case, in which you have several identical
bpatcher instances of something all with pattrstorages, where another
type of functionality is warranted.

Anyway, I can make it do what I want it to. Thats all that matters.

Thanks,

b

Jeremy Bernstein wrote:
> Because a named pattrstorage isn’t like a named coll — the name is the
> pattrstorage’s SCRIPTING NAME. A pattrstorage’s contents are
> context-specific, in any case; the whole point of the object is that,
> depending on where it’s located in the patcher hierarchy, it will manage
> different stuff!
>
> jb
>
> Am 19.03.2007 um 00:13 schrieb Barry Threw:
>
>> Why don’t like named pattrstorages share data
>
>


barry threw
composition : sound : programming
http://www.barrythrew.com
bthrew(at)gmail(dot)com
857-544-3967

Today, Noise is triumphant and reigns sovereign over the sensibility of men.
- Luigi Russolo, The Art of Noises

#99285
Mar 21, 2007 at 7:44am

Jeremy Bernstein schrieb:
> Because a named pattrstorage isn’t like a named coll — the name is the
> pattrstorage’s SCRIPTING NAME. A pattrstorage’s contents are
> context-specific, in any case; the whole point of the object is that,
> depending on where it’s located in the patcher hierarchy, it will manage
> different stuff!

But it would be VERY nice as a feature. If you have a mixer with 12
channels, and store presets for the filter, you definitely want each
filter of that mixer to have access to the same set of presets. The same
is true for synths and a million other abuses…

I always thought, that the name of a pattrstorage could be used for more
than just defining a scripting name. I would not mind to have it acting
like a coll/buffer name. But now I guess its too late – here is my
suggestion: “@share 1″ and all pattrstorages with the same name should
refer to the same set of presets….

I’d love it…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#99286
Mar 21, 2007 at 1:22pm

Quote: Stefan Tiedje wrote on Wed, 21 March 2007 08:44
—————————————————-
here is my
> suggestion: “@share 1″ and all pattrstorages with the same name should
> refer to the same set of presets….
>

Then I vote for “@share filter”. Presets are shared among pattrstorages with the same value for the share attribute.

Mattijs

#99287
Mar 21, 2007 at 10:10pm

Mattijs Kneppers wrote:
> Then I vote for “@share filter”. Presets are shared among pattrstorages with the same value for the share attribute.

Yum.

#99288
Mar 21, 2007 at 10:46pm

Mattijs Kneppers schrieb:
> Quote: Stefan Tiedje wrote on Wed, 21 March 2007 08:44
> —————————————————- here is my
>> suggestion: “@share 1″ and all pattrstorages with the same name
>> should refer to the same set of presets….
>>
>
> Then I vote for “@share filter”. Presets are shared among
> pattrstorages with the same value for the share attribute.

You’d just name the pattrstorage filter if its a pattrstorage for a
filter wouldn’t you?…
I thought of that also first, but realized that it would make a patch
more readable anyway if the shared name and the pattr name is the same,
and I can’t imagine a case where you would need different ones. It makes
sense anyway only in similar environments aka abstractions. If you’d
have a different abstractions with different pattr objects you might
confuse such a sharing. That’s probably the most tricky part, to compare
the set of objects, and complain if they differ…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#99289
Mar 22, 2007 at 9:20am

Quote: Stefan Tiedje wrote on Wed, 21 March 2007 23:46
—————————————————-
> Mattijs Kneppers schrieb:
> > Quote: Stefan Tiedje wrote on Wed, 21 March 2007 08:44
> > —————————————————- here is my
> >> suggestion: “@share 1″ and all pattrstorages with the same name
> >> should refer to the same set of presets….
> >>
> >
> > Then I vote for “@share filter”. Presets are shared among
> > pattrstorages with the same value for the share attribute.
>
> You’d just name the pattrstorage filter if its a pattrstorage for a
> filter wouldn’t you?…
> I thought of that also first, but realized that it would make a patch
> more readable anyway if the shared name and the pattr name is the same,
> and I can’t imagine a case where you would need different ones.

Me neither at the moment, but in my experience it is better not to use one structure for different purposes. It makes programming more intuitive. For example the arguments of unpack versus the arguments of spray. They use the same structure in a different way, which is quite confusing and counter-intuitive, especially at start.

#P newex 108 136 66 196617 spray 5;
#P newex 109 113 49 196617 unpack 5;

> It makes
> sense anyway only in similar environments aka abstractions. If you’d
> have a different abstractions with different pattr objects you might
> confuse such a sharing. That’s probably the most tricky part, to compare
> the set of objects, and complain if they differ…

Would it? It wouldn’t be a problem to me if a shared pattrstorage would simply be disabled if the objects don’t match. Of course one pattrstorage would have to be the ‘master’ and others should link to it.

Hmm, in that case.. What if one pattrstorage is named ‘filter’ (no attributes) and all pattrstorages with the attribute ‘@share filter’ would link to it?

Mattijs

>
> Stefan
>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>
>
—————————————————-

#99290
Mar 23, 2007 at 8:01pm

Mattijs Kneppers schrieb:
> Hmm, in that case.. What if one pattrstorage is named ‘filter’ (no
> attributes) and all pattrstorages with the attribute ‘@share filter’
> would link to it?

Sounds good at first sight, but what if you just want to put it into a
poly~? then you need to have a pattrstorage named filter outside of that
poly~? Inside they would all have the same name, and thats part of the
reason why you would want them to share their content. It can only
happen if they share absolutely similar environments…
I think it only has to be switched on, no more info necessary…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#99291

You must be logged in to reply to this topic.