@gentleclockdivider of course, you can look at the code.

static void pack_anything(t_pack *x, t_symbol *s, int ac, t_atom *av)
{
    t_atom *av2 = (t_atom *)alloca((ac + 1) * sizeof(t_atom));
    int i;
    for (i = 0; i < ac; i++)
        av2[i + 1] = av[i];
    SETSYMBOL(av2, s);
    obj_list(&x->x_obj, 0, ac + 1, av2);
}

you have to get into a few functions, but basically the argument 's' is the 'selector' (in this case '-' or 'X'), 'ac' is the count of items in the list (after the selector) and *av is the pointer to the atoms that make it up.

first, it allocates a new list of atoms of length of the input elements (elements after the selector, in this case 0) + 1 = 1

then it shifts all the input elements up by 1, and inserts the selector as a symbol in the first element
Then obj_list will distribute all the elements of that list to the inlets of pack, from right to left which will set the atoms that pack is storing for those inlets
when obj_list lastly reaches/distributes to the leftmost it will call pack_symbol, which will call pack_bang which triggers the atoms pack has stored to be output as another new list

binding pack_anything to anythings coming into the first inlet is done by calling class_addanything in pack_setup method

the '-' and 'X' are 'anything's in terms of pd types

the cold inlets are generic and expect symbols, not 'anything's. That's why you have to convert them to symbols with [symbol].

However, the 'hot' (leftmost) inlet does accept 'anything's, and converts them to symbols

you can use the 'find externals' Help menu item to find missing externals.
When I look for 'xfm~' using this it brings up the 'creb' library. Doing so with 'sgn~' brings up zexy
edit: you can also use the deken website: https://deken.puredata.info/

it isn't finding the libtcl library. Where is it installed?
Anyways, are you sure they weren't written for 043-4-Extended rather than vanilla? Any old patch than ran on old PD vanilla should at least run in current PD
Maybe instead of recompiling pd you could post those incompatibilities.

internally pd uses a table for the [cos~] and [osc~] objects that is only 512 points with linear interpolation.
if you want to be more accurate you can make your own tables with [cos] object, or if you want to use the math.h functions directly at audio rate I think [expr~ sin($v1)] (or cos) does that

@jameslo said:

It looks like the second ramp (jump in this case) is still timed relative to halfway through the block though.

yes that one doesn't have negative delay and the first message cleared the queue already so that one gets processed normally
edit: it isn't relative to the start of the block, but if you're trying to sync with block-synced objects that would be an issue regardless

@jameslo I just discovered that if you give vline~ negative delay time value it clears the scheduled ramps and immediately jumps to the value

so if you use a negative delay time in a vline~ message it will start at the same time as a sig~ one, at the beginning of the block
it will only work for jumps and not ramps I think, but sig~ only does jumps..
edit: created a pddp issue to add to the docs: https://github.com/pure-data/pddp/issues/267

@jameslo this is getting a bit off-topic but it looks like portmidi does have timestamp info on received messages, but afaict PD doesn't use it

@jameslo midi messages don't have timing info themselves afaik (except for realtime/clock?)
Therefore they would have to be processed at block boundaries, just as graphical bangs are.
Not sure how REAPER does it, maybe they store timing info in the queue when they're received on a separate thread or something
or maybe portmidi supports it and pd just doesn't use the timing info, have to check. But maybe even with that it would be preferable to have the midi events start ASAP on block boundaries since most things in PD are synced at block boundaries

@jameslo yes it looks like you would have to delay the sig~ one to the next block as well.. (but you could do so by delaying it by a constant 64 samples I think)

(repost, my first test I forgot to resize array2)

not sure if there's a better way, but I made an object [pib~] a while ago to get the position in the current signal block in ms, using that you could delay a bang to the end of the current block:

https://github.com/sebshader/shadylib/blob/master/pib~.c
Iirc the bigger issue with vline~ is that it starts the ramp on the value after the 1st value you give it
If I want to sync on blocks I usually just use line~ unless I need something really precise like reading an audio buffer or karplus strong or something like that.

@ddw_music I'm pretty sure there's an option to display all of the searched paths that get failed trying to load a certain class, if you run pd at higher verbosity. It will be like "tried xxx and failed" or something.
Anyways you could use that to see which paths are being tried

@flextUser when I tried to download it windows flagged it as a virus..
I would just host the source on the repo host, and wait for deken to upload the release/artifacts
uploading the .zip file in the repo in the meantime rather than uploading the source and just waiting for deken to upload the package seems like an odd choice

like this? toggle-count.pd

updated to 0.55-1 on the release page https://github.com/sebshader/pdnext/releases/tag/0.55-1

@BetaRiffs you mean add them together?

@hmp did you try opening the zip file I attached? it shows how to use the [text get]

@hmp you could hypothetically parse the csv in pd, but it's probably easier to just store the text file in the pd native format, which is just separated by spaces with semicolons at the end of lines
file_example.zip

@manuels hmm yeah I guess it doesn't quite work due to the phase discontinuities..
maybe have to do a bit more tinkering with the offset/phase reset part
I wonder if it would work to just discard the wrapped around part somehow, and set the limit based on the 'non-fractional' part of the period

@porres that's quite a philosophical question.. what are the positive ones for?
edit: as a serious answer, I guess anything that's polarity-specific. you could maybe combine multiple generators in different ways?
I guess you could always multiply by -1 but to me it seems more natural to have it go from 1 to -1 since that's the output range of digital audio and it would take extra objects.. easier just to allow negative values