--- On Thu, 8/19/10, Miller Puckette msp@ucsd.edu wrote:
From: Miller Puckette msp@ucsd.edu Subject: Re: [PD-dev] run-up to release 0.43 To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@at.or.at, pd-dev@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@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 08:30 AM, Jonathan Wilkes wrote:
(And I think initbang and closebang are totally different animals...)
They definitely are very different.
sure. i implemented both while i was at it :-)
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.
i hae used [initbang] a lot for dynamic patching (where [loadbang] is not triggered).
e.g. i have used both [initbang] and [closebang] together in a system that implements click-free reinstantiation of objects: when you have several abstractions generating audio, and you edit and save one of them, all of the sister abs are recreated, which easily generates dropouts because of 2 reasons - - the dsp-chain has to be recalculated - - the phase of the a vanishing object is different from that of the newly created replacement.
the dsp-chain recalculation can be made click-free by simply using faster processors (there are other ways (or rather: ways to reduce the time it takes for recalculation) as well, but i won't open this can of worms now)
the phase however, is a real problem which cannot be easily solved (unless Pd does automatic fade in/out for created/deleted objects automatically, which is probably not such a good idea)
the way i solved it, was sending the output of the abstraction to a summing bus (where [initbang] would create a fade in), and if the abstraction got deleted (detected by [closebang]!) it would fade out.
this has proven to work well in live-coding performances on an eee901 (e.g. a not so super-fast processor), without a rather minimal change in the core of Pd (only [initbang] and [closebang] are required)
mfgfst IOhannes
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] ).
In other words, you want Pd to include "meta" capabilities enough that abstractions have all the functionality of coded objects. [initbang] would be one step in this direction, but there would be at least these other requirements:
1) The ability, in vanilla, to dynamically delete individual instantiated objects without "dynamic mousing."
2) Left [inlet~] that can take messages like [bang( or [stop( and pass them.
3) [inlet~] that can output a settable constant signal upon creation (imagine if you wanted to create [tabosc4~] as an abstraction using a [phasor~] and a [tabread4~] -- there isn't currently a good way to connect the [inlet~] to the phasor and also have a default frequency creation arg).
4) In some cases, access to name of the parent patch could be helpful.
Matt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 05:59 PM, Matt Barber wrote:
- The ability, in vanilla, to dynamically delete individual
instantiated objects without "dynamic mousing."
this can already be done with externals: see iemguts. (i see that you say "vanilla"; however, we should differentiate between things that can be done in pd-vanilla, things that can be done with the help of externals, and things were we need to run a modified version of Pd; your request falls into category#2, which is not as evil as not being able to implement it at all without being miller)
nevertheless, it would be very nice to have this feature built into Pd, thus i have submitted a patch to the sourceforge tracker a while ago.
- In some cases, access to name of the parent patch could be helpful.
this can be done with iemguts as well.
your other 2 requests, however, would need a modified Pd-core.
fgamsdr IOhanness
--- On Fri, 8/20/10, Matt Barber brbrofsvl@gmail.com wrote:
From: Matt Barber brbrofsvl@gmail.com Subject: Re: [PD-dev] run-up to release 0.43 To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Friday, August 20, 2010, 5:59 PM
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] ).
In other words, you want Pd to include "meta" capabilities enough that abstractions have all the functionality of coded objects. [initbang] would be one step in this direction, but there would be at least these other requirements:
I'm interested in that, too, but the main reason I ask about [initbang] is because its patch has been sitting there on Sourceforge since 2006, and has been used in Pd-ext since then (and I haven't found any bugs so far with it) but not in Vanilla. If you do as the Sourceforge comments suggest and search the archives you'll not only find reasons for why the object is needed as I've suggested here, but also requests by developers (including yourself, I think) for the object to be included as an internal Pd object.
To make a max-compatible [trigger] I don't need any of the other meta-features you mention (which are good ideas). I just need [initbang]. It only has one outlet, and I've never needed more than one in an abstraction. So if future-[loadbang]-with-args were implemented tomorrow I'd just need to change one object for my max-compatible [trigger] to work across all Pd versions.
-Jonathan
-
IOhannes m zmölnig -
Jonathan Wilkes -
Matt Barber