lists@lowfrequency.or

pattrstorage-in-poly

Typically, using pattrstorage inside of a poly~ works fine. Could you please send a patch where it doesn't? Simple tests based on your description do not reproduce the problem you are describing.

As you know well by now, bug reports require a minimum of information to be useful. OS and Max version are a minimum. An example patch with complete, concise instructions for reproduction of the problem is even better. Without this information, chances that we're going to be able to find the problem are slight, and chances that we're going to spend more than 2 minutes trying to are also.

SO... thanks for your coooperation. Bug reporting guidelines copied below. Please use them.

Please report any problems you experience with clear and complete

information, including steps to reproduce, software and system

information, and where possible, an isolated example patch and crash

log. Something like the following would be ideal. This makes it

easier for us to find and fix the problems you experience. Without

such clear and complete information, it is less likely we will be

Provide a descriptive summary of the issue.

In numbered format, detail the exact steps taken to produce the bug.

Describe what you expected to happen when you executed the steps above.

Please explain what actually occurred when steps above are executed.

Describe circumstances where the problem occurs or does not occur,

such as software versions and/or hardware configurations.

Provide additional information, such as references to related

problems, workarounds and relevant attachments.

Please report any problems you experience with clear and complete
information, including steps to reproduce, software and system
information, and where possible, an isolated example patch and crash
log. Something like the following would be ideal. This makes it
easier for us to find and fix the problems you experience. Without
such clear and complete information, it is less likely we will be
able to.

Summary:
Provide a descriptive summary of the issue.

Steps to Reproduce:
In numbered format, detail the exact steps taken to produce the bug.

Expected Results:
Describe what you expected to happen when you executed the steps above.

Actual Results:
Please explain what actually occurred when steps above are executed.

Regression:
Describe circumstances where the problem occurs or does not occur,
such as software versions and/or hardware configurations.

Notes:
Provide additional information, such as references to related
problems, workarounds and relevant attachments.


On 14 Sep 2006, at 13:44, evan.raskob [lists] wrote:

> Is it considered bad form to put a pattrstorage (with no name 

I'm interested to see the answer to this myself - but what I usually 

do is to have the interface outside of the poly~, (either open-able 

patcher or bpatcher) as that's generally what I want to store, and 

(so far) I haven't found a need for multiple instances of the UI in a 

If I understand what you want to do, having the UI separate would 

> Ideally, what I was thinking of doing is using pattrstorage and 

> poly to create an arbitrary number of sprite-like objects (wrapped 

> around jit.gl.gridshape) with different presets for position, 

> Is it considered bad form to put a pattrstorage (with no name  
> specified) inside a patch in a poly~?

I'm interested to see the answer to this myself - but what I usually  
do is to have the interface outside of the poly~, (either open-able  
patcher or bpatcher)  as that's generally what I want to store, and  
(so far) I haven't found a need for multiple instances of the UI in a  
subpatch.
>
If I understand what you want to do, having the UI separate would  
work for this ...
> Ideally, what I was thinking of doing is using pattrstorage and  
> poly to create an arbitrary number of sprite-like objects (wrapped  
> around jit.gl.gridshape) with different presets for position,  
> scale, etc.

I understand the bug reporting format, I just didn't want to go an 

offend anyone by calling it a "bug" until I could be sure that I 

wasn't just doing something bass-ackwards. My last 2-3 "bug reports" 

turned out to be bass-ackwardness on my part, so why add to that score?

Anyway, there is an issue with poly~ and pattrstorage, and it was 

tricky to pin down. But I don't think it qualifies as a bug because 

it seems to work (as far as I can tell), just giving that funky error 

message from my last post. But I'll toe the company line anyway.

Bug: Mysterious error with pattrstorage in poly~ subpatch

Summary: In some circumstances, Max reports an error when using 

pattrstorage objects in subpatchers, although the pattrstorage 

1. Save the following patchers in the same folder.

3. You should see an error in the Max window. If not, open 

pstoragenugget.pat separately, and save it. Then increase the number 

of voices numberbox in the pstoragepolytest.pat.

Regression: Remove the top-level pattrstorage from 

pstoragepolytest.pat and the errors will disappear.

I understand the bug reporting format, I just didn't want to go an  
offend anyone by calling it a "bug" until I could be sure that I  
wasn't just doing something bass-ackwards.  My last 2-3 "bug reports"  
turned out to be bass-ackwardness on my part, so why add to that score?

Anyway, there is an issue with poly~ and pattrstorage, and it was  
tricky to pin down.  But I don't think it qualifies as a bug because  
it seems to work (as far as I can tell), just giving that funky error  
message from my last post.  But I'll toe the company line anyway.

Summary: In some circumstances, Max reports an error when using  
pattrstorage objects in subpatchers, although the pattrstorage  
objects appear to work as expected.

1. Save the following patchers in the same folder.
2. open pstoragepolytest.pat.
3. You should see an error in the Max window.  If not, open  
pstoragenugget.pat separately, and save it.  Then increase the number  
of voices numberbox in the pstoragepolytest.pat.

Regression: Remove the top-level pattrstorage from  
pstoragepolytest.pat and the errors will disappear.


See? That wasn't too bad, and now I can reproduce the error! Thanks for the report.

The error does go away, btw, if you give the psto objects inside the poly~ names.

Also, can you please give an example of how to reference a pattr 

inside a poly~, via a pattrstorage on the same level as the enclosing 

I've noticed that in the pattrstorage's clientwindow, pattrs inside a 

poly~ patch come up as having a path of "patchname.poly-index", but 

when I try to reference them, I don't seem to be doing it properly 

because the values don't change. If my poly~ subpatch is named 

"nugget", is at the first index in the poly~ and has a pattr named 

"pdiddy" then it looks like telling pattrstorage "recall nugget. 

1::pdiddy 1." should recall pdiddy's state from preset 1?

If that's not clear, I'll whip up a few more max patches.

Also, can you please give an example of how to reference a pattr  
inside a poly~, via a pattrstorage on the same level as the enclosing  
poly~?

I've noticed that in the pattrstorage's clientwindow, pattrs inside a  
poly~ patch come up as having a path of "patchname.poly-index", but  
when I try to reference them, I don't seem to be doing it properly  
because the values don't change.  If my poly~ subpatch is named  
"nugget", is at the first index in the poly~ and has a pattr named  
"pdiddy" then it looks like telling pattrstorage "recall nugget. 
1::pdiddy 1." should recall pdiddy's state from preset 1?

If you just want to set the value of the child psto, via the parent: "pstoragenugget.4::kram 1.5", for instance. Since the value of the pattrstorage is its current "recall" value, this causes the child in the poly~ to recall an interpolated preset between 1 and 2.

If you want to send a _message_ to the child psto, you should look at the "pattrforward" object. The pathname of the object remains the same -- polyname.voice#::objectname

aha, thanks. that all works very well for me.

what's subtle is that you can rename the poly~ object (or cut it and 

paste it from one patch to another), and then you might have 

