Danny de Graan

I've got the strangest problem. If I'm building a patch using poly~ it doesn't work even the simplest thing. When I save the patch and reload it, it works. I've got no idea whats going on here. Does anyone as a idea?

Its pretty annoying building a patch like this. Maybe its a bug in Max?

BTW I work on a MacBook Pro 2.33 with maxmsp 4.6.2.

I've got the strangest problem. If I'm building a patch using poly~ it doesn't work even the simplest thing. When I save the patch and reload it, it works. I've got no idea whats going on here. Does anyone as a idea?
Its pretty annoying building a patch like this. Maybe its a bug in Max?

poly-problem-3

Your question is vague and you provide few details as to 

what you are trying to do with poly~. Some more information 

might be helpful or post an example patch so that we can see 

Your question is vague and you provide few details as to 
what you are trying to do with poly~. Some more information 
might be helpful or post an example patch so that we can see 
what you are talking about.

The thing is that the patches are okay....they work but only after I reload them. So I have to close the patch and load it in max and then it works.

Also, if I'm working in the poly~ and place a new [in 2] of [out 2] it will not appear in the poly~ when I save it. Again, I need to close the masterpatch (which includes the poly~) and load it back into max and then it appears.

So, if I post a patch here, it will work fine for you.

Hope someone knows the answer to this mysterious problem.

So, if I post a patch here, it will work fine for you. 

One point: if you have abstractions in a patch, and open them *from 

the patch* (open the abstraction window, then option-click in the 

title bar to open an editable copy), the mother patch is updated when 

you save changes. But if you open the same abstraction from the 

Finder, the mother patch is not updated when you save changes. Ditto 

This is a subtle behavioral difference. I'm not sure if this is what 

On 16-Feb-2007, at 18:26, danny de graan wrote:

> The thing is that the patches are okay....they work but only after 

> I reload them. So I have to close the patch and load it in max and 

> Also, if I'm working in the poly~ and place a new [in 2] of [out 2] 

> it will not appear in the poly~ when I save it. Again, I need to 

> close the masterpatch (which includes the poly~) and load it back 

> So, if I post a patch here, it will work fine for you.

> Hope someone knows the answer to this mysterious problem.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

One point: if you have abstractions in a patch, and open them *from  
the patch* (open the abstraction window, then option-click in the  
title bar to open an editable copy), the mother patch is updated when  
you save changes. But if you open the same abstraction from the  
Finder, the mother patch is not updated when you save changes. Ditto  
for poly~s, pfft~s, bpatchers.

This is a subtle behavioral difference. I'm not sure if this is what  
you are facing.

> The thing is that the patches are okay....they work but only after  
> I reload them. So I have to close the patch and load it in max and  
> then it works.
>
> Also, if I'm working in the poly~ and place a new [in 2] of [out 2]  
> it will not appear in the poly~ when I save it. Again, I need to  
> close the masterpatch (which includes the poly~) and load it back  
> into max and then it appears.
>
> So, if I post a patch here, it will work fine for you.
>
> Hope someone knows the answer to this mysterious problem.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

> I've got the strangest problem. If I'm building a patch using poly~

> it doesn't work even the simplest thing. When I save the patch and

> reload it, it works. I've got no idea whats going on here. Does

> anyone as a idea? Its pretty annoying building a patch like this.

Though you don't deliver anything for helping you, I bet its 

This is typically something you should find out yourself...

danny de graan wrote:
> I've got the strangest problem. If I'm building a patch using poly~
> it doesn't work even the simplest thing. When I save the patch and
> reload it, it works. I've got no idea whats going on here. Does
> anyone as a idea? Its pretty annoying building a patch like this.

Though you don't deliver anything for helping you, I bet its 
initialisation...
This is typically something you should find out yourself...

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


> Also, if I'm working in the poly~ and place a new [in 2] of [out 2]

> it will not appear in the poly~ when I save it. Again, I need to

> close the masterpatch (which includes the poly~) and load it back

Yes the original patch can't know that you changed the number of 

ins/outs. But you don't need to reload the patch, if you delete your 

poly~ and the immediately undo, it will instantiate with the correct 

