Hi,
I'm using this to generate a list of integers, is there a better way ?

@FFW Mostly have it, but it would be good to get in the habit of breaking things down into the base functions and creating abstractions like this. Either right inlet or creation argument sets how high it counts, bang or float to the left inlet counts.

[list store] with the [append $1( message or the [add2( message to an empty message can be used to create the list more efficiently, [list prepend] and [list append] reiterate the entire list each time a new element is added. The [list store] and [message( helpfiles should answer your questions.

Edit: Just remembered i posted a little abstraction here here which shows constructing lists with messages, the pird abstraction. Generally [list store] is the better way, I think.

Maybe like this:

@FFW As @oid says..... I would go with [add2 $1(
I can't think of a simpler solution.
David.

@oid You're obviously right about abstraction. This was only an example.
@Jona Yes ! I don't need [moses] as [until] block the trigger !
@whale-av [add2( is great. I can certainly use it in many abstraction I wrote.

@whale-av Messages are nice but they can be irritating with long lists since they can expand and fill the screen quickly, probably bog down the UI as well. If @FFW does not need the end result in a message and was just using it to monitor tests then your solution without the stuff on the output seems better over all.

edit, guess that was not your solution but @Jona's

IMO I would teach Jona's solution in my classes: clean, simplest way, with clear flow of control at the top = better readability.

The general pattern is "initialize - run - finalize" running right to left in the top trigger object: t b f b b:

1. b = initialize an empty list
2. b = initialize the counter
3. f = run the loop n times
4. b = after the loop, output the final list

These stages are in the original patch too, except that the finalizer is a bit hidden in the [moses] conditional.

This is a generally applicable design pattern for a whole lot of situations.

hjh

Does exist a vanilla library for such snippets ?
If not, it could be great to create a git repository.

@FFW There are a great number of them in the various libraries on deken and on this site, about as good as we get. I once brought up the idea of a standard library of common abstractions, but no one expressed any interest beyond supporting the idea and it would require more than one person to accomplish.

@FFW The list-abs library is great for message handling.
David.

@whale-av thats true. But a lot of the abstractions could be updated and optimized with the new PD objects.

@Jona @whale-av I can't understand why a contents index was not yet standardized for externals. A simple text file which lists abstractions with a short desc would help.
It's a pity to depends on https://puredata.info/docs/ListOfPdExternals/ instead of an up-to-date local index.

@oid said:

it would require more than one person to accomplish.

@oid + @FFW = 2

@FFW I no longer have the time for such a project, have two massive pd projects to eat up my time. I have mostly moved to just letting the forum fill that role and doing what I can to help it fill that gap. In some ways the forum is better suited since it can be effectively searched in rather vague and directionless ways. I still like the idea of a standard library of abstractions, but it will be up to someone else, if it ever happens.

@oid I understand.

This python script lists all abstractions in a CSV format:

from pathlib import Path

# include path
path = Path('/opt/purr-data/lib/pd-l2ork/extra/')

# lists externals
dirs = [e for e in path.iterdir() if e.is_dir()]


# parse externals for abstractions
for ext in dirs:
    abst = [e for e in ext.glob('*.pd*') if e.is_file()]
    dashHelp = [e for e in ext.glob('*-help.pd') if e.is_file()]
    dashMeta = [e for e in ext.glob('*-meta.pd') if e.is_file()]
    # Filter only non help and non meta
    abst = [a for a in abst if not a in dashHelp]
    abst = [f"{ext.name}, {a.stem}" for a in abst if not a in dashMeta]
    print("\n".join(abst))

pd-l2ork has 2566 external abstractions. Adding desc would be quite long

@Jona @whale-av I can't understand why a contents index was not yet standardized for externals. A simple text file which lists abstractions with a short desc would help.
It's a pity to depends on https://puredata.info/docs/ListOfPdExternals/ instead of an up-to-date local index.

timothyschoen starts to list and documents many objects in one file:
https://github.com/timothyschoen/PlugData/blob/main/ObjectDocumentation

@FFW I've stopped doing that, instead I use the pddoc format now instead: https://github.com/uliss/pddoc