I am recording from microphone into a table (for 2 seconds). Then from a separate sub patch using messaging i send a bang to a tabplay~ to play the table. Although the bang is being sent (testing with print) it doesn't trigger the tabplay~. The strange thing is that as soon as i save the patches and the window, the tabplay~ starts playing! I have no clue what is going on? Could some one possibly help?

This is the message which send the bang for playing the tabplay~:

and here is where i was expecting the bang:

@amirt Your message should probably be [pd-some-subpatch obj x y my-abstraction $1 $2(
..... without the hyphens.... if you want your abstraction to have arguments they should not be part of the "name".
example.zip
David.

@amirt I think your issue is related to this bug: https://github.com/pure-data/pure-data/issues/362

Here is a demo to reproduce the bug: demo.zip

There is also a possible workaround included: If you turn dsp off an on again, the dsp objects within the abstraction start working.

Here is another demo that may offer a solution: demo.zip

As also loadbang doesn't work in dynamically created abstractions, this sends a bang to the abstraction after creation that makes the abstraction save itself. By doing this, dsp objects within the abstraction are working.

There is even another way: As selecting an object with the mouse in edit mode and then duplicating it also triggers the dsp to work, it is possible to simulate this behavior with dynamic patching and thus have audio objects work in dynamically created abstractions without saving or turning dsp on and off. Here again it is necessary to send a bang from outside to initiate the process: demo.zip

@ingox Opening another patch works too. I have always opened a main gui after all the audio sub-patches are built, so I never noticed this problem.
A real head twister when the problem occurs. Well spotted....!
David.

@ingox That is exactly what i am experiencing! Thank you for the link, now i know at least that it is a pd problem!

@ingox Your solutions perfectly solved the problem

@ingox Is the [menusave( a special message that namecanvas understands?

@amirt Check out all the internal messages that can be used for dynamic patching: https://forum.pdpatchrepo.info/topic/10813/collection-of-pd-internal-messages-dynamic-patching

You can send these messages to a canvas via [s pd-name-of-canvas].

[namecanvas] can be used so you don't have to worry about filenames and can use the name set by [namecanvas] instead.

Like this:

[dynamic patching message(
|
[s mycanvasname]

[namecanvas mycanvasname]

--
Edit: „canvas“ has two meanings in Pd: One is the graphic canvas object that is just a rectangle that can have colors. The other is canvas as Pd patch. Above i am refering to the latter one. Has nothing to do with the graphical canvas you can insert via put menu.

edited sorry left off loadbang

using cut then paste then loadbang in the message while creating also seems to work

@Balwyn Cut and paste probably work if you start Pd anew, but if you have already copied an object to the clipbord, it will paste this object instead. It seems that the cut doesn't do anything, as nothing is selected. The mouse commands could be used to select the abstraction and then cut & paste it though...

Cool thing with sending the loadbang message, was not aware of that!

@ingox Oh yes, I see, the cut & paste is just creating an event.
using that idea this seem to work

@Balwyn You can also just turn on DSP directly in the abstraction, rather than turning it off and on in the sub-patch or doing any editing........

Although that will crash Pd if DSP is not turned on, generally, already. So probably a message to Pd to turn dsp on first would be best.
demo.zip
AAArgh...... extended only..... doesn't work for Vanilla.....
David.

@whale-av maybe turn it off and on in the message?

@Balwyn To me "menusave" seems the least disruptive...... here saving the abstraction so as not to change the main patch. The delay is unnecessary, but suppresses an error message.
The abstraction will not have changed so it is not harmful.
No need to write menusave into the abstraction, but @ingox had the original idea.
Vanilla and Extended.
demo.zip
And the delay is unnecessary if an incoming message initiates....... demo2.zip
It simply automates what @amirt was forced to do to make it work.
David.

@whale-av Now i got a new problem with saving the abstraction using menusave message: since my abstractions are created dynamically by attempting to create a second abstraction pd crashes with a segmentation fault error! However your second solution with simulating mouse clicks seems to work

@amirt Do you mean the contents of the abstraction are created dynamically, or the abstractions are placed in the one (or more) sub-patches dynamically?
If the latter then it should work....... demo3.zip
TURN the volume DOWN..... it will create 10 copies.

If the former then don't forget that when you save an abstraction all copies will change to that saved file and be re-loaded.
David.