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:
- 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
- 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 | peter@createdigitalmedia.net
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:
- 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
- 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 | peter@createdigitalmedia.net
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
it's still possible to use multiplexing for passing list of integers, like for RGB values of graphical objects
or you can store parameter values in arrays and pass indexes through [poly]
----- "Phil Stone" pkstone@ucdavis.edu a écrit :
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.
it's still possible to use multiplexing for passing list of integers, like for RGB value of graphical objects
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:
- 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
- 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 | peter@createdigitalmedia.net
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks, everyone.
So, patko, I gather poly alone should work -- I'd just multiplex messages, so long as there are two arguments?
Hans, I gather the Rj version u_makepoly is now the newest. It's looking great, though I ran into one hitch - right now, with the abstraction I built it's giving me this error - Error: Bad arguments for message 'f' to object 'objectmaker' f $1 ... couldn't create
Not sure what that means. (I mean, I know literally what it means, but not why.) Looking into it / open to someone pointing out anything obvious. ;)
Peter
I don't use the rjdj libs so I wouldn't be the one to ask about them.
Frank is the main author tho, so he probably keeps them up to date.
.hc
On Mar 10, 2011, at 8:57 PM, Peter Kirn wrote:
Thanks, everyone.
So, patko, I gather poly alone should work -- I'd just multiplex messages, so long as there are two arguments?
Hans, I gather the Rj version u_makepoly is now the newest. It's looking great, though I ran into one hitch - right now, with the abstraction I built it's giving me this error - Error: Bad arguments for message 'f' to object 'objectmaker' f $1 ... couldn't create
Not sure what that means. (I mean, I know literally what it means, but not why.) Looking into it / open to someone pointing out anything obvious. ;)
Peter
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
On Thu, 10 Mar 2011, Peter Kirn wrote:
Hans, I gather the Rj version u_makepoly is now the newest. It's looking great, though I ran into one hitch - right now, with the abstraction I built it's giving me this error - Error: Bad arguments for message 'f' to object 'objectmaker' f $1 ... couldn't create Not sure what that means. (I mean, I know literally what it means, but not why.) Looking into it / open to someone pointing out anything obvious. ;)
Well, how literally ? objectmaker is the collection of all object-creation methods ("creators") of all classes. objectbox contents are considered to be messages to be sent to objectmaker. What is $1 substituting to ? is $1 happening to be standing for a symbol, by mistake ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Well, how literally ? objectmaker is the collection of all object-creation methods ("creators") of all classes. objectbox contents are considered to be messages to be sent to objectmaker. What is $1 substituting to ? is $1 happening to be standing for a symbol, by mistake ?
See my other message - ideally, u_dispatcher, the helper abstraction that distributes arguments to patches after using u_makepoly to make them polyphonic, should be able to dispatch symbols. Right now, it appears limited to only lists and floats. I need to dispatch symbols in order to pass the array name for playback of the sound buffer (in this case for a granular synth, but the same would be potentially true for a sampled instrument).
Unless there's a better way I'm missing.
Peter
On Fri, Mar 11, 2011 at 09:53:18AM -0500, Peter Kirn wrote:
See my other message - ideally, u_dispatcher, the helper abstraction that distributes arguments to patches after using u_makepoly to make them polyphonic, should be able to dispatch symbols. Right now, it appears limited to only lists and floats. I need to dispatch symbols in order to pass the array name for playback of the sound buffer (in this case for a granular synth, but the same would be potentially true for a sampled instrument).
Unless there's a better way I'm missing.
Hi Peter,
One thing you could do is convert to a list before you send it (e.g. a message that starts with the word "list") and then convert back to a symbol on the other side, I think with [list trim].
Cheers,
Chris.
Hi Peter,
On Fri, Mar 11, 2011 at 11:38:01PM +0800, Chris McCormick wrote:
On Fri, Mar 11, 2011 at 09:53:18AM -0500, Peter Kirn wrote:
See my other message - ideally, u_dispatcher, the helper abstraction that distributes arguments to patches after using u_makepoly to make them polyphonic, should be able to dispatch symbols. Right now, it appears limited to only lists and floats. I need to dispatch symbols in order to pass the array name for playback of the sound buffer (in this case for a granular synth, but the same would be potentially true for a sampled instrument).
Unless there's a better way I'm missing.
One thing you could do is convert to a list before you send it (e.g. a message that starts with the word "list") and then convert back to a symbol on the other side, I think with [list trim].
I think I have figured out the exact magical incantionation you need.
You want a dispatcher called "source" to specify the grain table source. So on the outside you send in to the right inlet a message that looks like:
[list source mytablename(
On the inside you have a [u_dispatch $0 source]
Then you hook the receiver up to the tabread~ with this lovely stack:
[r $0-source] | [list trim] | [symbol] | [set $1( | [tabread~]
I think that should do what you need it to.
Cheers,
Pd Potter.
If you want to work in the MIDI style, you probably want Frank
Barknecht's [polypoly]. Its an abstraction so it should just work on
libpd on any platform. And it works quite well.
.hc
On Mar 10, 2011, at 12:25 PM, 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:
- 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
- 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 | peter@createdigitalmedia.net
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
-
Chris McCormick -
Hans-Christoph Steiner -
Mathieu Bouchard -
patko -
Peter Kirn -
Phil Stone