Yes, I think the documentation is important (shame on me for never finishing all my docs). It's just a bit of a shame that we have to document some quite redundant functions, but if they make life easier for other patchers then that's great. I've made quite a few things in C that could be abstractions for example.
Also, there's an annoyance that comes from having to investigate C code from abandoned libs, although this is usually not so hard with things like ramp~. I think it could be a good idea and a lot of work to present at least some examples in the help files of how such externals could be modelled within Pd vanilla. Naively I think this could help both newbies and people learning to code externals. xEd _-_-_-_-_-_-_-^-_-_-_-_-_-_-_ For Lone Shark releases, Pure Data software and published Research, go to http://sharktracks.co.uk On Saturday, 28 January 2017, 20:48, Alexandre Torres Porres <por...@gmail.com> wrote: it's one of those objects that is in Pd but could be easily dealt with in Pd without the external (...) but it's basically a line~ with an offset, and a fixed rate looks like~ cyclone's count~ but much simpler it just generates a signal ramp with the right characteristics to patch it into tabread4~ and playback samples at their original pitch. or using it with tabread~ then instead pf tabread4~ looks again like count~ as one of its applications is in conjunction with index~ (basically tabread~). There are quite a lot of externals like this (and some from me) where people coded something in C for convenience, but can be easily done in Pd without externals. I know... Pd Extended is filled with things like that, and to make it more of a deal, documentation is sometimes bad, when simply non existing. I'm willing to help this in the forth coming Purr Data, by reorganising it and making it better documented cheers
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
