[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