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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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__ >>>> >>>> _______________________________________________ >>>> [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>>> >>>> >>> >>> >> > > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
