mattias petersson

i'm too stupid today to figure things out and it's been a while since i used poly~..

but isn't this kind of solution supposed to work?

i'm too stupid today to figure things out and it's been a while since i used poly~..
but isn't this kind of solution supposed to work?

probably-something-very-basic-i-forgot-about-poly

You need to connect your [poly~] to your [gain~]...

Brennon : the poly~ was connected to the gain~ in the orginal one.

You just have to save "oneSine" before creating the second patch.

Just tested it and it works nice here.
Brennon : the poly~ was connected to the gain~ in the orginal one.
You just have to save "oneSine" before creating the second patch.


Quote: stefantiedje wrote on Mon, 26 January 2009 13:33

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

> He didn't save the subpatcher to his search path... ;-)

> What isn't working? It does work for me as expected...

A search path problem may also be true, but the [poly~] is not connected to the [ezdac~], even when I save onesine.maxpat to my search path prior to opening the main patch.

Quote: stefantiedje wrote on Mon, 26 January 2009 13:33
----------------------------------------------------
> He didn't save the subpatcher to his search path... ;-)
>
> What isn't working? It does work for me as expected...

A search path problem may also be true, but the [poly~] is not connected to the [ezdac~], even when I save onesine.maxpat to my search path prior to opening the main patch.


this is very strange. i tried again and if i copy and paste my original code the poly~ IS connected to the gain~. you mean this is not the case when you do the same thing? are you on windows maybe?

so, ok.. thanks, but this was not the problem.

the thing is that i thought that voice allocation with poly~ could be done with this method, but it doesn't seem to work.

so, ok.. thanks, but this was not the problem.
the thing is that i thought that voice allocation with poly~ could be done with this method, but it doesn't seem to work.

No, this patch does work if the [poly~] is connected and the abstraction

loaded into the [poly~] is in your search path. If this is the case for

you, and it's still not working, something else is awry for you...

No, this patch does work if the [poly~] is connected and the abstraction
loaded into the [poly~] is in your search path.  If this is the case for
you, and it's still not working, something else is awry for you...


Quote: stefantiedje wrote on Mon, 26 January 2009 14:33

it seems i can only get one voice out of it. poly~ doesn't seem to allocate any new voices. if i klick fast on the kslider (or do a glissando) it doesn't trig any new notes until the first ones envelope is done.

or shouldn't i expect polyphony out of poly~? ;)

Quote: stefantiedje wrote on Mon, 26 January 2009 14:33
----------------------------------------------------
> What isn't working? It does work for me as expected...
it seems i can only get one voice out of it. poly~ doesn't seem to allocate any new voices. if i klick fast on the kslider (or do a glissando) it doesn't trig any new notes until the first ones envelope is done.
or shouldn't i expect polyphony out of poly~? ;)

That's because you're not doing any targeting of different voices. Check

out the "target" message in the [poly~] help and reference files.

That's because you're not doing any targeting of different voices.  Check
out the "target" message in the [poly~] help and reference files.

Brennon Bortz
School of Music and Sonic Arts
Queen's University of Belfast
brennon@brennonbortz.com


Scratch that...if I recall correctly now, it was fine.

Actually, I'm away from my computer now, but I seemed to recall that your

[thispoly~] setup was a little out of whack. Compare that to the

Actually, I'm away from my computer now, but I seemed to recall that your
[thispoly~] setup was a little out of whack.  Compare that to the
[thispoly~] help file again...

Quote: Brennon Bortz wrote on Mon, 26 January 2009 14:56

> That's because you're not doing any targeting of different voices. Check

> out the "target" message in the [poly~] help and reference files.

yes, i know about targeting voices. but if i am using ‘note’ as voice allocator message, and signal to thispoly~ this shouldn't be necessary, right?

Quote: Brennon Bortz wrote on Mon, 26 January 2009 14:56
----------------------------------------------------
> That's because you're not doing any targeting of different voices.  Check
> out the "target" message in the [poly~] help and reference files.
yes, i know about targeting voices. but if i am using ‘note’ as voice allocator message, and signal to thispoly~ this shouldn't be necessary, right?

I think the problem resides more in the kslider, which is monophonic by default (check the reference and the mode message)

now, my small example suddenly seems to work. i didn't do anything but re-instantiating poly with a different number of voices a couple of times.. really strange i have to say.

the slightly bigger patch i'm working on, which uses the same voice allocating method, still doesn't work though.

i'm attaching this as well. nothing fancy, just a simple additive synth..

please tell me if this works with 8 voice polyphony on your system. here, i get only one voice..

the slightly bigger patch i'm working on, which uses the same voice allocating method, still doesn't work though.
i'm attaching this as well. nothing fancy, just a simple additive synth..
please tell me if this works with 8 voice polyphony on your system. here, i get only one voice..

Brennon Bortz
School of Music and Sonic Arts
Queen's University of Belfast
brennon@brennonbortz.com 

Quote: Brennon Bortz wrote on Mon, 26 January 2009 16:22

it would work in the small oneSine example, but in the bigger patch i have 8 envelopes inside poly which can be of different length. so i thought that the easiest way to do this is to use the signal in feature of thispoly~: 

