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 I don't know offhand, but if you'd be willing to share the smallest version of your program that exhibits the problem I'd be interested in checking it out.

@jameslo How should i share it with? You want me to put it on github? By the way i found now where the problem is, but i am not sure if it is a bug! The situation is the following:

i am creating abstractions dynamically (using messaging techniques like [pd-some-subpatch obj x y my-abstraction-$1-$2(). These dynamically created abstractions are getting at later times some data from the main subpatch (like a bang to record at a tabwrite~ etc.), but they are not reacting to any of these data, untill i have manually done some work on the abstraction window (this could be sor instance Ctrl+s to save the current situation of the abstraction), then the abstraction will come to live immediately. I have no idea why is this happening and am totally lost!

@amirt $1, $2 etc. in objects are used to get the creation arguments of an abstraction.

With [abstraction 12 25] a list object [list $1 $2] inside the abstraction will contain the list [12 25(.

To create abstractions with creation arguments via dynamic patching, you have to include the creation arguments:

[obj x y abstraction 12 25(
|
[s pd-subpatch]

With this, a receive object like [r ch-$1-$2-play] inside the abstraction should work and should listen on ch-12-25-play.

Here is a demo: demo.zip

You can upload patches here in the forum by using the upload button next to the emoticon button

@ingox Sorry, i of course create the abstractions with their arguments, (i forgott to write them in the example, corrected).

@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.