I'm more interested in stopping the loadbang than starting it. If you have a patch that dynamically creates itself (or worse deletes itself) when loaded, it is very useful to be able to inspect the patch without the the process starting. Initbang provides this because it bangs only when the patch is loaded as an abstraction, not when the patch is opened.
Message: 3 Date: Mon, 11 Jan 2016 09:41:41 +0100 From: Jack jack@rybn.org To: pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 56936AC5.6030301@rybn.org Content-Type: text/plain; charset=utf-8
Hello,
For dynamic patching, you can :
- import your abstraction in a subpatch
- send the message 'loadbang' to your subpatch
=> all your abstractions with the object 'loadbang' will send a bang when the message 'loadbang' will be send. ++
Jack
Le 11/01/2016 04:27, Liam Goodacre a écrit :
So no chance of getting them in Vanilla then? That's annoying, as they're both really useful objects. I particularly like [initbang] because it bangs only when the patch is loaded as an abstraction, not when it is opened. This is really useful for dynamic patching.
Message: 3 Date: Sun, 10 Jan 2016 13:31:36 +0000 (UTC) From: Jonathan Wilkes jancsika@yahoo.com To: Roman Haefeli reduzent@gmail.com, "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 355667468.2920260.1452432696797.JavaMail.yahoo@mail.yahoo.com Content-Type: text/plain; charset="utf-8"
They are also in Pd-l2ork.
On Sunday, January 10, 2016 6:36 AM, Roman Haefeli
reduzent@gmail.com wrote:
On Sun, 2016-01-10 at 09:52 +0000, Liam Goodacre wrote:
Which libraries are [closebang] and [initbang] in? They don't seem to load in Vanilla and I can't find the relevant information in the helpfiles so that I can use [declare].
I'm not totally sure, but I believe those are part of the Pd-extended core and cannot be implemented as externals. That's why you can't find them anywhere but in Pd-extended.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
There's a startup flag -noloadbang. -Jonathan
On Monday, January 11, 2016 8:57 AM, Liam Goodacre <liamg_uw@hotmail.com> wrote:
<!--#yiv6527113392 .yiv6527113392hmmessage P{margin:0px;padding:0px;}#yiv6527113392 body.yiv6527113392hmmessage{font-size:12pt;font-family:Calibri;}-->I'm more interested in stopping the loadbang than starting it. If you have a patch that dynamically creates itself (or worse deletes itself) when loaded, it is very useful to be able to inspect the patch without the the process starting. Initbang provides this because it bangs only when the patch is loaded as an abstraction, not when the patch is opened.
Message: 3 Date: Mon, 11 Jan 2016 09:41:41 +0100 From: Jack jack@rybn.org To: pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 56936AC5.6030301@rybn.org Content-Type: text/plain; charset=utf-8
Hello,
For dynamic patching, you can :
- import your abstraction in a subpatch
- send the message 'loadbang' to your subpatch
=> all your abstractions with the object 'loadbang' will send a bang when the message 'loadbang' will be send. ++
Jack
Le 11/01/2016 04:27, Liam Goodacre a écrit :
So no chance of getting them in Vanilla then? That's annoying, as they're both really useful objects. I particularly like [initbang] because it bangs only when the patch is loaded as an abstraction, not when it is opened. This is really useful for dynamic patching.
Message: 3 Date: Sun, 10 Jan 2016 13:31:36 +0000 (UTC) From: Jonathan Wilkes jancsika@yahoo.com To: Roman Haefeli reduzent@gmail.com, "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 355667468.2920260.1452432696797.JavaMail.yahoo@mail.yahoo.com Content-Type: text/plain; charset="utf-8"
They are also in Pd-l2ork.
On Sunday, January 10, 2016 6:36 AM, Roman Haefeli
reduzent@gmail.com wrote:
On Sun, 2016-01-10 at 09:52 +0000, Liam Goodacre wrote:
Which libraries are [closebang] and [initbang] in? They don't seem to load in Vanilla and I can't find the relevant information in the helpfiles so that I can use [declare].
I'm not totally sure, but I believe those are part of the Pd-extended core and cannot be implemented as externals. That's why you can't find them anywhere but in Pd-extended.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
[initbang] also helps with dynamic patching of [inlet]/[outlet], preserving connections in the parent patch. [loadbang] won't do this (last I checked anyway).
On Mon, Jan 11, 2016 at 9:57 AM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
There's a startup flag -noloadbang.
-Jonathan
On Monday, January 11, 2016 8:57 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
I'm more interested in stopping the loadbang than starting it. If you have a patch that dynamically creates itself (or worse deletes itself) when loaded, it is very useful to be able to inspect the patch without the the process starting. Initbang provides this because it bangs only when the patch is loaded as an abstraction, not when the patch is opened.
Message: 3 Date: Mon, 11 Jan 2016 09:41:41 +0100 From: Jack jack@rybn.org To: pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 56936AC5.6030301@rybn.org Content-Type: text/plain; charset=utf-8
Hello,
For dynamic patching, you can :
- import your abstraction in a subpatch
- send the message 'loadbang' to your subpatch
=> all your abstractions with the object 'loadbang' will send a bang when the message 'loadbang' will be send. ++
Jack
Le 11/01/2016 04:27, Liam Goodacre a écrit :
So no chance of getting them in Vanilla then? That's annoying, as they're both really useful objects. I particularly like [initbang] because it bangs only when the patch is loaded as an abstraction, not when it is opened. This is really useful for dynamic patching.
Message: 3 Date: Sun, 10 Jan 2016 13:31:36 +0000 (UTC) From: Jonathan Wilkes jancsika@yahoo.com To: Roman Haefeli reduzent@gmail.com, "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 355667468.2920260.1452432696797.JavaMail.yahoo@mail.yahoo.com Content-Type: text/plain; charset="utf-8"
They are also in Pd-l2ork.
On Sunday, January 10, 2016 6:36 AM, Roman Haefeli
reduzent@gmail.com wrote:
On Sun, 2016-01-10 at 09:52 +0000, Liam Goodacre wrote:
Which libraries are [closebang] and [initbang] in? They don't seem
to
load in Vanilla and I can't find the relevant information in the helpfiles so that I can use [declare].
I'm not totally sure, but I believe those are part of the Pd-extended core and cannot be implemented as externals. That's why you can't find them anywhere but in Pd-extended.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
It seems like pd-extended is kaput and pd-l2ork is not (yet) cross-platform, the new paradigm is vanilla+deken (yes?). Given that [initbang] and [closebang] can't be implemented as plugins, I wonder if there's a chance they could be folded into vanilla, maybe with a switch to enable them so that they are not there by default nor officially supported, but available to those who need them.
A guy's gotta dream big now and again.
On Mon, Jan 11, 2016 at 10:59 AM, Matt Barber brbrofsvl@gmail.com wrote:
[initbang] also helps with dynamic patching of [inlet]/[outlet], preserving connections in the parent patch. [loadbang] won't do this (last I checked anyway).
On Mon, Jan 11, 2016 at 9:57 AM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
There's a startup flag -noloadbang.
-Jonathan
On Monday, January 11, 2016 8:57 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
I'm more interested in stopping the loadbang than starting it. If you have a patch that dynamically creates itself (or worse deletes itself) when loaded, it is very useful to be able to inspect the patch without the the process starting. Initbang provides this because it bangs only when the patch is loaded as an abstraction, not when the patch is opened.
Message: 3 Date: Mon, 11 Jan 2016 09:41:41 +0100 From: Jack jack@rybn.org To: pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 56936AC5.6030301@rybn.org Content-Type: text/plain; charset=utf-8
Hello,
For dynamic patching, you can :
- import your abstraction in a subpatch
- send the message 'loadbang' to your subpatch
=> all your abstractions with the object 'loadbang' will send a bang when the message 'loadbang' will be send. ++
Jack
Le 11/01/2016 04:27, Liam Goodacre a écrit :
So no chance of getting them in Vanilla then? That's annoying, as they're both really useful objects. I particularly like [initbang] because it bangs only when the patch is loaded as an abstraction, not when it is opened. This is really useful for dynamic patching.
Message: 3 Date: Sun, 10 Jan 2016 13:31:36 +0000 (UTC) From: Jonathan Wilkes jancsika@yahoo.com To: Roman Haefeli reduzent@gmail.com, "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 355667468.2920260.1452432696797.JavaMail.yahoo@mail.yahoo.com Content-Type: text/plain; charset="utf-8"
They are also in Pd-l2ork.
On Sunday, January 10, 2016 6:36 AM, Roman Haefeli
reduzent@gmail.com wrote:
On Sun, 2016-01-10 at 09:52 +0000, Liam Goodacre wrote:
Which libraries are [closebang] and [initbang] in? They don't seem
to
load in Vanilla and I can't find the relevant information in the helpfiles so that I can use [declare].
I'm not totally sure, but I believe those are part of the Pd-extended core and cannot be implemented as externals. That's why you can't
find
them anywhere but in Pd-extended.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
Here's an idea... I could just patch Pd to make it possible for externs to do that. That wouldn't bother me (I'm horrified by hte design of 'initbang' but don't mind if someone else is maintaining it :)
cheers Miller
On Tue, Jan 12, 2016 at 10:25:08PM -0500, Matt Barber wrote:
It seems like pd-extended is kaput and pd-l2ork is not (yet) cross-platform, the new paradigm is vanilla+deken (yes?). Given that [initbang] and [closebang] can't be implemented as plugins, I wonder if there's a chance they could be folded into vanilla, maybe with a switch to enable them so that they are not there by default nor officially supported, but available to those who need them.
A guy's gotta dream big now and again.
On Mon, Jan 11, 2016 at 10:59 AM, Matt Barber brbrofsvl@gmail.com wrote:
[initbang] also helps with dynamic patching of [inlet]/[outlet], preserving connections in the parent patch. [loadbang] won't do this (last I checked anyway).
On Mon, Jan 11, 2016 at 9:57 AM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
There's a startup flag -noloadbang.
-Jonathan
On Monday, January 11, 2016 8:57 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
I'm more interested in stopping the loadbang than starting it. If you have a patch that dynamically creates itself (or worse deletes itself) when loaded, it is very useful to be able to inspect the patch without the the process starting. Initbang provides this because it bangs only when the patch is loaded as an abstraction, not when the patch is opened.
Message: 3 Date: Mon, 11 Jan 2016 09:41:41 +0100 From: Jack jack@rybn.org To: pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 56936AC5.6030301@rybn.org Content-Type: text/plain; charset=utf-8
Hello,
For dynamic patching, you can :
- import your abstraction in a subpatch
- send the message 'loadbang' to your subpatch
=> all your abstractions with the object 'loadbang' will send a bang when the message 'loadbang' will be send. ++
Jack
Le 11/01/2016 04:27, Liam Goodacre a écrit :
So no chance of getting them in Vanilla then? That's annoying, as they're both really useful objects. I particularly like [initbang] because it bangs only when the patch is loaded as an abstraction, not when it is opened. This is really useful for dynamic patching.
Message: 3 Date: Sun, 10 Jan 2016 13:31:36 +0000 (UTC) From: Jonathan Wilkes jancsika@yahoo.com To: Roman Haefeli reduzent@gmail.com, "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 355667468.2920260.1452432696797.JavaMail.yahoo@mail.yahoo.com Content-Type: text/plain; charset="utf-8"
They are also in Pd-l2ork.
On Sunday, January 10, 2016 6:36 AM, Roman Haefeli
reduzent@gmail.com wrote:
On Sun, 2016-01-10 at 09:52 +0000, Liam Goodacre wrote: > Which libraries are [closebang] and [initbang] in? They don't seem
to
> load in Vanilla and I can't find the relevant information in the > helpfiles so that I can use [declare].
I'm not totally sure, but I believe those are part of the Pd-extended core and cannot be implemented as externals. That's why you can't
find
them anywhere but in Pd-extended.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
On 01/13/2016 10:32 PM, Miller Puckette wrote:
Here's an idea... I could just patch Pd to make it possible for externs to do that. That wouldn't bother me (I'm horrified by hte design of 'initbang' but don't mind if someone else is maintaining it :)
cool, count me in. please provide possibilities to implement both initbang AND closebang (some of my perfor
alternatively, if we (well: you) could come up with a "proper design" of initbang/closebang i guess i could implement that well :-) (iirc there have been a few notes about that on the list (and maybe off-list), but i never was able to accumulate them into a document)
gmasr IOhannes
EVERYONE WINS! :)
On Wed, Jan 13, 2016 at 4:32 PM, Miller Puckette msp@ucsd.edu wrote:
Here's an idea... I could just patch Pd to make it possible for externs to do that. That wouldn't bother me (I'm horrified by hte design of 'initbang' but don't mind if someone else is maintaining it :)
cheers Miller
On Tue, Jan 12, 2016 at 10:25:08PM -0500, Matt Barber wrote:
It seems like pd-extended is kaput and pd-l2ork is not (yet) cross-platform, the new paradigm is vanilla+deken (yes?). Given that [initbang] and [closebang] can't be implemented as plugins, I wonder if there's a chance they could be folded into vanilla, maybe with a switch
to
enable them so that they are not there by default nor officially
supported,
but available to those who need them.
A guy's gotta dream big now and again.
On Mon, Jan 11, 2016 at 10:59 AM, Matt Barber brbrofsvl@gmail.com
wrote:
[initbang] also helps with dynamic patching of [inlet]/[outlet], preserving connections in the parent patch. [loadbang] won't do this
(last
I checked anyway).
On Mon, Jan 11, 2016 at 9:57 AM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
There's a startup flag -noloadbang.
-Jonathan
On Monday, January 11, 2016 8:57 AM, Liam Goodacre <
liamg_uw@hotmail.com>
wrote:
I'm more interested in stopping the loadbang than starting it. If you have a patch that dynamically creates itself (or worse deletes
itself) when
loaded, it is very useful to be able to inspect the patch without the
the
process starting. Initbang provides this because it bangs only when
the
patch is loaded as an abstraction, not when the patch is opened.
Message: 3 Date: Mon, 11 Jan 2016 09:41:41 +0100 From: Jack jack@rybn.org To: pd-list@lists.iem.at Subject: Re: [PD] closebang and initbang in Vanilla Message-ID: 56936AC5.6030301@rybn.org Content-Type: text/plain; charset=utf-8
Hello,
For dynamic patching, you can :
- import your abstraction in a subpatch
- send the message 'loadbang' to your subpatch
=> all your abstractions with the object 'loadbang' will send a bang when the message 'loadbang' will be send. ++
Jack
Le 11/01/2016 04:27, Liam Goodacre a écrit :
So no chance of getting them in Vanilla then? That's annoying, as they're both really useful objects. I particularly like [initbang] because it bangs only when the patch is loaded as an abstraction,
not
when it is opened. This is really useful for dynamic patching.
> Message: 3 > Date: Sun, 10 Jan 2016 13:31:36 +0000 (UTC) > From: Jonathan Wilkes jancsika@yahoo.com > To: Roman Haefeli reduzent@gmail.com, "pd-list@lists.iem.at" > pd-list@lists.iem.at > Subject: Re: [PD] closebang and initbang in Vanilla > Message-ID: > 355667468.2920260.1452432696797.JavaMail.yahoo@mail.yahoo.com > Content-Type: text/plain; charset="utf-8" > > They are also in Pd-l2ork. > > > On Sunday, January 10, 2016 6:36 AM, Roman Haefeli reduzent@gmail.com wrote: > > > On Sun, 2016-01-10 at 09:52 +0000, Liam Goodacre wrote: > > Which libraries are [closebang] and [initbang] in? They don't
seem
to
> > load in Vanilla and I can't find the relevant information in
the
> > helpfiles so that I can use [declare]. > > I'm not totally sure, but I believe those are part of the
Pd-extended
> core and cannot be implemented as externals. That's why you can't
find
> them anywhere but in Pd-extended. > > Roman > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > >
Thanks for the positive response here--it will make me extremely happy to have initbang running in vanilla. Should we expect to see this by the next release?
From: brbrofsvl@gmail.com Date: Wed, 13 Jan 2016 17:00:48 -0500 Subject: Re: [PD] closebang and initbang in Vanilla To: msp@ucsd.edu CC: jancsika@yahoo.com; liamg_uw@hotmail.com; pd-list@lists.iem.at
EVERYONE WINS! :) On Wed, Jan 13, 2016 at 4:32 PM, Miller Puckette msp@ucsd.edu wrote: Here's an idea... I could just patch Pd to make it possible for externs to
do that. That wouldn't bother me (I'm horrified by hte design of 'initbang'
but don't mind if someone else is maintaining it :)
cheers
Miller
On Tue, Jan 12, 2016 at 10:25:08PM -0500, Matt Barber wrote:
It seems like pd-extended is kaput and pd-l2ork is not (yet)
cross-platform, the new paradigm is vanilla+deken (yes?). Given that
[initbang] and [closebang] can't be implemented as plugins, I wonder if
there's a chance they could be folded into vanilla, maybe with a switch to
enable them so that they are not there by default nor officially supported,
but available to those who need them.
A guy's gotta dream big now and again.
On Mon, Jan 11, 2016 at 10:59 AM, Matt Barber brbrofsvl@gmail.com wrote:
[initbang] also helps with dynamic patching of [inlet]/[outlet],
preserving connections in the parent patch. [loadbang] won't do this (last
I checked anyway).
On Mon, Jan 11, 2016 at 9:57 AM, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> wrote:
There's a startup flag -noloadbang.
-Jonathan
On Monday, January 11, 2016 8:57 AM, Liam Goodacre liamg_uw@hotmail.com
wrote:
I'm more interested in stopping the loadbang than starting it. If you
have a patch that dynamically creates itself (or worse deletes itself) when
loaded, it is very useful to be able to inspect the patch without the the
process starting. Initbang provides this because it bangs only when the
patch is loaded as an abstraction, not when the patch is opened.
Message: 3
Date: Mon, 11 Jan 2016 09:41:41 +0100
From: Jack jack@rybn.org
To: pd-list@lists.iem.at
Subject: Re: [PD] closebang and initbang in Vanilla
Message-ID: 56936AC5.6030301@rybn.org
Content-Type: text/plain; charset=utf-8
Hello,
For dynamic patching, you can :
- import your abstraction in a subpatch
- send the message 'loadbang' to your subpatch
=> all your abstractions with the object 'loadbang' will send a bang
when the message 'loadbang' will be send.
++
Jack
Le 11/01/2016 04:27, Liam Goodacre a écrit :
So no chance of getting them in Vanilla then? That's annoying, as
they're both really useful objects. I particularly like [initbang]
because it bangs only when the patch is loaded as an abstraction, not
when it is opened. This is really useful for dynamic patching.
Message: 3
Date: Sun, 10 Jan 2016 13:31:36 +0000 (UTC)
From: Jonathan Wilkes jancsika@yahoo.com
To: Roman Haefeli reduzent@gmail.com, "pd-list@lists.iem.at"
Subject: Re: [PD] closebang and initbang in Vanilla
Message-ID:
355667468.2920260.1452432696797.JavaMail.yahoo@mail.yahoo.com
Content-Type: text/plain; charset="utf-8"
They are also in Pd-l2ork.
On Sunday, January 10, 2016 6:36 AM, Roman Haefeli
reduzent@gmail.com wrote:
On Sun, 2016-01-10 at 09:52 +0000, Liam Goodacre wrote:
> Which libraries are [closebang] and [initbang] in? They don't seem
to
> load in Vanilla and I can't find the relevant information in the
> helpfiles so that I can use [declare].
I'm not totally sure, but I believe those are part of the Pd-extended
core and cannot be implemented as externals. That's why you can't
find
them anywhere but in Pd-extended.
Roman
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
OK... the support should be in git - and I've put an initbang object for testing here: msp.ucsd.edu/tmp/initbang.zip
cheers Miller
On Sun, Jan 17, 2016 at 02:15:46PM +0000, Liam Goodacre wrote:
Thanks for the positive response here--it will make me extremely happy to have initbang running in vanilla. Should we expect to see this by the next release?
From: brbrofsvl@gmail.com Date: Wed, 13 Jan 2016 17:00:48 -0500 Subject: Re: [PD] closebang and initbang in Vanilla To: msp@ucsd.edu CC: jancsika@yahoo.com; liamg_uw@hotmail.com; pd-list@lists.iem.at
EVERYONE WINS! :) On Wed, Jan 13, 2016 at 4:32 PM, Miller Puckette msp@ucsd.edu wrote: Here's an idea... I could just patch Pd to make it possible for externs to
do that. That wouldn't bother me (I'm horrified by hte design of 'initbang'
but don't mind if someone else is maintaining it :)
cheers
Miller
On Tue, Jan 12, 2016 at 10:25:08PM -0500, Matt Barber wrote:
It seems like pd-extended is kaput and pd-l2ork is not (yet)
cross-platform, the new paradigm is vanilla+deken (yes?). Given that
[initbang] and [closebang] can't be implemented as plugins, I wonder if
there's a chance they could be folded into vanilla, maybe with a switch to
enable them so that they are not there by default nor officially supported,
but available to those who need them.
A guy's gotta dream big now and again.
On Mon, Jan 11, 2016 at 10:59 AM, Matt Barber brbrofsvl@gmail.com wrote:
[initbang] also helps with dynamic patching of [inlet]/[outlet],
preserving connections in the parent patch. [loadbang] won't do this (last
I checked anyway).
On Mon, Jan 11, 2016 at 9:57 AM, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> wrote:
There's a startup flag -noloadbang.
-Jonathan
On Monday, January 11, 2016 8:57 AM, Liam Goodacre liamg_uw@hotmail.com
wrote:
I'm more interested in stopping the loadbang than starting it. If you
have a patch that dynamically creates itself (or worse deletes itself) when
loaded, it is very useful to be able to inspect the patch without the the
process starting. Initbang provides this because it bangs only when the
patch is loaded as an abstraction, not when the patch is opened.
Message: 3
Date: Mon, 11 Jan 2016 09:41:41 +0100
From: Jack jack@rybn.org
To: pd-list@lists.iem.at
Subject: Re: [PD] closebang and initbang in Vanilla
Message-ID: 56936AC5.6030301@rybn.org
Content-Type: text/plain; charset=utf-8
Hello,
For dynamic patching, you can :
- import your abstraction in a subpatch
- send the message 'loadbang' to your subpatch
=> all your abstractions with the object 'loadbang' will send a bang
when the message 'loadbang' will be send.
++
Jack
Le 11/01/2016 04:27, Liam Goodacre a écrit :
So no chance of getting them in Vanilla then? That's annoying, as
they're both really useful objects. I particularly like [initbang]
because it bangs only when the patch is loaded as an abstraction, not
when it is opened. This is really useful for dynamic patching.
> Message: 3
> Date: Sun, 10 Jan 2016 13:31:36 +0000 (UTC)
> From: Jonathan Wilkes jancsika@yahoo.com
> To: Roman Haefeli reduzent@gmail.com, "pd-list@lists.iem.at"
> Subject: Re: [PD] closebang and initbang in Vanilla
> Message-ID:
> 355667468.2920260.1452432696797.JavaMail.yahoo@mail.yahoo.com
> Content-Type: text/plain; charset="utf-8"
>
> They are also in Pd-l2ork.
>
>
> On Sunday, January 10, 2016 6:36 AM, Roman Haefeli
reduzent@gmail.com wrote:
>
>
> On Sun, 2016-01-10 at 09:52 +0000, Liam Goodacre wrote:
> > Which libraries are [closebang] and [initbang] in? They don't seem
to
> > load in Vanilla and I can't find the relevant information in the
> > helpfiles so that I can use [declare].
>
> I'm not totally sure, but I believe those are part of the Pd-extended
> core and cannot be implemented as externals. That's why you can't
find
> them anywhere but in Pd-extended.
>
> Roman
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
>
>
>
>
On 2016-01-19 00:42, Miller Puckette wrote:
OK... the support should be in git
thank you very much.
while i find the API very elegant, i have one question: will existing externals with loadbang functionality now start banging three times during their life-cycle?
a first test with iemlib's [init] exhibits triggers on initbang and loadbang, but not on closebang...i might miss something though
gmasdr IOhannes
On 01/19/2016 10:00 AM, IOhannes m zmoelnig wrote:
a first test with iemlib's [init] exhibits triggers on initbang and loadbang, but not on closebang...i might miss something though
found the culprit: canvas_closebang() never gets called when deleting an abstraction.
attached patch fixes this.
gfmsadr IOhannes
Good, thanks.
Next: for people who are trying to close OS resources when Pd quits, I'm thinking there should be a fourth phase, "LB_PANIC", which objects should not respond to by passing messages but only closing resources.
cheers Miller
On Tue, Jan 19, 2016 at 02:07:32PM +0100, IOhannes m zmölnig wrote:
On 01/19/2016 10:00 AM, IOhannes m zmoelnig wrote:
a first test with iemlib's [init] exhibits triggers on initbang and loadbang, but not on closebang...i might miss something though
found the culprit: canvas_closebang() never gets called when deleting an abstraction.
attached patch fixes this.
gfmsadr IOhannes
From fc83f3253f7b1e661a270f7ada9e47ccd8314466 Mon Sep 17 00:00:00 2001 From: IOhannes m zmoelnig zmoelnig@umlautQ.umlaeute.mur.at Date: Tue, 19 Jan 2016 14:04:48 +0100 Subject: [PATCH] emit closebang before an abstraction is closed
src/g_graph.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/src/g_graph.c b/src/g_graph.c index d01c803..eb347a1 100644 --- a/src/g_graph.c +++ b/src/g_graph.c @@ -62,6 +62,9 @@ int canvas_setdeleting(t_canvas *x, int flag) return (ret); }
- /* JMZ: emit a closebang message */
+void canvas_closebang(t_canvas *x);
- /* delete an object from a glist and free it */
void glist_delete(t_glist *x, t_gobj *y) { @@ -73,6 +76,11 @@ void glist_delete(t_glist *x, t_gobj *y) int drawcommand = class_isdrawcommand(y->g_pd); int wasdeleting;
- if (pd_class(&y->g_pd) == canvas_class) {
/* JMZ: send a closebang to the canvas */canvas_closebang((t_canvas *)y);- }
- wasdeleting = canvas_setdeleting(canvas, 1); if (x->gl_editor) {
-- 2.7.0.rc3
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
- 1
Some behaviour congruent with POSIX signals has always been on my wishlist. Those (admittedly rare) occasions when some unrecoverable IO blockage happens it would be nice to rescue the patch.
cheers, Andy
On Tue, Jan 19, 2016 at 08:22:13AM -0800, Miller Puckette wrote:
Good, thanks.
Next: for people who are trying to close OS resources when Pd quits, I'm thinking there should be a fourth phase, "LB_PANIC", which objects should not respond to by passing messages but only closing resources.
cheers Miller
On Tue, Jan 19, 2016 at 02:07:32PM +0100, IOhannes m zmölnig wrote:
On 01/19/2016 10:00 AM, IOhannes m zmoelnig wrote:
a first test with iemlib's [init] exhibits triggers on initbang and loadbang, but not on closebang...i might miss something though
found the culprit: canvas_closebang() never gets called when deleting an abstraction.
attached patch fixes this.
gfmsadr IOhannes
From fc83f3253f7b1e661a270f7ada9e47ccd8314466 Mon Sep 17 00:00:00 2001 From: IOhannes m zmoelnig zmoelnig@umlautQ.umlaeute.mur.at Date: Tue, 19 Jan 2016 14:04:48 +0100 Subject: [PATCH] emit closebang before an abstraction is closed
src/g_graph.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/src/g_graph.c b/src/g_graph.c index d01c803..eb347a1 100644 --- a/src/g_graph.c +++ b/src/g_graph.c @@ -62,6 +62,9 @@ int canvas_setdeleting(t_canvas *x, int flag) return (ret); }
- /* JMZ: emit a closebang message */
+void canvas_closebang(t_canvas *x);
- /* delete an object from a glist and free it */
void glist_delete(t_glist *x, t_gobj *y) { @@ -73,6 +76,11 @@ void glist_delete(t_glist *x, t_gobj *y) int drawcommand = class_isdrawcommand(y->g_pd); int wasdeleting;
- if (pd_class(&y->g_pd) == canvas_class) {
/* JMZ: send a closebang to the canvas */canvas_closebang((t_canvas *)y);- }
- wasdeleting = canvas_setdeleting(canvas, 1); if (x->gl_editor) {
-- 2.7.0.rc3
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Next: for people who are trying to close OS resources when Pd quits, I'm
thinking there should be a fourth phase, "LB_PANIC", which objects should not respond to by passing messages but only closing resources. What's a situation where Pd currently won't close its resources upon quitting?
-Jonathan
On Tuesday, January 19, 2016 1:14 PM, Andy Farnell <padawan12@obiwannabe.co.uk> wrote:
- 1
Some behaviour congruent with POSIX signals has always been on my wishlist. Those (admittedly rare) occasions when some unrecoverable IO blockage happens it would be nice to rescue the patch.
cheers, Andy
On Tue, Jan 19, 2016 at 08:22:13AM -0800, Miller Puckette wrote:
Good, thanks.
Next: for people who are trying to close OS resources when Pd quits, I'm thinking there should be a fourth phase, "LB_PANIC", which objects should not respond to by passing messages but only closing resources.
cheers Miller
On Tue, Jan 19, 2016 at 02:07:32PM +0100, IOhannes m zmölnig wrote:
On 01/19/2016 10:00 AM, IOhannes m zmoelnig wrote:
a first test with iemlib's [init] exhibits triggers on initbang and loadbang, but not on closebang...i might miss something though
found the culprit: canvas_closebang() never gets called when deleting an abstraction.
attached patch fixes this.
gfmsadr IOhannes
From fc83f3253f7b1e661a270f7ada9e47ccd8314466 Mon Sep 17 00:00:00 2001 From: IOhannes m zmoelnig zmoelnig@umlautQ.umlaeute.mur.at Date: Tue, 19 Jan 2016 14:04:48 +0100 Subject: [PATCH] emit closebang before an abstraction is closed
src/g_graph.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/src/g_graph.c b/src/g_graph.c index d01c803..eb347a1 100644 --- a/src/g_graph.c +++ b/src/g_graph.c @@ -62,6 +62,9 @@ int canvas_setdeleting(t_canvas *x, int flag) return (ret); } + /* JMZ: emit a closebang message */ +void canvas_closebang(t_canvas *x);
/* delete an object from a glist and free it */ void glist_delete(t_glist *x, t_gobj *y) { @@ -73,6 +76,11 @@ void glist_delete(t_glist *x, t_gobj *y) int drawcommand = class_isdrawcommand(y->g_pd); int wasdeleting; + if (pd_class(&y->g_pd) == canvas_class) { + /* JMZ: send a closebang to the canvas */ + canvas_closebang((t_canvas *)y); + }
wasdeleting = canvas_setdeleting(canvas, 1); if (x->gl_editor) { -- 2.7.0.rc3
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/19/2016 08:35 PM, Jonathan Wilkes via Pd-list wrote:
Next: for people who are trying to close OS resources when Pd quits, I'm
thinking there should be a fourth phase, "LB_PANIC", which objects should not respond to by passing messages but only closing resources. What's a situation where Pd currently won't close its resources upon quitting?
you mean https://sourceforge.net/p/pure-data/patches/82/?
i'm pretty exited about LB_PANIC as it suggests that #82 might get resolved!
gfamrds IOhannes
Sort of. I think it's a bad idea to go through and close all the windows (sometimes closing a window takes time) - but just send objects a message in case they need to get off some resource. I don't have any examples to hand, except a rather lame one: sending an all-notes-off message to some MIDI output.
cheers M
On Tue, Jan 19, 2016 at 08:54:12PM +0100, IOhannes m zmölnig wrote:
On 01/19/2016 08:35 PM, Jonathan Wilkes via Pd-list wrote:
Next: for people who are trying to close OS resources when Pd quits, I'm
thinking there should be a fourth phase, "LB_PANIC", which objects should not respond to by passing messages but only closing resources. What's a situation where Pd currently won't close its resources upon quitting?
you mean https://sourceforge.net/p/pure-data/patches/82/?
i'm pretty exited about LB_PANIC as it suggests that #82 might get resolved!
gfamrds IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2016-01-19 20:59, Miller Puckette wrote:
Sort of. I think it's a bad idea to go through and close all the windows (sometimes closing a window takes time) - but just send objects a message in case they need to get off some resource.
i'm not really interesting about "closing windows". what i do want is to call the "free" method of each object though (assuming that those objects are written properly to free any open ressources in their destructor).
I don't have any examples to hand, except a rather lame one: sending an all-notes-off message to some MIDI output.
so one from the new millenium: locking a network ressource (e.g. an gigabit IP-camera that saturates the the network once it's told to start delivering frames).
fgamsd IOhannes
so one from the new millenium: locking a network ressource (e.g. an
gigabit IP-camera that saturates the the network once it's told to start delivering frames). What happens currently if you click <ctrl-c> in the terminal on a Pd instance that's using that network resource? Is LB_PANIC a public interface (having an external and/or pd class interface)? Or is it a private interface that Pd would use to call free methods? Is there a deep reason to have it named "panic" which clashes with its meaning in Linux?
I don't have any examples to hand, except a rather lame one: sending an all-notes-off message to some MIDI output.
A naive question-- suppose I have a [foo] external in my patch and click <ctrl-c>.If LB_PANIC calls foo_free, and I have a blocking call there to free up resources for libborksalot.so, what happens? If that resource just hangs, is my terminal likewise now hanging, unresponsive?
-Jonathan
On Tuesday, January 19, 2016 3:52 PM, IOhannes m zmoelnig <zmoelnig@iem.at> wrote:
On 2016-01-19 20:59, Miller Puckette wrote:
Sort of. I think it's a bad idea to go through and close all the windows (sometimes closing a window takes time) - but just send objects a message in case they need to get off some resource.
i'm not really interesting about "closing windows". what i do want is to call the "free" method of each object though (assuming that those objects are written properly to free any open ressources in their destructor).
I don't have any examples to hand, except a rather lame one: sending an all-notes-off message to some MIDI output.
so one from the new millenium: locking a network ressource (e.g. an gigabit IP-camera that saturates the the network once it's told to start delivering frames).
fgamsd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/19/2016 10:00 AM, IOhannes m zmoelnig wrote:
On 2016-01-19 00:42, Miller Puckette wrote:
OK... the support should be in git
thank you very much.
ok.
so the new and shiny iemguts-0.2 [1] features both [initbang] and [closebang].
these will magically start working as soon as use Pd>=0.47. this also means, they magically won't work with any *currently* available Pd (even git, which still claims to be 0.46)... (hint: shouldn't the version number in m_pd.h be bumped to something line "0.47-0 ([WIP])"?)
Debian packages have been uploaded, they should appear in the archives within the next few hours.
gmsadr IOhannes
-
Andy Farnell -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Liam Goodacre -
Matt Barber -
Miller Puckette