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.

_-_-_-_-_-_-_-^-_-_-_-_-_-_-_

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 <porres@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