"You can also connect a signal to thispoly~ to set the "busy" state;

when the signal is non-zero, the busy state is set, when it is 0, it is not set." (from the help file)

so, when all my partials are silent the voice should be freed.

Quote: Brennon Bortz wrote on Mon, 26 January 2009 16:22
----------------------------------------------------
> Is this what you're looking for?
it would work in the small oneSine example, but in the bigger patch i have 8 envelopes inside poly which can be of different length. so i thought that the easiest way to do this is to use the signal in feature of thispoly~: 
"You can also connect a signal to thispoly~ to set the "busy" state;
when the signal is non-zero, the busy state is set, when it is 0, it is not set." (from the help file)

so, when all my partials are silent the voice should be freed.
but maybe i misunderstood the help file?

Sorry Phijel, but I don't believe this is a [kslider] problem. Were [kslider] to be sending note-offs, then it would be an issue.

Quote: mattias petersson wrote on Mon, 26 January 2009 15:41

> "You can also connect a signal to thispoly~ to set the "busy" state;

> when the signal is non-zero, the busy state is set, when it is 0, it is not set." (from the help file)

> so, when all my partials are silent the voice should be freed.

> but maybe i misunderstood the help file?

No, you didn't misunderstand the help file--you just didn't mirror the help files patching method. Compare the way the help file feeds a constant signal (using [sig~]) with a value of either 1. or 0. to [thispoly~] to what you're doing. The difference is subtle, but important.

Sorry Phijel, but I don't believe this is a [kslider] problem.  Were [kslider] to be sending note-offs, then it would be an issue.  

Quote: mattias petersson wrote on Mon, 26 January 2009 15:41
----------------------------------------------------
> "You can also connect a signal to thispoly~ to set the "busy" state;
> when the signal is non-zero, the busy state is set, when it is 0, it is not set." (from the help file)
>
> so, when all my partials are silent the voice should be freed.
> but maybe i misunderstood the help file?

No, you didn't misunderstand the help file--you just didn't mirror the help files patching method.  Compare the way the help file feeds a constant signal (using [sig~]) with a value of either 1. or 0. to [thispoly~] to what you're doing.  The difference is subtle, but important.


Ok, well then i don't understand what your problem is, because it works fine here ???

Quote: Phijel wrote on Mon, 26 January 2009 17:40

> Ok, well then i don't understand what your problem is, because it works fine here ???

i don't understand either. but here it does _not_ work. did you try out the bigger zipped patch as well?

i remember now why i stopped using poly~... it's all about troubleshooting. sigh..

according to the helpfile, the msp tutorial 21 (the littlebeep~ synth) and the reference it should be possible just to connect a signal to thispoly~. and then the busy state should be set to 1 if the signal is non-zero and 0 if it's zero.

maybe my poly~ object is corrupt or something? because in the zipped patch i uploaded i only hear one voice. as if the other voices never gets allocated.

also when i tried to choose another file in the poly~ inspector Max crashed...

hopefully it's just me doing something wrong in the patch, but i cannot seem to find it.

i'm running Max 5.0.5 with Leopard 10.5.6 btw.

Quote: Phijel wrote on Mon, 26 January 2009 17:40
----------------------------------------------------
> Ok, well then i don't understand what your problem is, because it works fine here ???
----------------------------------------------------
i don't understand either. but here it does _not_ work. did you try out the bigger zipped patch as well?
i remember now why i stopped using poly~... it's all about troubleshooting. sigh..

according to the helpfile, the msp tutorial 21 (the littlebeep~ synth) and the reference it should be possible just to connect a signal to thispoly~. and then the busy state should be set to 1 if the signal is non-zero and 0 if it's zero.
maybe my poly~ object is corrupt or something? because in the zipped patch i uploaded i only hear one voice. as if the other voices never gets allocated.
also when i tried to choose another file in the poly~ inspector Max crashed...

hopefully it's just me doing something wrong in the patch, but i cannot seem to find it.
i'm running Max 5.0.5 with Leopard 10.5.6 btw.

You've thrown the whole purpose of [poly~] out the window here... Those partials should each be handled by their own [poly~]. Why are they all wrapped up into one?

You've thrown the whole purpose of [poly~] out the window here...  Those partials should each be handled by their own [poly~].  Why are they all wrapped up into one?


Are you trying to give each [poly~] instance 8 of its own partials? Or, are you trying to route each partial to a different [poly~] instance?

Are you trying to give each [poly~] instance 8 of its own partials?  Or, are you trying to route each partial to a different [poly~] instance?


Quote: Brennon Bortz wrote on Mon, 26 January 2009 19:32

> Are you trying to give each [poly~] instance 8 of its own partials?

> Or, are you trying to route each partial to a different [poly~] instance?

this is simple additive synthesis with 8 partials. and i want the synth to be 8 voice polyphonic, which means 8 oscillators, 8 envelopes and 8 amplifiers (*~) per voice.

i know that there's other and nicer ways of doing additive synthesis, but this is how i want it this time.

it's just the poly~ that's not working the way it should

