[PD-dev] Re: FRIDAY 25, UTC 17.00 : developers meeting on irc

[Miller Puckette]

Can you remind me of the IRC address and what's a good client (gaim?)
... never tried IRC before.

thanks
Miller

On Mon, Feb 21, 2005 at 04:19:42PM -0500, Mathieu Bouchard wrote:
> 
> On Wed, 9 Feb 2005, Tim Blechmann wrote:
> 
> > i've set up a wiki to collect topics for the developer meetings on irc:
> > http://puredata.org/Members/timblech/developerwiki
> > feel free to add topics, that are supposed to be discussed there ... it
> > can also be used to propose a date ...
> 
> Apparently, in the meantime, this has moved to:
> 
>   http://puredata.org/Members/timblech/TopicsForTheDeveloperMeetingsOnIrc/
> 
> *******************************************************************
> * NOTE: THE MEETING WILL BE HELD ON FRIDAY FEBRUARY 25, UTC 17.00 *
> *******************************************************************
> 
> This is the FINAL date, because the people we delayed the meeting for
> have, to my knowledge, not proposed any other date. (contact me if you
> believe i may have accidentally skipped a mail on this...)
> 
> 
> 
> Tim's list of topics (from the link above):
> -------------------------------------------
> 
> fft, position of the nyquist bin, fftw, sign of the complex part of rfft~
> irfft~
>  
> behaviour of audio arrays (references to _array or a_vec?)
>  
> adding callback-based scheduling?
>  
> memory locking resulting in segmentation faults
>  
> locking mechanism for g_arrays to make a threaded soundfiler threadsafe
>  
> threadsafety of pd in general (e.g. improved idle callbacks)
>  
> alsa midi support (higgs: I'll even raise my hand and offer to start this
> if pd-dev likes.)
> 
> 
> 
> Matju's list of topics (from the link above):
> ---------------------------------------------
> 
> devel_0_38 bug in loading of externals (mystery and major hurdle)
>  
> distribution of devel_0_38 (tarballs, rpm's, etc.)
>  
> unit-testing in pd : how to ensure pd's functionalities work, and continue
> to work even when changes (major or minor) are made to pd itself or any
> supporting libraries
>  
> improving error-handling in pd (important if unit-testing of pd is done
> using pd patches); this would consist of a way for a pd patch to trap an
> error message and process it. For example, sending a message to
> [error]? would make that same message go out of left inlet, except that if
> ever pd_error() is called before returning, the message gets sent by
> right-outlet of [error]? instead of (or in addition to) being printed in
> the console.
>  
> fixing miller's console: how to make it optional? not all error messages
> are being rerouted to the Pd console, and when Pd dies early there is no
> way to see those messages. Matju's console is optional, but is found only
> in impd_0_37 and would cvs-conflict with Miller's. Also: control the urge
> to remove the term-window, or at least tell people how they're supposed to
> reenable it in case of need. (or figure a way to reroute stdout/stderr
> portably! no fork() in mingw)
> 
> integration of impd_0_37 to devel_0_38; especially, making sure the merge
> of miller_0_39 and devel_0_38 will be smooth enough, so that less efforts
> get wasted.
> 
> _____________________________________________________________________
> Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
> 
> 
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev