Happy new year!
sounds great, I'm looking forward to the new release!
just a couple of randoms ideas which have been in my head for a while:
- list
a) a new list method (let's say [list get]) with which you can retrieve one or more elements of a stored list. the rightmost inlet could store a list. A middle inlet could set the length of the desired sublist (default = 1) and the hot leftmost inlet takes a float as the onset (or a bang). This is just one possible interface, taken from [array] and [text]. The point is, that one can finally iterate over a list arbitrarily and in linear time! Right now, the only possible vanilla solution for random access is [bang( -> [list] -> [list split] which results in many unnecessary copies of the whole list. Finally, it would make sequencing lists (in either direction) trivial and more efficient. b) a method for sorting c) a method for reversing d) a method for searching (outputting the indices of found elements) (I know, there are externals for b), c) and d) but since these are quite common tasks (and awkward/inefficient to patch) it would make sense to have those methods in vanilla.
- writing/reading files.
a) it would be great if soundfiler, readsf~, text etc. would send some kind of message which tells whether a file was loaded successfully. Right now, these objects only throw errors in the Pd console, which the user can't catch within the patch. b) when you write a file, all folders in a given path must exist. It would, however, be nice if Pd would automatically create non-existing folders. c) some vanilla way to query a folder for existing files...
- data structures
a) a way to compare pointers for equality! b) clicking on array elements should output a pointer to the clicked element and not only to the struct containing the array. c) a way to toggle the -x flag. sometimes one wants to lock/unlock editing just temporarily. d) right now, the -x flag prevents both moving the scalar in edit mode AND moving vertices in non-edit mode. Often you only want one of the two behaviours. [ c) would actually provide a workaround for this: you just need to track the current edit mode (e.g. with [iemguts/receivecanvas]) and toggle the -x flag accordingly. ]
Thanks for your awesome work!
Christof
Gesendet: Sonntag, 01. Januar 2017 um 21:32 Uhr Von: "Miller Puckette" msp@ucsd.edu An: pd-list@iem.at Betreff: [PD] plans for Pd 0.48
Hi all,
I'm now ready to start working toward the next Pd release (0.48) . I've barely touched the Pd sources since the 0.47-1 release last June, and meanwhile picked up lots of ideas from the Pd convention and always have my own long list of things to do. In the interest of transparency I'll try to map out my plans for the 3-ish months I think it will take me to get to 0.48.
I'll only be advancing rather slowly before Feb. 4 because I have two separate music production projects before then; I'll start working faster after that.
First thing is always to merge in as many patches and pull requests as I can. I get these from two sources: sourceforge (https://sourceforge.net/p/pure-data/patches/) and github (https://github.com/pure-data/pure-data/pulls). At the moment I don't prioritize one of those above the other. I do this first because, when I enter a period of heavy code editing I risk causing conflicts with patches/pull requests and I don't want to create extra work for contributors.
In a few days I'll start on my own changes, with the major ones first so that there's extras time to get them decently debugged; then while bugs in the major changes are surfacing I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
- Make a stab at making Pdlib callable from multiple threads. There's a
suggestion from Peter Brinkmann in which gensym() (and I presume by extension, pd_bind() etc) would be protected by a lock. I have an alternative idea I'd like to float; I'll do this in a separate message to follow.
- fix "preferences" so that you can load/store them explicitly to files, and
offer an option to delete all "system" preferences ("defaults" on mac; registry info on Windows).
- Adapt and incorporate the Pd-llork/purr-data "infinite undo" feature. Since
the code has diverged I'll probably have to extensively rewrite it to work in Pd vanilla.
- fix the DSP sorting mechanism so that objects can sense whether they have
signals connected and, if not, avoid having Pd automatically generate fake signals for them to use. This way, for example, "+~" can finally detect whether it's got a signal connected without having the user have to tell it via "+~ 0". Also, then the filters (hip~ etc) can then be upgraded to allow signals for filter parameters, without doing the extra calculations if there's no signal connected. This will require adding something to the "DSP" mechanism; I'm still not sure how to do this in the best way.
- Make a binary "FUDI" format for pd~ objects, and perhaps also offer it as an
option for netsend/netreceive (I'm not sure if that's needed or not - maybe the existing "-b" binary formatting can be used in conjunction with some new formatting/parsing objects to allow passing floats and symbols around in binary messages instead.)
- Hack at sigmund~ to add some features it needs.
This is a long list and I probably won't get to all of it. Then I'll move onto all the smaller changes, which are too numerous to list here.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list