Peter,
You are correct that [poly] imposes a MIDI-like structure in that it
works with note/velocity pairs. I just wanted to point out that it does
not clip those tuplets in a MIDI way; i.e., you can pass floats for both
"note" and "velocity" to your polyphonic instrument. Your general point
is still taken, that a more generalized, perhaps list-passing [poly]
would be very useful.
BTW, I've made a granular-based polyphonic synthesizer for Pd; it's
here: http://www.pkstonemusic.com/polygrainsynth.html , along with it's
older sibling a subtractive/fm hybrid polyphonic synthesizer:
http://www.pkstonemusic.com/polywavesynth.html .
Phil Stone
On 3/10/11 9:25 AM, Peter Kirn wrote:
Hi everyone,
I'm revisiting granular patches as I work on some examples for libpd.
Any kind of granular synthesis is, of course, heavily dependent on
polyphony. That raises the question of how to instantiate multiple
copies of the same abstraction.
The issue is, many non-external methods of doing this right now depend
on poly, which in turn assumes MIDI parameters. I would prefer
something that uses arbitrary parameter lists.
We actually could now do this two ways:
1. We can instantiate multiple patches when opening them in libpd,
maintaining independent references to each patch, as Peter Brinkmann
recently described on his blog - http://bit.ly/egBGV2
2. Perhaps there's a way to do this using an abstraction?
nqpoly, etc., I believe did this, but it seems it's not supported -
and may not be the best approach?
Thanks,
Peter
PETER KIRN | http://createdigitalmusic.com | ny, ny |
[email protected]
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
