Kyle Klipowicz wrote:
Phil~
I don't think it would cause problems if you keep them in a subdirectory and addressed the abstractions with abs/foobar.pd type naming.
OK, I think it's starting to sink in. I can keep private "abstraction libraries" inside my abstraction. Another advantage to this is that I can control the versioning of these libraries -- only updating them when I know they don't break [polyWaveSynth].
(Man, I wish the whole PD namespace thing weren't such a ball of confusion, to me at least. I guess it's a natural consequence of the organic growth of PD, though.)
Does Pd search the patch's folder first for all non-native objects before parsing the path?
I was wondering that same thing. If not, this method wouldn't work very consistently.
Also, this will all become resolved once Pd-extended moves forward to including more recent abstractions in its releases (i.e. Pd-extended-0.40 or however it will be branded).
Yes. (Hans? Frank?) please add sssad and polypoly to Pd-extended!
Until then, we just can't really expect the same crowd that Pd-extended is marketed for to know much about cvs and setting up the paths and stuff. It's better to take the high road and avoid elitist isolationism and make things easy as possible for new users to dive into: Pd needs adherents to thrive and become a serious competitor of similar commercial options.
Agreed. I just want to make sure I don't screw up the user's namespace, though. That sort of thing will lose adherents in a hurry. :-)
I think that this object will be a great selling point for new Pd users, especially because of the polyphony. Polyphony management is one of the most annoying things for new (and more seasoned) users to deal with in Pd. Your synth (combined w/ Frank's freaking awesome abstractions) has a great possibility for becoming a template for many awesome modifications and enhancements down the line.
What a nice thing to hear! Thanks, Kyle.
Phil
~Kyle
On 9/9/07, Phil Stone pkstone@ucdavis.edu wrote:
Hi Kyle,
I thought of doing that, but reconsidered because it seems like it might lead to versioning problems, namespace clashes, multiple copies of objects and possibly, dogs and cats sleeping together.
Or am I over-thinking it?
Phil
Kyle Klipowicz wrote:
Hi Phil~
Perhaps you could repackage the polyWaveSynth with the required abstractions included, since they are very small in size to make much of a difference? This might eliminate much of the frustration that seems to be plaguing some people.
~Kyle
On 9/9/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Luigi Rensinghoff hat gesagt: // Luigi Rensinghoff wrote:
i was curious to check out that synth, but i get this error.
the screenshot i from ubuntu, but it was the same on OS X.
You can fix this by adding your polyWaveSynth directory to your pd-path or copy over poly*.pd to that director.y As polypoly.pd lives in a different directory from polyWaveSynth, it cannot find the objects it creates dynamically. (I'm not sure, if it *should* see them, though, i.e. if this is a bug in Pd.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list