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.
jb
BUG REPORTING GUIDELINES
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
> 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.
> But maybe I'm a little crazy.
welcome to the club :-)
David
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
objects appear to work as expected.
Max/Jitter 4.5.7/1.5.2
OS X 1.4.7
Steps to reproduce:
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.
pstoragenugget.pat :
pstoragepolytest.pat :
Expected results: No errors.
Actual results: An error message.
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.
jb
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 that's not clear, I'll whip up a few more max patches.
best
evan
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
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.
best,
evan
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
>
> 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 didn't test the line input yet.
best,
Edwin
hi jeremy, thanks for the test patch!
> Just one of those 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.
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,
including the pattrmarker!
jan
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)
> But maybe I'm a little crazy.
Max is the best aid in being crazy...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com