On Fri, 28 Sep 2001 15:32:47 +0200 Krzysztof Czaja czaja@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 event...
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 increate-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 :)
pix.