[PD] Missing objects/methods in Pd WAS: objects with no alphanumerical names, how to build them?

Alexandre Torres Porres porres at gmail.com
Wed Apr 6 06:41:04 CEST 2016


howdy, I guess you missed the "pd is limited" discussion from not long
ago...

well, vanilla is quite limited and there surely reasons for it. I can't
really answer you cause I don't know exactly what they are, I guess I'd
like to hear more about it too.

like anything in this world, something with particular characteristics have
advantages and disadvantages. A smaller package is easier for someone like
Miller to develop - it also makes it easy to allow things like libpd to
exist.

I guess lots of people didn't care much about vanilla's limitation as they
were using Pd-Extended. That's how I came to know pd over 10 years ago now
(damn). And what it was could be thought of as a not limited version of Pd.

To answer your inquiry, I, for one, could list so many things that I miss
in Pd Vanilla that I'd be actually describing how I miss a fork of Pd
Vanilla that relates to what Pd Extended was...

I guess it's alright that vanilla keeps it plain simple and that we have to
rely on external libraries. It's hard to say where to stop enhancing
vanilla... I guess there is no limit, the arbitrary line must be drawn by
whoever is running it to the point where it's reasonable to handle and
manage.

But anyway, the thing is that if vanilla is limited, then we need to rely
on many libraries, and the issue now becomes the external addons and who is
taking care of them. I could point that things aren't that well when we see
that the the great majority of pd-extended's libraries are currently
unmaintained (not to mention how Extended died on its own).

If most of these libraries were still being supported, and if the community
worked on a distribution with many features/libraries already wrapped
around vanilla, we wouldn't be having the 'what's missing in vanilla
discussion".

having said all that and not really concluding, I can say I miss in Pd
Vanilla:

a clear message in delwrite~
a peak amplitude output to env~
a wrap function in expr
a way to set initial state/current input samples in fexpr~
a knob GUI

a way to specify that the object I'm creating is from a particular external
library

and that pd~ external for max actually running

and finally, a patch that would make me a lot of money...

cheers


2016-04-05 20:59 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:

> Actually I never understood why relational and bitwise signal operators
> were never included in vanilla...
>
> Or: why zexy as a whole (despite of some obsolete objects) isn't part of
> the core :-).
>
> Joking aside, at least some externals that prove to be very useful or even
> fundamental (like zexy's sigops or [z~]) could find its way into the core
> now and then. To me, Pd vanilla seems to be overly conservative in this
> respect. On the other hand, I like that the set of objects is rather
> restricted, it's just about a handful of objects which I think are really
> missing and shouldn't require a user to get an external library.
>
> And when there are already good externals which do an important job, why
> not include them? For example, Pd vanilla got its own set of OSC objects
> recently (nice!), but they are rather awkward to use and have far less
> functionality then, for example, the mrpeach objects (Miller actually
> refers to them in the help patch).
>
> I personally like how openFrameworks, for example, makes good addons part
> of the core (ofxOsc, ofxGui ...).
>
>
> Another thing: there are definitely some methods missing in [list] and
> [array], like sorting, searching, iterating, inserting... Why do I have to
> rely on an external to sort a list? Just imagine the shock of someone
> coming from SuperCollider :-D.
>
> Don't get me wrong: The limited set of objects in vanilla definitely has
> its charme but in many aspects it seems too narrow.
>
> Maybe we could have a discussion, like: Which objects/methods are you
> missing the most in Pd vanilla?
>
>
>
> Gesendet: Dienstag, 05. April 2016 um 17:12 Uhr
> Von: "Jonathan Wilkes via Pd-list" <pd-list at lists.iem.at>
> An: "Alexandre Torres Porres" <porres at gmail.com>, "Roman Haefeli" <
> reduzent at gmail.com>
> Cc: "pd-list at lists.iem.at" <pd-list at lists.iem.at>
> Betreff: Re: [PD] objects with no alphanumerical names, how to build them?
>
> Here's some Pd Fan Fiction:
>
> Relational sigop author: Hey I got relational sigops.  You want them?
> Pd author: Yeah thanks, I forgot about those. *copy/paste*
> Pd community: Yay!
>
> Fin.
>
> -Jonathan
>
>
> On Tuesday, April 5, 2016 10:46 AM, Alexandre Torres Porres <
> porres at gmail.com> wrote:
>
>
>
> 2016-04-05 5:08 GMT-03:00 Roman Haefeli <reduzent at gmail.com>: If you're
> simply interested in knowing how things work technically, fine.
>
> I'd love to know, for sure, that's why I'm asking :)
>
>  Now that we have a chance to get rid of all hexloader related kludges,
> now you come and bring it up again.
>
> You see, I don't really get what you mean by "hexloader" or its related
> kludges. All I know is some [hexloader] object that is in my pd extended
> 0.42-5, and all I know is that I need to use it in order to load the [==~]
> object from zexy. What you're talking about, somehow, relates to that?
>
> Anyway, seems so to me... and if so, the thing is that what I'm asking and
> doing has nothing to do with "hexloader"... (I never even mentioned about
> "hexloader", btw) ... and I read about the "hex loader" discussion as
> suggested, and found stuff that I didn't really think was related to my
> questions. Yeah, like I said, I don't really know much and I'd like to
> know, so I might be missing something, and someone can help me with it...
>
> But the thing is, all I asked was how to compile an object like [==~] and
> make it load without being part of a library. I found on deken a zexy
> version that seemed to do that
> (specifically: zexy-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar).
> And it didn't need a [hexloader] object too, by the way.
>
> I didn't get an answer, but me and my colleague were checking the source
> code from zexy and found some cues. We tried it... and it works!
>
> Now I have an object that is compiled as [==~], it's not part of a
> library, and it loads and works on pd vanilla 0.46-7 64 bits, pd
> vanilla 0.46-7 32 bits and also Pd-Extended 0.42-5 (without the need of the
> [hexloader] object by the way). All you need is the ==~.pd_darwin object in
> a search path.
>
>
> Speaking and thinking as a user, I think it is easy and great to have a
> working and compiled object that just loads and works, so that is what I 'm
> after.
>
> But anyway, yeah, I wanna know what are the dangers and all...
>
> cheers
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at[Pd-list at lists.iem.at] mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>  _______________________________________________ Pd-list at lists.iem.at
> mailing list UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160406/75c7f31b/attachment-0001.html>


More information about the Pd-list mailing list