is it correct behavior that loadbang will not be called when it is part of a dynamically created object? See attached. If you load test-do, it will create an instance of test when you click on the message. Test should print loadbang and initbang, but it only prints initbang.
I've tested you patch, happens here too. But I'm no expert in this behavior. :)
p.s.: The help patch on "loadbang" states that a bang is sent when the patch is loaded. Is it a semantic issue? Patch vs. abstraction? or merely a problem.. 'Cause initbang "bangs".
2011/2/19 John Harrison johnharrisonwsu@gmail.com
yes, this is known.
By known you mean.. Is it on the bug tracker already?
When such things are discovered (and by things I mean issues), shouldn't they be documented inside the help patches?
It helps a lot those getting inside pd.
Best, pedro
On Sat, Feb 19, 2011 at 7:44 PM, cyrille henry ch@chnry.net wrote:
Cyrille I just tried your solution and the problem is that all objects sharing the name of the dynamically-created object all get the loadbang message.
On Sat, Feb 19, 2011 at 1:49 PM, Pedro Lopes pedro.lopes@ist.utl.pt wrote:
Le 19/02/2011 20:58, John Harrison a écrit :
Cyrille I just tried your solution and the problem is that all objects sharing the name of the dynamically-created object all get the loadbang message.
yes. you should create them all in the same time, and then send the loadbang. if this is not possible, you can still : -use different name on your object -use argument on the abstraction and send to bang to a [receive loadbang-$1] object inside your abstraction -use initbang -use a [oneshot] object (or similar) after the loadbang
anyway, i think using dynamic creation in real time is bad. imho, it really should be limited for patch creation.
c
On Sat, Feb 19, 2011 at 9:07 PM, cyrille henry ch@chnry.net wrote:
anyway, i think using dynamic creation in real time is bad. imho, it really should be limited for patch creation.
Hi Cyrille, can you explain better your position please? I have been using dynamic patching in real time a lot in my works and I didn't noticed big problems. It's more: it will be very hard to me realize some programming without using dynamic creation at all. So i'm just curious. saluts husk
anyway, i think using dynamic creation in real time is bad.
I don't. I know that you are probably just referring to the fact that it affects performance and recomputes the DSP graph. But that would be the same to call a gamedev and say: "don't create assets dynamically, create them all at game start" - which is insane, there is a wide number of stuff in a lot of engines that force a recompile of blob-trees, meshes, and other 3d-data-structures, but it always depends on the "amount of data" and the "frequency of those calls".
imho, it really should be limited for patch creation.
imho no. Depends on the situation, maybe you can say that you've seen people overdo-it. (I haven't) As far as my experience, It suits what I need. I have patches that create modules on user demand (for audio processing, and so forth), and there is no need to create them in advance (although it is possible and then just manage them later with dynamic routing) but performance falls well under my needs so I apply dynamic patching in realtime.
I'd like to hear you out on this matter, maybe several situations could not apply to d. patching in rt, thus it is good to learn.
Best regards, Pedro
On Sat, Feb 19, 2011 at 8:07 PM, cyrille henry ch@chnry.net wrote:
Le 19/02/2011 20:49, Pedro Lopes a écrit :
yes, this is known.
By known you mean.. Is it on the bug tracker already?
no, it's not considered as a bug.
When such things are discovered (and by things I mean issues), shouldn't they be documented inside the help patches?
dynamic patching is not officially supported.
if issues are discovered (and by this i mean bug), they should be post on the bug tracker, to be corrected. c
uhhh "not officially supported" sounds great.
Okay, didn't knew that position. Comment withdrawn.
Best, Pedro
On Sat, Feb 19, 2011 at 8:01 PM, cyrille henry ch@chnry.net wrote:
On Sat, 19 Feb 2011, Pedro Lopes wrote:
uhhh "not officially supported" sounds great. Okay, didn't knew that position. Comment withdrawn.
Ah, btw, you have to know what official means in the pd world.
GUI classes outside of Pd are all using unofficial, unsupported APIs.
It's been like that for over ten years. All that time, people have been bundling g_canvas.h with their externals because Pd distributions don't come with that file, because it's unofficial.
That's what unofficial means around here : without unofficial APIs, you can hardly get anything done.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Yeah, if its the logical behaviour of the "class": ok. As i said, comment withdrawn.
I agree with Mathieu, I'll just use one of the unsupported stuff out there.
2011/2/20 IOhannes zmölnig zmoelnig@iem.at
On Sun, 20 Feb 2011, Pedro Lopes wrote:
Yeah, if its the logical behaviour of the "class": ok. As i said, comment withdrawn.
There's a [loadbang] class of objects, but we're talking about a collection of methods all named "loadbang" : one in class [loadbang], one in class canvas ([pd], abstractions, main patches), and then, one in [bng], one in [tgl], etc.
The relationship between all those "loadbang" methods could be called a protocol : the loadbang protocol is the description of how loadbanging is supposed to be working in pd, overall.
(This concept of "protocol" is also called "interface" or "contract" : it depends on which book you use, to learn about programme design.)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sat, Feb 19, 2011 at 07:49:09PM +0000, Pedro Lopes wrote:
yes, this is known.
By known you mean.. Is it on the bug tracker already?
As Cyrille wrote, it's not a bug, but a feature: Usually when you use an abstraction in your patch and you load that patch, everything inside of that abstraction is loaded first, including its loadbangs, then the surrounding patch goes through its own loadbangs. Normally you don't recognize this, but the order becomes important, when the abstraction sends something to the surrounding patch for example through its outlet. Then the rule is: First the abstractions sends through the outlet, possibly influencing stuff in the main patch, then the main patch loadbangs. See the attachement "main.pd" for an illustration of this behaviour.
Now dynamic patching basically is the same as loading a patch: The messages are almost the same, only now they get sent to a [pd something] subpatch-receiver instead of to Pd's internal objectmaker. You can see this in the second example, main-dynamic.pd, whic just patches the contents of main.pd into a subpatch.
The important difference is the handling of loadbangs: If an abstraction like [lb-abs] would execute its loadbang immediatly, then it would bang to an outlet, that is not yet connected! So in the end your result would be different from the result you get when loading main.pd, although it's the same construction.
To overcome this ambiguity, loadbanging in dynamic patching is an explicit action: You have to initiate the loadbangs at an appropriate time that you decide on your own. Ususally it's fine to do that by sending a "loadbang" message at the end of your dynamic patching cycle, to the same receiver. This way also the execution order of the construct you've build will be preserved in execution of the loadbangs and initialisation.
When such things are discovered (and by things I mean issues), shouldn't they be documented inside the help patches?
There are no official help patches for dynamic patching, only the tutorial floating around somewhere, which I can't find ATM. The loadbang explanation should probably be inside of this, if it isn't already.
Frank Barknecht Do You RjDj.me? _ ______footils.org__
--- On Mon, 2/21/11, Frank Barknecht fbar@footils.org wrote:
I think I need to add the term "official" to the (probably unofficial*) Pd glossary.
What does it mean? I.e., what information are you trying to convey by using it?
-Jonathan
The slightly fuzzier expression "widely recognised as good practice" might substitute.
Once something appears in the core help files, then when it goes horribly wrong they might be tempted to interpret it as a bug, rather than realising they were on shaky foundations in the first place.
On Mon, 21 Feb 2011 12:28:58 -0800 (PST) Jonathan Wilkes jancsika@yahoo.com wrote:
--- On Mon, 2/21/11, Andy Farnell padawan12@obiwannabe.co.uk wrote:
That can't be, because there are things in the official docs-- like wires overlapping xlets in the audio tutorial, for example-- that are widely recognised as bad practice.
That makes sense if we're comparing core help docs to, say, docs on an experimental external library. But concerning the dynamic patching docs (pd-msg), what's the shaky ground?
Either you or Frank: Tell me what's wrong with the pd-msg docs, and what needs improvement to achieve the standard of "official docs" and I'll make those changes.
-Jonathan
Hi,
On Mon, Feb 21, 2011 at 06:00:22PM -0800, Jonathan Wilkes wrote:
Tell me what's wrong with the pd-msg docs, and what needs improvement to achieve the standard of "official docs" and I'll make those changes.
I already wrote what's wrong. Now I have committed an updated loadbang example patch based on the example and text I posted earlier.
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Hi,
On Mon, Feb 21, 2011 at 12:28:58PM -0800, Jonathan Wilkes wrote:
Awgh, come on!
We all know, that dynamic patching, while very useful, still is considered exploiting internal implementation details, and has never been encouraged nor documented by its author, Miller.
If it makes you feel better, let me express it this way: The tutorial "pd-msg" [*] for dynamic patching contains a section on the loadbang message that could be improved 8 years, 3 months after it was written:
[*] pure-data/trunk/doc/additional/pd-msg/1.msg_and_patch/5.loadbang.pd
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Tue, 22 Feb 2011, Frank Barknecht wrote:
Yet if Miller changed internals so that dynamic patching becomes impossible, what would he achieve with that ? What would you do ? What would I do ? What would other people do about it ?
It does not help anyone, to know that Miller doesn't encourage some of the most interesting patching in the Pd community.
What are you trying to achieve, by restating Miller's position ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Mon, 2/21/11, Frank Barknecht fbar@footils.org wrote:
[...]
doc/manuals/pd-msg/1.msg_and_patch/5.loadbang.pd
-Jonathan
On Sat, 19 Feb 2011, John Harrison wrote:
initbang is called when your [test] abstraction is finished loading.
loadbang is called when your [test] abstraction's parent is finished loading. in the case of dynamic patching, you're supposed to know when you're finished "instantiating", and then call "loadbang" by yourself.
If your dynamic patching is incremental, you may use [gf/canvas_loadbang] with [gf/canvas_count], to send loadbang only to the new objects (and not to those that are supposed to have already received loadbang).
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC