I'm pleased to announce the availability of [polygrainsynth], a polyphonic granular synthesizer built on the [a_grain] abstraction written by Jamie Bullock. Much like its older sibling [polywavesynth], [polygrainsynth] does automatic allocation and management of n voices, where n is limited only by your available processing power.
See http://www.pkstonemusic.com/polygrainsynth.html for all you need to know, and http://www.pkstonemusic.com/code/polygrainsynth.tgz to download the archive.
I've added some examples of this synthesizer in use to my music page: http://www.pkstonemusic.com/pubmusic.html (particularly in the section "Amber Grains of Wave").
Enjoy; let me know if there are problems (but please read the web page completely before asking!). Also let me know how you like it.
Phil Stone http://www.pkstonemusic.com
P.S. [polywavesynth] has been updated. See http://www.pkstonemusic.com/pd_code.html for a convenient link to both synthesizers.
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
I'm pleased to announce the availability of [polygrainsynth], a polyphonic granular synthesizer built on the [a_grain] abstraction written by Jamie Bullock. Much like its older sibling [polywavesynth], [polygrainsynth] does automatic allocation and management of n voices, where n is limited only by your available processing power.
That's very nice, and has exemplary documentation!
I didn't look at the internals yet, but it occured to me, that the dependency on OSC probably could be factored out (if you'd want to) by using Pd's standard [route]. The control messages would look like: "(name) grain env atk 12" then and would include a tree of [route]s. To make that OSC-targetable one could use a separate abstraction. The disadvantage would be that one looses pattern matching.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
I'm pleased to announce the availability of [polygrainsynth], a polyphonic granular synthesizer built on the [a_grain] abstraction written by Jamie Bullock. Much like its older sibling [polywavesynth], [polygrainsynth] does automatic allocation and management of n voices, where n is limited only by your available processing power.
That's very nice, and has exemplary documentation!
Thank you, Frank. The object wouldn't have been possible without [polypoly] and several other of your excellent contributions.
I didn't look at the internals yet, but it occured to me, that the dependency on OSC probably could be factored out (if you'd want to) by using Pd's standard [route]. The control messages would look like: "(name) grain env atk 12" then and would include a tree of [route]s. To make that OSC-targetable one could use a separate abstraction. The disadvantage would be that one looses pattern matching.
That's an intriguing idea. I *do* like the pattern matching, but it's not necessary at the interior level of the synthesizers. I wonder what the performance differences are, if any, between [routeOSC] and [route]?
It's tempting, because with your recent work towards a vanilla-ready filter, it's getting more likely that [svf~] could be replaced with something non-external, and then my synthesizers could be completely external-free.
Phil www.pkstonemusic.com
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
That's an intriguing idea. I *do* like the pattern matching, but it's not necessary at the interior level of the synthesizers. I wonder what the performance differences are, if any, between [routeOSC] and [route]?
I guess, route may even be a bit faster as it just compares symbols and doesn't have to split any strings, but it's probably negligible.
It's tempting, because with your recent work towards a vanilla-ready filter, it's getting more likely that [svf~] could be replaced with something non-external, and then my synthesizers could be completely external-free.
I found some diagrams on the web for the svf filter e.g. http://www.earlevel.com/Digitalir%20Audio/StateVar.html so maybe with some tweaking a simple svf could be made with pure Pd, too.
(You know, Damian and I and others are on a "Pure Pd" trip ATM, as the Pd in the RJDJ project for smartphones - iPhone only ATM - doesn't load externals. It's also a great exercise.)
Ciao
Frank
Hi there.
i've been lurking here for 4 or 5 months now, and this community
is really excellent; i've learned a lot. But now i have my first question: Is there an easy way to make a number like 76.87731 round up/down or even just chop off the decimal places? i'm sending these numbers as MIDI controller numbers and would like to be able to see them the way the MIDI device does, as a simple number between 0 and 127.
--t [london, canada]
Hi Tim,
[int] makes it an integer. Nothing could be simpler....
best! d.
Tim Glasgow wrote:
question: Is there an easy way to make a number like 76.87731 round up/down or even just chop off the decimal places?
Me:
Is there an easy way to make a number like 76.87731 round up/down or even just chop off the decimal places?
Chris Clepper:
Put the [i] object wherever you need integers.
Derek Holzer:
[int] makes it an integer. Nothing could be simpler....
Perfect. Problem solved. Thanks to both of you!
--t [london, canada]
-
Derek Holzer -
Frank Barknecht -
Phil Stone -
Tim Glasgow