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: 1) 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. 2) 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... 3) 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" <[email protected]> > An: [email protected] > 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: > > 1. 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. > > 2. 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). > > 3. 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. > > 4. 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. > > 5. 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.) > > 6. 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. > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
