[PD] max4-like poly~ for pd

pix pix at test.at
Fri Sep 28 15:57:01 CEST 2001

On Fri, 28 Sep 2001 15:32:47 +0200
Krzysztof Czaja <czaja at chopin.edu.pl> wrote:

> hi,
> I like your cute-poly~, it is fun.  Any doubts I have are of more
> general
> nature.  And I would be happy to sort out these things for the future,
> to
> give more `stability in time' (shell I say: `more permanent status'?) to
> the work composers are patching in Pd.

yeah, the comments are interesting and making me think... i hadn't really
considered trying to use poly to do this, but i can see many reasons why
it's probably good that i didn't... most of these revolve around how
midi-dependant poly is. i would really like to think that we are well
beyond the simplicity if midi-like specifications of sound events. i'm not
sure what the 10 parameters might be that someone could use to trigger a
note in nqpoly~, but i like making it more general.
> Take a look, if you wish, to the attached new version of notsocute.pd
> (untested), which deal with some of the difficulties you pointed out.
> Finally, allow me to add few remarks to your explanation:
> pix wrote:
> ...
> > mainly because poly only lets you send through two parameters...
> As in my notsocute.pd example, one can always send more parameters
> separately to the voice that currently awaits them.

but there is a lot of trickery to change the parameters before every

> > and also how does it recycle the voices in the pool? it doesn't know
> when
> > they have finished.
> >
> > to do stuff like grainsynth, you need to be able to recycle free
> voices
> > straight away (without having to stop all notes, which i think it what
> you
> > have to do with poly).
> You are right, poly works the MIDI-way, so one has to cheat it somehow.
> There is such cheating in my example, the `extended-poly' subpatch
> (it is ugly).

yeah this is very very midi - assuming that you won't want two events with
the same frequency.. but there is a lot more to sound than frequency.

> > poly could probably be fiddled with to make it more useful (or should
> i
> > just say, general) - for example, taking a message that will kill a
> given
> > voice number (that the voice can send when it is finished).
> That would make PureData's poly incompatible with max, but indeed,
> making
> such an extended poly-alike would save much trouble (and is very easy
> btw).

yeah i imagine it would be easy... at it really just involves is an
efficient array for remembering which voices are doing what. theoretically
this could probably just be done with a table anyhow... *thinks thinks..
hmm, evil gleam*.. i have this perverse obsession with doing as much as
possible in abstractions without resorting to externals (which feel like a
kind of cheating - because everything is theoretically possible in code,
i'm more interested in finding out what is possible in pd).

> > and you could even squeeze some self-mod patch in there for making the
> > building of the voice-pool less painful (i'd rather not make 100
> voices by
> > hand - especially with extra wrapper-logic for signalling back to
> poly).
> Since with global callback (`killme' s/r in my example) you do not need
> to make any local connections, creating 100 voices is not a pain.  You
> can automate this through some sort of self-mod mechanism, as in
> `create-your-voices' subpatch in my example, but anyway it is safer to
> do this only once, and not each time your patch is loading.

i don't know about safer.. but it's certainly easier to code. as you can
imagine, making changes to nqpoly~ is a nightmare :)

> Krzysztof
> ps. I will be out of reach (and away from Pd) for the next few days.
> Then I will start adding midifile interface to qlist, if nobody
> stops me :)


More information about the Pd-list mailing list