[PD] plans for Pd 0.48

Christof Ressi christof.ressi at gmx.at
Mon Jan 2 19:17:09 CET 2017


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" <msp at ucsd.edu>
> An: pd-list at 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:
> 
> 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.
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> 



More information about the Pd-list mailing list