[PD-dev] run-up to release 0.43

Jonathan Wilkes jancsika at yahoo.com
Fri Aug 20 08:30:25 CEST 2010


--- On Thu, 8/19/10, Miller Puckette <msp at ucsd.edu> wrote:

> From: Miller Puckette <msp at ucsd.edu>
> Subject: Re: [PD-dev] run-up to release 0.43
> To: "Jonathan Wilkes" <jancsika at yahoo.com>
> Cc: "Hans-Christoph Steiner" <hans at at.or.at>, pd-dev at iem.at
> Date: Thursday, August 19, 2010, 10:44 PM
> Hi Jonathan -
> 
> I don't feel confortable with the design but don't
> understand the rationale
> for them well enough to know how to evaluate them. 
> (And I think initbang
> and closebang are totally different animals...)

They definitely are very different.

As for [initbang] - my only use has been for making abstractions that 
can spawn a variable number of inlets/outlets.  That's the only way 
I've used it and the only way I've ever seen it used-- if there are 
other uses maybe someone else on this list can give an example.

The [initbang] object gives abstractions 
the ability to do something that otherwise would only be possible by 
coding an external in another programming language.  For example, 
with [initbang] I can quickly make an abstraction that can act like 
Max/MSP's [trigger] object-- where you can specify numeric values as 
arguments ( like [trigger b 0] ).

> 
> I want to redesign loadbang to take arguments, one of which
> could indicate
> at what "phase" of loading or closing the message should
> come out -- but this
> is a bigger design problem than I'm able to attack right
> now.  I worry, though,
> that enshrining the proposed initbang/closebang will make
> thiings uglier and
> more complicated than necessary.

The addition of initbang would be a rather restricted ugliness, since a) 
neither [loadbang] nor [initbang] have an inlet (and therefore must 
always be at the head of an object chain), and b) both have a single 
outlet that sends a single message, and that message is a bang in both 
cases.

If future compatibility is the issue, and if the current [initbang] 
is to be a subset of the features of future [loadbang], wouldn't it 
be fairly straightforward to make [initbang] an alias of future 
[loadbang] (like a shortcut to whatever args you have to give future 
[loadbang] to get the functionality of current [initbang])?

-Jonathan

> 
> cheers
> Miller
> > 
> > Miller- would you mind commenting on the
> initbang/closebang patch 
> > on Sourceforge, as to why it's still not included in
> your Pd?
> > 
> > Thanks,
> > Jonathan
> > 
> > > I'm
> > > curious what features you have in mind, and
> looking forward
> > > to having
> > > you in NYC.  Perhaps we should have a mini PdCon
> here
> > > in the Fall :)
> > > 
> > > .hc
> > > 
> > > On Wed, 2010-08-18 at 17:06 -0700, Miller
> Puckette wrote:
> > > > Hi all,
> > > > 
> > > > I have only 2 weeks left in the vicinity of
> my usual
> > > collection of testing
> > > > machines (will be in New York Sept 1 - Jan.
> 1!) and so
> > > should probably
> > > > try to get 0.43 finalized.  I have several
> bugs
> > > to work on but I think the
> > > > whole thing is ready to put out compiled
> "test
> > > versions" for people to
> > > > exercise.
> > > > 
> > > > I'll try not to add new "features" but just
> fix bugs
> > > for the next 2 weeks --
> > > > I'll have all fall for the next bunch of
> features
> > > (including, perhaps, the
> > > > ones I've been trying to find time to work
> on).
> > > > 
> > > > I'll do my usual compiling and spot testing,
> hopefully
> > > putting out the
> > > > test versions within the next day.
> > > > 
> > > > cheers
> > > > Miller
> > > > 
> > > >
> _______________________________________________
> > > > Pd-dev mailing list
> > > > Pd-dev at iem.at
> > > > http://lists.puredata.info/listinfo/pd-dev
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Pd-dev mailing list
> > > Pd-dev at iem.at
> > > http://lists.puredata.info/listinfo/pd-dev
> > > 
> > 
> > 
> >       
> > 
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at iem.at
> 
> > http://lists.puredata.info/listinfo/pd-dev
>



      



More information about the Pd-dev mailing list