numbers of ins/outs. The same is true for js by the way...

danny de graan wrote:
> Also, if I'm working in the poly~ and place a new [in 2] of [out 2]
> it will not appear in the poly~ when I save it. Again, I need to
> close the masterpatch (which includes the poly~) and load it back
> into max and then it appears.

Yes the original patch can't know that you changed the number of 
ins/outs. But you don't need to reload the patch, if you delete your 
poly~ and the immediately undo, it will instantiate with the correct 
numbers of ins/outs. The same is true for js by the way...

Quote: Stefan Tiedje wrote on Fri, 16 February 2007 13:31

----------------------------------------------------

> ins/outs. But you don't need to reload the patch, if you delete your 

> poly~ and the immediately undo, it will instantiate with the correct 

> numbers of ins/outs. The same is true for js by the way...

I've also found that just retyping the arguments (like the number of voices) in the poly~ in the parent patcher will reinstantiate it as well - complete with new ins/outs, internal goodies, etc. all ready to go. Watch out for loadbangs which send data into the poly~ as well. Doubleclick those to re-loadbang to make sure whatever you're banging in gets sent. Also, if you have some other data in the parent patch (like BPM or an LFO rate for instance) which is sent into the poly~ you need to resend that info to the new instantiation before it'll behave as expected.

Quote: Stefan Tiedje wrote on Fri, 16 February 2007 13:31
----------------------------------------------------
> ins/outs. But you don't need to reload the patch, if you delete your 
> poly~ and the immediately undo, it will instantiate with the correct 
> numbers of ins/outs. The same is true for js by the way...
>
> Stefan
----------------------------------------------------

I've also found that just retyping the arguments (like the number of voices) in the poly~ in the parent patcher will reinstantiate it as well - complete with new ins/outs, internal goodies, etc. all ready to go.  Watch out for loadbangs which send data into the poly~ as well.  Doubleclick those to re-loadbang to make sure whatever you're banging in gets sent.  Also, if you have some other data in the parent patch (like BPM or an LFO rate for instance) which is sent into the poly~ you need to resend that info to the new instantiation before it'll behave as expected.

On 16-Feb-2007, at 23:32, Lewis Keller wrote:

> I've also found that just retyping the arguments (like the number 

To force reinstantiation it's enough to click anywhere in the object, 

hit space then backspace and enter. It's fast and you don't have to 

> Watch out for loadbangs which send data into the poly~ as well.

Instantiation in an existing patch never generates loadbangs. 

Loadbangs are only generated when the patch is loaded. That's why 

loadbang and loadmess are double-clickable.

> I've also found that just retyping the arguments (like the number  
> of voices)

To force reinstantiation it's enough to click anywhere in the object,  
hit space then backspace and enter. It's fast and you don't have to  
think.

Instantiation in an existing patch never generates loadbangs.  
Loadbangs are only generated when the patch is loaded. That's why  
loadbang and loadmess are double-clickable.

it depends on the order you're opening things.

If your main patch is already open, then you open up the poly~ patch, edit it, and save it, then you'll experience so called systems until you retype the argument into poly~ box. It doesn't work the same way that abstractions reload.

If you're editing the poly~ patch, save it, then open the main patch that has poly~ in it, it'll work as you're expecting it to work.

As you can see, poly~ is a complicated object. I thereby recommend you hire me as a maxMSP tutor for the low low price of $50 an hour. We can begin tomorrow at 8am. See you there.

As you can see, poly~ is a complicated object.  I thereby recommend you hire me as a maxMSP tutor for the low low price of $50 an hour.  We can begin tomorrow at 8am. See you there.


Quote: Peter Castine wrote on Fri, 16 February 2007 15:05

Quote: Peter Castine wrote on Fri, 16 February 2007 15:05
>and you don't have to  
> think.

Quote: Peter Castine wrote on Fri, 16 February 2007 10:47

> But if you open the same abstraction from the 

> Finder, the mother patch is not updated when you save changes.

what?? do you use a different max than i do?

> But if you open the same abstraction from the  
> Finder, the mother patch is not updated when you save changes. 

poly~ problem