[PD] loadbang in dynamic abstractions

[B. Bogart]

Hey Roman,

I did not realize there was a special receive for a patch to send its
loadbang! Thanks for teaching me a little something.

I was about to impliment this in my pixelTANGO abstractopm when I
relized a little snag.

We can send messages to an abstraction:

[myabst]

with

[; pd-myabst.pd <

BUT what if I call my abstraction with:

[/long/ugly/path/to/myabst]

I dont think that this would work:

[; pd-/long/ugly/path/to/myabst.pd <

Ah, well it looks like you still use pd-myabst.pd

We'll that was fun, Now I need another python script to strip the
pathname from the abstraction name!

I still think it is more elegant to do it this way.

Thanks for the tip Roman.

I'll let you know about any delay once I'm at that point.

B>



Roman Haefeli wrote:
> please forgive my stubborness.........
> can you send me an example? i'm just wondering, because i once did a
> patch with dynamically created abs, in which other abs were created
> dynamically .. and so on, and it worked all fine (with several messages,
> too).
> also doing something like:
>
> [112(
> |
> [t b b f]
> |      |       \
> |     [repeat 0]
> |      |
> |     [; pd-patch.pd obj 10 10 myabs(
> |
> [; pd-myabs.pd loadbang(
>
> works fine on my machine, altough it takes a few miliseconds to create
> all [myabs], but all [myabs] get a loadbang. i never experienced yet
> that pd does NOT keep execution order because of the time it takes to
> build the gui or dsp-chain or whatever. but obviously i did not try
> everything.
>
> cheers
> roman
>
>
> ----- Original Message -----
> From: "B. Bogart" <ben at ekran.org>
>
>>*cough*
>>
>>I unfortunatly found many issues with things not happening in the
>>correct time. Well that is to say when you dynamically create an array
>>of objects the time between the message being send and the object
>>actually being ready to receive messages is not 0ms. I can't remember
>>the delay I needed, but indeed some abstractions would not get the
>
> bang
>
>>message if I sent it immediatly after the message to create the last
>>abstraction. This is on OSX, which has had some GUI issues in the
>
> past,
>
>>could be related.
>>
>>Oh and this is also because I'm not creating my whole dynamic patch
>
> with
>
>>one message, but multiple messages. (This is because I'm creating one
>>abstraction for each file in a directory)Also the number of files is
>>indeterminant so I can't create one message to do it all...
>
>
>>I guess the best way to test if the last object is done would be to
>
> have
>
>>it send a message "I'm done!" to the parent patch and then we know all
>>the abstractions are ready... Maybe I'll do this...
>>
>>Back to replacing my TOTs with PYs.
>>
>>b>
>>
>>Roman Haefeli wrote:
>>
>>>hi ben
>>>
>>>
>>>----- Original Message -----
>>>From: "B. Bogart" <ben at ekran.org>
>>>
>>>>Hey Tom,
>>>>
>>>>If you look at pt.layerfx in pixelTANGO I'm sending a bang to all
>>>>dynamic abstractions after all the creation messages have been sent
>>>
>>>and
>>>
>>>
>>>>an additional (arbitrary) delay. It seems to work...
>>>
>>>
>>>are you sure, that a delay is necessary? in my experience, the
>>>determinisme of pd is absolutely reliable. i mean, when i use a [t b
>
> b]
>
>>>and i use the first 'bang' to create the whole patch and the second
>
> one
>
>>>the send the 'loadbang' it works perfectly.
>>>afaik, pd rather drops the audio-processing for while than dropping a
>>>message. at least i experienced that if i create big patches
>>>dynamically, i get audio drop-outs.
>>>
>>>
>>>
>>>>It would be damn handy to have tcl/tk report when a dynamic patch has
>>>>finished building.
>>>
>>>
>>>in case i am right, this wouldn't be necessary anymore... or would
>
> it?
>
>>>cheers
>>>roman
>
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20050328/479098e1/attachment.pgp>