Has anyone ever heard of the existence of an object or patch that functions like [poly] but is aware of what notes are currently playing and re-routes new notes that match currently playing to the voice that is currently playing it, thus avoiding unisons between voices? Unisons are loud, annoying and use extra CPU. I have built a unison subpatch using [poly] and a pile of wires that I am still testing, but I'd like to see if I wasted my time and there is something better out there.

Hans:
That's a shame, to be honest. I don't use plugins either but most people do. I have non-nerds that I work with musically who I would really like to share various Pd tools with. I heard about the libpd project and selfishly hoped it and you would help do my bidding. I gave up and switched to using Reaktor's "Core" which definitely proved to be on par with Pd in terms of flexibility and power but did not afford me any new ways of sharing unless we ALL buy Reaktor. Rats! Back to ye olde Pd. I think maybe I just need to get my head out of DSP and finally learn the nuts and bolts of C++ coding properly like you have eluded too. How right you are.

Quite frankly, I am pissed at the Pd fanbase. Maybe if it cost a pretty penny people would be more exited about libpd? Anyway...
Question directed to Hans von Brooklyn:
Is there any hope for me of a Vsti/AU/app/exe builder complete with GUI options? If a GUI builder is not in the cards should I look for/rile up some personages who are capable of making a builder?

@Johnny said:

I am looking for a way to integrate PD in my Nokia 5230, Symbian Phone. I want to communicate to my Computer via bluetooth. I tried to program it with symbians qt but didn't get very far. Can libpd help me? Or even better, did anybody do this before?

I am no expert but there has got to be a way. Just hang on.

Also to put things in perspective, think about the other options: Synthedit is okay I guess... I wouldn't really know. But it's Windows only and that's quite limiting. Sonicbirth is/was the the MacOS equivalent but as far as I know it's been abandoned in it's current highly buggy state. Reaktor lets you open your creations in Reaktor so that's hardly mentionable unless you want to work for NI or only want to deal with Reaktor owners. Max/MSP tried to be mobile with Pluggo, without giving up it's ownership their (actually Miller Puckette's) work but gave up and are now permanently housed inside Ableton Live's sequencer. Puredata continues to be free of cost and free of most restrictions yet extremely powerful. Now it is more mobile as well. GET EXCITED NOW!

I know I sound like a jerk saying thing, but I think people are not excited because this forum is populated by highly skilled "programmer artists." I fall victim to this too. There is a certain balance that I wish we all had. Whenever I mention standard "musical" features for Pd patches like legato voicing, no one is interested. Likewise (and perhaps admirably) Pd users are not ravenous to sell their synth creations. I want to share what I make to non Pd users/create something that might be desirable for profit/make my own music with Pd. I really hope this libpd lifts us all out of patcher obsession into the real world of music.

BTW...is anyone out there working on a non-GNU expr/expr~? I am totally cool dispensing with [expr] but for audio-rate conditional logic I am clueless, and [expr~] has had a crucial role in my work so far.

WHY AREN'T MORE PEOPLE FREAKING OUT ABOUT THIS??? Pd has a powerful engine for manipulation of audio and creation of new sounds from scratch. I would assume that those two things are what attracted people to Pd in the first place. libpd allows for sale or exposure of your creations as well as full integration into applications such as games. Your creative efforts now have potential for a purpose other than impressing other Pd users who already have Pd downloaded. Libpd will help you make something meaningful with them!!

The problem I faced was that the note's pitch needs to be taken into account to determine if it will block note on's or not. You may very well receive a note on after a note off and still want to block the note on (if the note off is not the previous note's note off.) Also, some mono-synths such as the TB-303 allowed notes to be accented even though they are legato. That means to me the velocity should pass through even if a noteon TRIGGER is blocked.

Yeah I second the need for monosynth style legato, I still haven't found anything that behaves the way I want but I don't think it will be hard to do. It's just conditional logic, if a second note on (nonzero velocity) is receive without the previous note's note off then envelopes will not be effected at all. That's tonight's task for me.

Maelstorm:
Yeah, that's a much better approach and think I might use that instead.

LarsXI:
So you put the knee adjusting phase distortion after the phase-sync...interesting. I can't find very accurate info on how the CZ worked but I am starting to realize that there are much more interesting ways to manipulate phase than what I read the CZ used. I have gotten some interesting results by truncating or compressing the phase with [clip~] and addition or multiplication respectively. Btw... (and this may reveal how new I am to Pd) your knee adjustor expression creates a divide by zero error... is this harmless?

P.S. Sorry if the above was FAR off the topic of this thread!

Thanks, you two. You both seem to be on the same page as I in terms of what we want Pd to do. I am working about 30 hours a week on building something like a Casio VZ/opl2 chip; having both phase modulation and phase distortion w/ a sync function for the phase accumulator. Also, sine functions will be able to flip shape to halfsine, quartersine, etc much like the 2op Yamaha opl2 chip. LarsXI: I use your [expr~ if($v1<$v2, ($v1*(1/$v2))/2, ((($v1-$v2)*(1/(1-$v2)))/2)+0.50] for PDist DAILY.

THANK YOU!

Also, LarsXI I am well aware of the CZ waveforms you linked me to. I have never owned a CZ but I am assumed they are derived by hardsyncing the phase accumulator (or sine function...for some reason?). Do you have any idea whether the knee adjusting phase distortion occurred before or after the hardsyncing on CZ's? I am just wondering what order of function would be best and I am leaning toward:

[phasor~] --> knee adjustor --> hard-sync --> phase modulation input --> [cos~] --> [dac~]

But really, I am just taking stabs in the dark for most of that.

Any suggestions?

JF

phase-sync.mmb.pd is pretty great and very clever but I am wondering if there is a more direct approach and I one in mind that I can't implement.

Example:

If the master [phasor~] is playing 440hertz and someone wanted to sync it to 880hrz wouldn't it be possible to hard sync that [phasor~]@440 by banging "440" into it repeatedly, at a rate of 880 times per second, reseting it's phase to zero each time? I know that [bang] does not operate at an audio rate up to 44.1k, but if it did... I would prefer this method. Is there any way to do that?