Quote: Brennon Bortz wrote on Mon, 26 January 2009 19:32
----------------------------------------------------
> Are you trying to give each [poly~] instance 8 of its own partials?
yes

> Or, are you trying to route each partial to a different [poly~] instance?
no

this is simple additive synthesis with 8 partials. and i want the synth to be 8 voice polyphonic, which means 8 oscillators, 8 envelopes and 8 amplifiers (*~) per voice.
i know that there's other and nicer ways of doing additive synthesis, but this is how i want it this time.

On Jan 26, 2009, at 5:44 AM, mattias petersson wrote:

> the thing is that i thought that voice allocation with poly~ could 

> be done with this method, but it doesn't seem to work.

I've always found the signal method of controlling thispoly~ 

problematic. I prefer to explicitly control thispoly~ at the scheduler 

> the thing is that i thought that voice allocation with poly~ could  
> be done with this method, but it doesn't seem to work.

I've always found the signal method of controlling thispoly~  
problematic. I prefer to explicitly control thispoly~ at the scheduler  
level:

Chris Muir
cbm@well.com	
http://www.xfade.com

Your "busy reporting" just isn't working reliably. You need to use Chris'

method, or what I showed earlier to explicitly set/unset the busy state of

[thispoly~]. Testing your patch shows that just having the signal output of

each partial connected to the [thispoly~] is not working reliably--whether

the tutorials say it should or not. Nevertheless, because you know envelope

times, you should be able to determine exactly when to send the busy/not

busy signal to [thispoly~]. This is going to get a little trickier as you

have added the possibility for longer envelope durations, though...

Your "busy reporting" just isn't working reliably.  You need to use Chris'
method, or what I showed earlier to explicitly set/unset the busy state of
[thispoly~].  Testing your patch shows that just having the signal output of
each partial connected to the [thispoly~] is not working reliably--whether
the tutorials say it should or not.  Nevertheless, because you know envelope
times, you should be able to determine exactly when to send the busy/not
busy signal to [thispoly~].  This is going to get a little trickier as you
have added the possibility for longer envelope durations, though...

One other thing I noticed when looking at your patch is a bug in 

keyslider, or at least a difference from the way it used to work in 

In Max 5, keyslider sends a velocity of 0, for any note other than the 

In Max 4 keyslider sent a velocity based on the position of the mouse 

when it entered a note, which I prefer, fwiw.

Inserting a [route 0] between the keyslider and the pack, to get rid 

of the 0 velocity notes makes keyslider act a little more like it did 

See my earlier message about controlling thispoly~ at scheduler level, 

One other thing I noticed when looking at your patch is a bug in  
keyslider, or at least a difference from the way it used to work in  
Max 4.

In Max 5, keyslider sends a velocity of 0, for any note other than the  
first one, when dragging over the keys.

In Max 4 keyslider sent a velocity based on the position of the mouse  
when it entered a note, which I prefer, fwiw.

Inserting a [route 0] between the keyslider and the pack, to get rid  
of the 0 velocity notes makes keyslider act a little more like it did  
in Max 4.

p.s.
See my earlier message about controlling thispoly~ at scheduler level,  
which I still think is a good idea.

rember the "target 0" message in your partialinterface.maxpat (i also

connect the extra outlet from this patcher to the first inlet of poly~

and use the signal from zigzag~ in your partial.maxpat to go to

rember the "target 0" message in your partialinterface.maxpat (i also
forget this all the time)

and use the signal from zigzag~ in your partial.maxpat to go to
thispatcher instead

the complete set of patchers that works for me are here...

addendum to my previous post:
the complete set of patchers that works for me are here...
/J


Quote: Chris Muir wrote on Mon, 26 January 2009 20:50

> One other thing I noticed when looking at your patch is a bug in 

> keyslider, or at least a difference from the way it used to work in 

> See my earlier message about controlling thispoly~ at scheduler level, 

yes, it's seems to be a safer way to go. thanks!

Quote: Chris Muir wrote on Mon, 26 January 2009 20:50
----------------------------------------------------
>
> One other thing I noticed when looking at your patch is a bug in  
> keyslider, or at least a difference from the way it used to work in  
> Max 4.
that's good to know.

> See my earlier message about controlling thispoly~ at scheduler level,  
> which I still think is a good idea.
yes, it's seems to be a safer way to go. thanks!

Quote: Jakob Riis wrote on Tue, 27 January 2009 00:45

> rember the "target 0" message in your partialinterface.maxpat (i also

but of course! thanks Jakob! (hitting myself..)

now i will make a tattoo that says "target 0" on my forehead.. ;-)

Quote: Jakob Riis wrote on Tue, 27 January 2009 00:45
----------------------------------------------------
> rember the "target 0" message in your partialinterface.maxpat (i also
> forget this all the time)
but of course! thanks Jakob! (hitting myself..)

> this way it works here!
it seems to work here as well. great!
now i will make a tattoo that says "target 0" on my forehead.. ;-)

>now i will make a tattoo that says "target 0" on my forehead.. ;-)

>now i will make a tattoo that says "target 0" on my forehead.. ;-)
LOL, look forward to see you sometime!

probably something very basic i forgot about poly~