Hi

i am wondering if anyone has had luck with pix_freeframe? I cannot get it to work. loading a plugin crashes pd [latest pd extended for intel w/ Gem "tigital". I would love to know if anyone has worked this out or has it working on an Intel mac pro.

Also, i am wondering asking/begging for pdp_freeframe and pdp_frei0r to be included in pd extended for OSX? I have them working in linux and PPC linux as well, but want to use them in OSX if possible.

cheers~

Patrick Pagano Sound and Light Technologist School of Theatre and Dance University of Florida

Yeah, I have to second that It's great to see stuff like this emerging.

.hc

On Nov 24, 2008, at 6:24 PM, Kyle Klipowicz wrote:

Very lovely! Your documentation is impeccable. This is truly an
great, full-functioning pair of synths. I will be sure to show it
off to my 7th grade Pd student.

~Kyle

On Wed, Oct 1, 2008 at 10:53 PM, Phil Stone pkstone@ucdavis.edu
wrote: Hi again,

If you use either of these synthesizers, please grab the latest. The previous versions moved "gain" to a global parameter. I should have known better; this causes glitches in already-sounding notes when presets change. I had a similar problem last year with
[polywavesynth], but forgot about it.

This is the tradeoff to using [poly] to manage voices; if you want the ability to change presets cleanly, most parameters (i.e., those stored to make up the preset) can only be changed on new attacks. I haven't thought of a way around this conundrum yet.

At any rate, the latest versions fix this issue. Sorry for any inconvenience.

This leads to the web pages and download links for both synthesizers: http://www.pkstonemusic.com/pd_code.html

Phil Stone http://www.pkstonemusic.com

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

--

---

---

---

http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams

Thanks for the feedback, Mr. Off. :-) Seriously, I really appreciate it. (responses interleaved below).

hard off wrote:

yeah getting some quite lush sounds out of this polywavesynth now.
says its only using 4% of my cpu as well, which is a bonus. haven't tried the grain one yet.

Fast machine! This means you can use big voice numbers, like 64 (if you can find a use for that kind of polyphony). Alternatively, you can throw up multiple [polywavesynth]s and/or [polygrainsynth]s, for polytimbral polyphony, or fattened unison voices.

a couple of things:

1. the message box going into the sssadpanel currently contains

[example_presets/example1( but the folder is actually [Example_Presets], my system doesn't work with the change in capitalization.

This is in [polywavesynth_example] -- good catch; I'll fix it on the next release.

2. it's hard to adjust the ADSR sliders at low values. particularly

for attack, it is important to be able to choose values around 20ms or 50ms. so i think a log, or exponential scaling would be better for the ADSR sliders.

This is such an excellent idea, I implemented it immediately (changed the sliders to log). Not nearly so much shift-dragging is necessary now. You have to watch out for attack/decay/release values of less than 11 msecs. or so, though. They can sound very clicky (although this may actually be desired in certain circumstances). Again, this will be available on the next release; it's easy to change on your own, though, and it has no ill effects.

3. i had a look, and i can't figure out why, but it seems that the

global gain is still somehow affecting the sound further up the chain. ie..when i adjust the global gain, the attack of the sound is also changing. still not sure where this is coming from, but maybe something connected to the adsr?

I don't understand what you mean here...the gain slider on the [polywavesynth] UI is interacting with the attack? Are you sure it's not clipping - it's easy to clip with higher gain settings. The more notes you hold down, the higher the output, so for big polyphony, you have to bring the slider down a bit. If I'm totally misreading what you're saying here, let me know.

4. would be nice to have more control over the amount of panning.

Like all the controls, it's available via OSC:

[an lfo, or anything else you like] | [/example/pan/position $1 < | (connect to the rightmost inlet of [polywavesynth])

Similarly, you can change the pan lagtime with a message like "/example/pan/speed 0.8". The OSC implementation of [polywavesynth] (polygrainsynth works the same way) is here:
http://www.pkstonemusic.com/polyWaveSynth.html#osc

but yeah, there are lots of really good sounds possible with this, great synth!!!

Thanks again for the excellent critique.

Phil http://www.pkstonemusic.com

hard off wrote:

hi again....some more comments

1. at first i also tried changing the ADSR sliders to a log setting,

and totally understand what you mean about the low values and clicking. my workaround was just to change the range from 1-5000 to 5-5000. however, i think an even better solution is not the log function, but an exponential one.

if you change the sliders to 0-1 range and then do:

[r slider-value] | [pow 2] (or 3) | [* 5000] | [+ 1]

then that gives the most user-friendly sliders in my opinion.

Be aware that that breaks the way state is currently saved for the ADSR; ADR values are stored as milliseconds, not as 0-1. That could be changed, but it would break all existing patches (I'm probably the only one for whom that causes problems -- still I try not to do it too often). The "log" setting is a pretty good compromise; thanks again for the idea.

2. i understand that you can change the pan position and speed, but

unless i'm mistaken, there is no way just to keep everything centre panned.

Just change the radio button from "rnd" (for random panning) to "fix" (for "fixed" position). Then, move the "position" slider to the center (or move it live for manual panning). Sorry that the controls are labeled so cryptically, but real estate is at a premium, and the web page documentation spells out the details.

i think a pan width slider would be helpful. however, maybe that's just something i want and wouldn't be that important for anyone else, so i might just put that on my own modified version.

Yeah, I thought of some other panning algorithms and enhancements besides random panning, too, but have punted this off to OSC control.
You can do just about anything you can conceive of through the OSC input, as you are completely in control of what numbers you pass in.
Most of my latest work with these two synths involves hooking up LFOs and other data generators to various controls through the OSC input.

That said, I *do* plan to balance the panning a little better at some point. It's a simple-minded pan right now, not a balanced-power ratio, so there's a "center hole" effect.

3. not sure what was happening with the gain problem. perhaps svf~

puts out some gnarly peaks that are well above the -1 1 threshold, and that was making things sound weird when i changed volume. the problem seems fine now, because i deleted the gain section from the polywavevoice~ abtraction and put the gain directly onto the ouptut of polywavesynth~.

Well, I'm glad you're not shy about customizing, but that change wipes out the possibility of phased-in preset changes (as when the "global" toggle is off). I've gone back and forth on this during the evolution of the instrument, and am really liking the current set up which allows local-per-voice gain changes, over-rideable with the "global" control, which causes all voices to be controlled instantly by the GUI and OSC.

the gain slider also had a really unusable range, so i also adjusted that into a more manageable range.

It is greater than unity gain above about 70% or so. This was done to match up with [polygrainsynth], which sometimes needs the extra gain.
When you have a "rack" of these, with the two types mixed together, it's good to have the gain slider-range match, but otherwise, you're right that the gain slider could be better optimized for [polywavesynth]'s purposes.

i will definitely use this synth a lot from now on. today i was running it with an SH101 emulator i am making, and a modified sequenced version of frank's vosim~ abstraction, and some drum synths, and it was all sounding pretty sweet. really cool to be able to get some polyphony happening and do chords and stuff!

That's really great to hear, and I look forward to hearing some music made with it. Check out [polygrainsynth] if you get a chance.

Thanks a million for the detailed feedback,

Phil http://www.pkstonemusic.com