different client names for all of your poly~ subpatches. whew! it 

gets complicated. note to self - make sure everything is always 

On Sep 14, 2006, at 3:17 PM, Jeremy Bernstein wrote:

> If you just want to set the value of the child psto, via the 

> parent: "pstoragenugget.4::kram 1.5", for instance. Since the value 

> of the pattrstorage is its current "recall" value, this causes the 

> child in the poly~ to recall an interpolated preset between 1 and 2.

> If you want to send a _message_ to the child psto, you should look 

> at the "pattrforward" object. The pathname of the object remains 

> the same -- polyname.voice#::objectname

aha, thanks.  that all works very well for me.

what's subtle is that you can rename the poly~ object (or cut it and  
paste it from one patch to another), and then you might have  
different client names for all of your poly~ subpatches.  whew! it  
gets complicated.  note to self - make sure everything is always  
named properly.

>
> If you just want to set the value of the child psto, via the  
> parent: "pstoragenugget.4::kram 1.5", for instance. Since the value  
> of the pattrstorage is its current "recall" value, this causes the  
> child in the poly~ to recall an interpolated preset between 1 and 2.
>
> If you want to send a _message_ to the child psto, you should look  
> at the "pattrforward" object. The pathname of the object remains  
> the same -- polyname.voice#::objectname
>
> jb


I'm surprised to see that the build in microphone of my mac book is 

able to produce signals out of adc~ and ezdac~ that are 'louder' then 

-1.0 and 1.0. The signal can easily go up to + or - 4.0.

I have the same behaviour with 4.6.1 as with 4.5.7.

I'm surprised to see that the build in microphone of my mac book is  
able to produce signals out of adc~ and ezdac~ that are 'louder' then  
-1.0 and 1.0. The signal can easily go up to + or - 4.0.
I have the same behaviour with 4.6.1 as with 4.5.7.
I didn't test the line input yet.

i have another one: in max 4.5.7, performance is about twice as fast 

as in 4.6, and in both direct-in is about twice as fast as thru pattr..

same on a tiBook 867ghz and a g5 2.33ghz dual core.

so for this purpose, i'll stick to the direct-in (and maybe my tiBook;-)

but for all other purposes, i'm very happy about pattr things, 

i have another one: in max 4.5.7, performance is about twice as fast  
as in 4.6, and in both direct-in is about twice as fast as thru pattr..
same on a tiBook 867ghz and a g5 2.33ghz dual core.

but for all other purposes, i'm very happy about pattr things,  
including the pattrmarker!

> Ideally, what I was thinking of doing is using pattrstorage and poly

> to create an arbitrary number of sprite-like objects (wrapped around

> jit.gl.gridshape) with different presets for position, scale, etc. 

> The presets themselves would be loaded up at runtime.

I do this usually with an autopattr inside the poly~ and one 

(Look at St.PresetAid.help from the St.ools)

evan.raskob [lists] wrote:
> Ideally, what I was thinking of doing is using  pattrstorage and poly
> to create an arbitrary number of sprite-like objects (wrapped around
> jit.gl.gridshape) with different presets for position, scale, etc. 
> The presets themselves would be loaded up at runtime.

I do this usually with an autopattr inside the poly~ and one 
pattrstorage in the main patch.
(Look at St.PresetAid.help from the St.ools)

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


pattrstorage in poly~?