probably something very basic i forgot about poly~

Jan 26, 2009 at 12:50pm

probably something very basic i forgot about poly~

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?

/m

save as oneSine

– Pasted Max Patch, click to expand. –

save as whateveryoulike

– Pasted Max Patch, click to expand. –
#41943
Jan 26, 2009 at 12:59pm

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

#149768
Jan 26, 2009 at 1:10pm

but i did that. or what do you mean?

/m

#149769
Jan 26, 2009 at 1:26pm

Compare these two…

Original:

– Pasted Max Patch, click to expand. –

Edited:

– Pasted Max Patch, click to expand. –
#149770
Jan 26, 2009 at 1:33pm

#149771
Jan 26, 2009 at 1:38pm

Hi,

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.

#149772
Jan 26, 2009 at 1:43pm

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.

#149773
Jan 26, 2009 at 1:44pm

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.

/m

#149774
Jan 26, 2009 at 1:48pm

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…

#149775
Jan 26, 2009 at 1:53pm

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~? ;)

/m

#149776
Jan 26, 2009 at 1:56pm

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

#149777
Jan 26, 2009 at 1:59pm

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
[thispoly~] help file again…

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

#149778
Jan 26, 2009 at 2:02pm

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?

/m

#149779
Jan 26, 2009 at 2:21pm

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

#149780
Jan 26, 2009 at 3:19pm

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..

/m

#149781
Jan 26, 2009 at 3:22pm

Is this what you’re looking for?

– Pasted Max Patch, click to expand. –

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

#149782
Jan 26, 2009 at 3:41pm

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?

/m

#149783
Jan 26, 2009 at 3:59pm

works fine here

– Pasted Max Patch, click to expand. –
#149784
Jan 26, 2009 at 4:07pm

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.

#149785
Jan 26, 2009 at 4:40pm

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

#149786
Jan 26, 2009 at 6:13pm

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.

/m

#149787
Jan 26, 2009 at 6:26pm

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?

#149788
Jan 26, 2009 at 6:32pm

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?

#149789
Jan 26, 2009 at 7:08pm

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.

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

/m

#149790
Jan 26, 2009 at 7:23pm

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
level:

– Pasted Max Patch, click to expand. –

Chris Muir
cbm@well.com

http://www.xfade.com

#149791
Jan 26, 2009 at 7:46pm

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…

#149792
Jan 26, 2009 at 7:50pm

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.

Chris Muir
cbm@well.com

http://www.xfade.com

#149793
Jan 26, 2009 at 11:45pm

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

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

– Pasted Max Patch, click to expand. –

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

– Pasted Max Patch, click to expand. –

this way it works here!

hope this helps!
/J

#149794
Jan 27, 2009 at 12:07am

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

#149795
Jan 27, 2009 at 10:41am

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!

/m

#149796
Jan 27, 2009 at 10:46am

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.. ;-)

thanks!
/m

#149797
Jan 27, 2009 at 2:08pm

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

/J

#149798

You must be logged in to reply to this topic.