Hi List,
I've been increasingly working with dynamic patching and there is an issue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall one instance of it from the main patch (already computing audio). This is what happens:
The abstraction will not produce sound until I:
a) save the patch b) create another abstraction with the same name (another audio object will not work) c) I click on a already existing object in the main patch (clicking on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable)
I attach an example:
Any insights or ideas about how to solve this?
with kind regards,
Angel Faraldo _________________ www.angelfaraldo.info
I tried your patch and the problem you mention does occur. I've no idea why and how to solve this, but I'm also getting some strange behavior with live patching. In my case [loadbang] won't work...
On Mon, Nov 12, 2012 at 5:29 PM, Ángel Faraldo angelfaraldo@gmail.comwrote:
Hi List,
I've been increasingly working with dynamic patching and there is an issue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall one instance of it from the main patch (already computing audio). This is what happens:
The abstraction will not produce sound until I:
a) save the patch b) create another abstraction with the same name (another audio object will not work) c) I click on a already existing object in the main patch (clicking on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable)
I attach an example:
Any insights or ideas about how to solve this?
with kind regards,
Angel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The answer to the original question has been posted many times over the years.
On Wednesday, November 14, 2012, Alexandros Drymonitis wrote:
I tried your patch and the problem you mention does occur. I've no idea why and how to solve this, but I'm also getting some strange behavior with live patching. In my case [loadbang] won't work...
On Mon, Nov 12, 2012 at 5:29 PM, Ángel Faraldo <angelfaraldo@gmail.com<javascript:_e({}, 'cvml', 'angelfaraldo@gmail.com');>
wrote:
Hi List,
I've been increasingly working with dynamic patching and there is an issue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall one instance of it from the main patch (already computing audio). This is what happens:
The abstraction will not produce sound until I:
a) save the patch b) create another abstraction with the same name (another audio object will not work) c) I click on a already existing object in the main patch (clicking on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable)
I attach an example:
Any insights or ideas about how to solve this?
with kind regards,
Angel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at <javascript:_e({}, 'cvml', 'Pd-list@iem.at');> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 14/11/2012 11:30, Alexandros Drymonitis a écrit :
I tried your patch and the problem you mention does occur. I've no idea why and how to solve this, but I'm also getting some strange behavior with live patching. In my case [loadbang] won't work...
when sending message to pd to create objects, one also have to manually send the loadbang messages. reasons are details in the archive. [loadbang bang< | [s pd-foo]
cheers c
On Mon, Nov 12, 2012 at 5:29 PM, Ángel Faraldo <angelfaraldo@gmail.com mailto:angelfaraldo@gmail.com> wrote:
Hi List, I've been increasingly working with dynamic patching and there is an issue that don't understand in relation with creating multiple audio abstractions... Imagine I put an oscillator inside an abstraction and I recall one instance of it from the main patch (already computing audio). This is what happens: The abstraction will not produce sound until I: a) save the patch b) create another abstraction with the same name (another audio object will not work) c) I click on a already existing object in the main patch (clicking on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable) I attach an example: Any insights or ideas about how to solve this? with kind regards, Angel Faraldo _________________ www.angelfaraldo.info <http://www.angelfaraldo.info> _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Or use [initbang]...after i go banana's reply I searched a bit and found out that my question has also been answered. It won't be vanilla though, but anyway I'm using extended..
Cheers
On Wed, Nov 14, 2012 at 12:54 PM, Cyrille Henry ch@chnry.net wrote:
Le 14/11/2012 11:30, Alexandros Drymonitis a écrit :
I tried your patch and the problem you mention does occur. I've no idea
why and how to solve this, but I'm also getting some strange behavior with live patching. In my case [loadbang] won't work...
when sending message to pd to create objects, one also have to manually
send the loadbang messages. reasons are details in the archive. [loadbang bang< | [s pd-foo]
cheers c
On Mon, Nov 12, 2012 at 5:29 PM, Ángel Faraldo <angelfaraldo@gmail.commailto: angelfaraldo@gmail.com**> wrote:
Hi List, I've been increasingly working with dynamic patching and there is anissue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall oneinstance of it from the main patch (already computing audio). This is what happens:
The abstraction will not produce sound until I: a) save the patch b) create another abstraction with the same name (another audioobject will not work) c) I click on a already existing object in the main patch (clicking on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable)
I attach an example: Any insights or ideas about how to solve this? with kind regards, Angel Faraldo _________________ www.angelfaraldo.info <http://www.angelfaraldo.info> ______________________________**_________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/**listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Thanks for your replies,
indeed I was reading on the list and there are various threads on this topic. Apologies for re-asking old threads.
In my current project, I wasn't planning to create the objects with messages (obj ... ... ..., i.e. dynamic patching) but manually adding objects which produce sound on the fly.
Therefore, [initbang] doesn't make a difference here, because loadbangs are actually initialized when loading an abstraction manually, and turning dsp audio off and on produces a longer-than-desirable silence gap when I create a new abstraction, so although advisable on regular situations, it doesn't seem to be the solution here.
So, although maybe not the most elegant, I've managed to solve it by sending the abstraction's [loadbang] to the main patch to dynamically save the latter. This way I get the sound of the abstraction immediately.
Cheers and thanks again.
ángel
On 14/11/2012, at 12:03, Alexandros Drymonitis wrote:
Or use [initbang]...after i go banana's reply I searched a bit and found out that my question has also been answered. It won't be vanilla though, but anyway I'm using extended..
Cheers
On Wed, Nov 14, 2012 at 12:54 PM, Cyrille Henry ch@chnry.net wrote:
Le 14/11/2012 11:30, Alexandros Drymonitis a écrit :
I tried your patch and the problem you mention does occur. I've no idea why and how to solve this, but I'm also getting some strange behavior with live patching. In my case [loadbang] won't work...
when sending message to pd to create objects, one also have to manually send the loadbang messages. reasons are details in the archive. [loadbang bang< | [s pd-foo]
cheers c
On Mon, Nov 12, 2012 at 5:29 PM, Ángel Faraldo <angelfaraldo@gmail.com mailto:angelfaraldo@gmail.com> wrote:
Hi List, I've been increasingly working with dynamic patching and there is an issue that don't understand in relation with creating multiple audio abstractions... Imagine I put an oscillator inside an abstraction and I recall one instance of it from the main patch (already computing audio). This is what happens: The abstraction will not produce sound until I: a) save the patch b) create another abstraction with the same name (another audio object will not work) c) I click on a already existing object in the main patch (clicking on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable) I attach an example: Any insights or ideas about how to solve this? with kind regards, Angel Faraldo _________________ www.angelfaraldo.info <http://www.angelfaraldo.info> _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info
You could try https://github.com/thisconnect/pddom It should take care about:
- updating DSP tree after adding removing an abstraction
- firing loadbang
- sets senders and receivers so you can send a signal from one
abstraction directly to the next one
On Wed, Nov 14, 2012 at 12:41 PM, Ángel Faraldo angelfaraldo@gmail.com wrote:
Thanks for your replies,
indeed I was reading on the list and there are various threads on this topic. Apologies for re-asking old threads.
In my current project, I wasn't planning to create the objects with messages (obj ... ... ..., i.e. dynamic patching) but manually adding objects which produce sound on the fly.
Therefore, [initbang] doesn't make a difference here, because loadbangs are actually initialized when loading an abstraction manually, and turning dsp audio off and on produces a longer-than-desirable silence gap when I create a new abstraction, so although advisable on regular situations, it doesn't seem to be the solution here.
So, although maybe not the most elegant, I've managed to solve it by sending the abstraction's [loadbang] to the main patch to dynamically save the latter. This way I get the sound of the abstraction immediately.
Cheers and thanks again.
ángel
On 14/11/2012, at 12:03, Alexandros Drymonitis wrote:
Or use [initbang]...after i go banana's reply I searched a bit and found out that my question has also been answered. It won't be vanilla though, but anyway I'm using extended..
Cheers
On Wed, Nov 14, 2012 at 12:54 PM, Cyrille Henry ch@chnry.net wrote:
Le 14/11/2012 11:30, Alexandros Drymonitis a écrit :
I tried your patch and the problem you mention does occur. I've no idea why and how to solve this, but I'm also getting some strange behavior with live patching. In my case [loadbang] won't work...
when sending message to pd to create objects, one also have to manually send the loadbang messages. reasons are details in the archive. [loadbang bang< | [s pd-foo]
cheers c
On Mon, Nov 12, 2012 at 5:29 PM, Ángel Faraldo <angelfaraldo@gmail.com mailto:angelfaraldo@gmail.com> wrote:
Hi List, I've been increasingly working with dynamic patching and there is anissue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall oneinstance of it from the main patch (already computing audio). This is what happens:
The abstraction will not produce sound until I: a) save the patch b) create another abstraction with the same name (another audioobject will not work) c) I click on a already existing object in the main patch (clicking on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable)
I attach an example: Any insights or ideas about how to solve this? with kind regards, Angel Faraldo _________________ www.angelfaraldo.info <http://www.angelfaraldo.info> _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey, that looks very interesting! Thanks Enrique
On 14/11/2012, at 16:14, Enrique Erne wrote:
You could try https://github.com/thisconnect/pddom It should take care about:
- updating DSP tree after adding removing an abstraction
- firing loadbang
- sets senders and receivers so you can send a signal from one
abstraction directly to the next one
On Wed, Nov 14, 2012 at 12:41 PM, Ángel Faraldo angelfaraldo@gmail.com wrote:
Thanks for your replies,
indeed I was reading on the list and there are various threads on this topic. Apologies for re-asking old threads.
In my current project, I wasn't planning to create the objects with messages (obj ... ... ..., i.e. dynamic patching) but manually adding objects which produce sound on the fly.
Therefore, [initbang] doesn't make a difference here, because loadbangs are actually initialized when loading an abstraction manually, and turning dsp audio off and on produces a longer-than-desirable silence gap when I create a new abstraction, so although advisable on regular situations, it doesn't seem to be the solution here.
So, although maybe not the most elegant, I've managed to solve it by sending the abstraction's [loadbang] to the main patch to dynamically save the latter. This way I get the sound of the abstraction immediately.
Cheers and thanks again.
ángel
On 14/11/2012, at 12:03, Alexandros Drymonitis wrote:
Or use [initbang]...after i go banana's reply I searched a bit and found out that my question has also been answered. It won't be vanilla though, but anyway I'm using extended..
Cheers
On Wed, Nov 14, 2012 at 12:54 PM, Cyrille Henry ch@chnry.net wrote:
Le 14/11/2012 11:30, Alexandros Drymonitis a écrit :
I tried your patch and the problem you mention does occur. I've no idea why and how to solve this, but I'm also getting some strange behavior with live patching. In my case [loadbang] won't work...
when sending message to pd to create objects, one also have to manually send the loadbang messages. reasons are details in the archive. [loadbang bang< | [s pd-foo]
cheers c
On Mon, Nov 12, 2012 at 5:29 PM, Ángel Faraldo <angelfaraldo@gmail.com mailto:angelfaraldo@gmail.com> wrote:
Hi List,
I've been increasingly working with dynamic patching and there is an issue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall one instance of it from the main patch (already computing audio). This is what happens:
The abstraction will not produce sound until I:
a) save the patch b) create another abstraction with the same name (another audio object will not work) c) I click on a already existing object in the main patch (clicking on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable)
I attach an example:
Any insights or ideas about how to solve this?
with kind regards,
Angel Faraldo _________________ www.angelfaraldo.info http://www.angelfaraldo.info
Pd-list@iem.at mailto:Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info
Enrique, I've been checking your abstractions and they seem to be very good. I've one question though, how can you control the abstractions you add to nodes, say with a slider? Or do you have to create your nodes with abstractions with arguments (like the proposed method in the readme file) and that should be it?
Cheers
On Wed, Nov 14, 2012 at 5:14 PM, Enrique Erne enrique@netpd.org wrote:
You could try https://github.com/thisconnect/pddom It should take care about:
- updating DSP tree after adding removing an abstraction
- firing loadbang
- sets senders and receivers so you can send a signal from one
abstraction directly to the next one
On Wed, Nov 14, 2012 at 12:41 PM, Ángel Faraldo angelfaraldo@gmail.com wrote:
Thanks for your replies,
indeed I was reading on the list and there are various threads on this topic. Apologies for re-asking old threads.
In my current project, I wasn't planning to create the objects with
messages
(obj ... ... ..., i.e. dynamic patching) but manually adding objects
which
produce sound on the fly.
Therefore, [initbang] doesn't make a difference here, because loadbangs
are
actually initialized when loading an abstraction manually, and turning
dsp
audio off and on produces a longer-than-desirable silence gap when I
create
a new abstraction, so although advisable on regular situations, it
doesn't
seem to be the solution here.
So, although maybe not the most elegant, I've managed to solve it by
sending
the abstraction's [loadbang] to the main patch to dynamically save the latter. This way I get the sound of the abstraction immediately.
Cheers and thanks again.
ángel
On 14/11/2012, at 12:03, Alexandros Drymonitis wrote:
Or use [initbang]...after i go banana's reply I searched a bit and found
out
that my question has also been answered. It won't be vanilla though, but anyway I'm using extended..
Cheers
On Wed, Nov 14, 2012 at 12:54 PM, Cyrille Henry ch@chnry.net wrote:
Le 14/11/2012 11:30, Alexandros Drymonitis a écrit :
I tried your patch and the problem you mention does occur. I've no idea why and how to solve this, but I'm also getting some strange behavior
with
live patching. In my case [loadbang] won't work...
when sending message to pd to create objects, one also have to manually send the loadbang messages. reasons are details in the archive. [loadbang bang< | [s pd-foo]
cheers c
On Mon, Nov 12, 2012 at 5:29 PM, Ángel Faraldo <angelfaraldo@gmail.com mailto:angelfaraldo@gmail.com> wrote:
Hi List, I've been increasingly working with dynamic patching and there isan
issue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall oneinstance of it from the main patch (already computing audio). This is
what
happens:
The abstraction will not produce sound until I: a) save the patch b) create another abstraction with the same name (another audioobject will not work) c) I click on a already existing object in the main patch (clicking on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable)
I attach an example: Any insights or ideas about how to solve this? with kind regards, Angel Faraldo _________________ www.angelfaraldo.info <http://www.angelfaraldo.info> _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Nevermind, I'm checking the gui02-test.pd patch, I guess my answer is there.
On Thu, Nov 15, 2012 at 1:38 PM, Alexandros Drymonitis adrcki@gmail.comwrote:
Enrique, I've been checking your abstractions and they seem to be very good. I've one question though, how can you control the abstractions you add to nodes, say with a slider? Or do you have to create your nodes with abstractions with arguments (like the proposed method in the readme file) and that should be it?
Cheers
On Wed, Nov 14, 2012 at 5:14 PM, Enrique Erne enrique@netpd.org wrote:
You could try https://github.com/thisconnect/pddom It should take care about:
- updating DSP tree after adding removing an abstraction
- firing loadbang
- sets senders and receivers so you can send a signal from one
abstraction directly to the next one
On Wed, Nov 14, 2012 at 12:41 PM, Ángel Faraldo angelfaraldo@gmail.com wrote:
Thanks for your replies,
indeed I was reading on the list and there are various threads on this topic. Apologies for re-asking old threads.
In my current project, I wasn't planning to create the objects with
messages
(obj ... ... ..., i.e. dynamic patching) but manually adding objects
which
produce sound on the fly.
Therefore, [initbang] doesn't make a difference here, because loadbangs
are
actually initialized when loading an abstraction manually, and turning
dsp
audio off and on produces a longer-than-desirable silence gap when I
create
a new abstraction, so although advisable on regular situations, it
doesn't
seem to be the solution here.
So, although maybe not the most elegant, I've managed to solve it by
sending
the abstraction's [loadbang] to the main patch to dynamically save the latter. This way I get the sound of the abstraction immediately.
Cheers and thanks again.
ángel
On 14/11/2012, at 12:03, Alexandros Drymonitis wrote:
Or use [initbang]...after i go banana's reply I searched a bit and
found out
that my question has also been answered. It won't be vanilla though, but anyway I'm using extended..
Cheers
On Wed, Nov 14, 2012 at 12:54 PM, Cyrille Henry ch@chnry.net wrote:
Le 14/11/2012 11:30, Alexandros Drymonitis a écrit :
I tried your patch and the problem you mention does occur. I've no
idea
why and how to solve this, but I'm also getting some strange behavior
with
live patching. In my case [loadbang] won't work...
when sending message to pd to create objects, one also have to manually send the loadbang messages. reasons are details in the archive. [loadbang bang< | [s pd-foo]
cheers c
On Mon, Nov 12, 2012 at 5:29 PM, Ángel Faraldo <
angelfaraldo@gmail.com
mailto:angelfaraldo@gmail.com> wrote:
Hi List, I've been increasingly working with dynamic patching and there isan
issue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall oneinstance of it from the main patch (already computing audio). This is
what
happens:
The abstraction will not produce sound until I: a) save the patch b) create another abstraction with the same name (another audioobject will not work) c) I click on a already existing object in the main patch
(clicking
on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable)
I attach an example: Any insights or ideas about how to solve this? with kind regards, Angel Faraldo _________________ www.angelfaraldo.info <http://www.angelfaraldo.info> _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
how can you control the abstractions you add to nodes, say with a slider? Or do you have to create your nodes with abstractions with arguments (like the proposed method in the readme file) and that should be it?
(I forgot to hit reply to all)
It depends on your needs, but [pddom] does not help you building the interface. The examples/ui illustrates simple ways of controlling the dynamically created abstractions with 1 interface.
Another way is to use the abstractions own window, that you can open with [vis $1( where $1 is the position (number) of the instantiated abstraction. This is of corse if you don't mind having each interface in it's own window.
To locate and open exactly the one abstraction vis send a [; $1.$2.vis findparent( command to [namecanvas $1.$2.vis]. This is the only reason why there is a [namecanvas] inside [pddom.from] and [pddom.from~]. This also requires [pddom.from] and [pddom.from~] to be located in the main canvas of each abstraction and not hidden somewhere deeper.
How are you planing to use pddom? Do you open the same abstraction multiple times or do you wish to combine many different abstractions with their own user interface?
The only bad thing is the dsp having to go off and on again.
If you are on OS X turning off/on DSP takes a long time (or at least it used to take over 100ms a few years ago). On other operating systems it was never a problem iirc.
You could try and increase the Delay time under Audio Settings and test if that helps.
Alternatively there is another "trick" that works without turning off/on DSP, this is creating 1 ~ object and deleting it again. See also tests/basic/test-dsp-update~.pd It disables the internal off/on update mechanism by [dsp_ disable( and uses a subpatch for the DSP tree update workaround. See [pd dsp-tree-update-workaround], but all your messages that change the DSP tree need to go through that subpatch.
Enrique, I've been playing around with pddom and it works very nicely, I only have trouble making it stereo. I tried to follow the examples/multi/pd-dom4-help.pd changing it a bit to make it stereo, but it won't really work. Is it something to do with the right most outlet of [pddom.from~] that connects to the right most inlet of [pddom.to~] in the mono version? In you multichannel version there are only tilde outlets in [pddom4.from~] and the right most inlet of [pddom4.to~] receives nothing. I tried to modify it accordingly but with no luck. Could you help?
On Fri, Nov 16, 2012 at 10:43 AM, Enrique Erne enrique@netpd.org wrote:
how can you control the abstractions you add to nodes, say with a
slider? Or do you have to create your nodes with abstractions with arguments (like the proposed method in the readme file) and that should be it?
(I forgot to hit reply to all)
It depends on your needs, but [pddom] does not help you building the interface. The examples/ui illustrates simple ways of controlling the dynamically created abstractions with 1 interface.
Another way is to use the abstractions own window, that you can open with [vis $1( where $1 is the position (number) of the instantiated abstraction. This is of corse if you don't mind having each interface in it's own window.
To locate and open exactly the one abstraction vis send a [; $1.$2.vis findparent( command to [namecanvas $1.$2.vis]. This is the only reason why there is a [namecanvas] inside [pddom.from] and [pddom.from~]. This also requires [pddom.from] and [pddom.from~] to be located in the main canvas of each abstraction and not hidden somewhere deeper.
How are you planing to use pddom? Do you open the same abstraction multiple times or do you wish to combine many different abstractions with their own user interface?
The only bad thing is the dsp having to go off and on again.
If you are on OS X turning off/on DSP takes a long time (or at least it used to take over 100ms a few years ago). On other operating systems it was never a problem iirc.
You could try and increase the Delay time under Audio Settings and test if that helps.
Alternatively there is another "trick" that works without turning off/on DSP, this is creating 1 ~ object and deleting it again. See also tests/basic/test-dsp-update~.pd It disables the internal off/on update mechanism by [dsp_ disable( and uses a subpatch for the DSP tree update workaround. See [pd dsp-tree-update-workaround], but all your messages that change the DSP tree need to go through that subpatch.
Alexandros, Thanks for reporting, somehow it was registering as no-audio abstraction. This commit should fix it: https://github.com/thisconnect/pddom/commit/b901f9f66b95e7efb244e27901b4d4db...
Please try the newest verison @ https://github.com/thisconnect/pddom and let me know if that works for you. I suggest to:
- copy/paste the abstractions form examples/multichannel into your project
- rename the abstractions to pddom2.to~ / pddom2.from~
- remove the unused 2 outlets~ s~/r~ parts
Let me know if that works for you, I will have time tomorrow during the day to have a look at it.
On Wed, Nov 21, 2012 at 5:13 PM, Alexandros Drymonitis adrcki@gmail.com wrote:
Enrique, I've been playing around with pddom and it works very nicely, I only have trouble making it stereo. I tried to follow the examples/multi/pd-dom4-help.pd changing it a bit to make it stereo, but it won't really work. Is it something to do with the right most outlet of [pddom.from~] that connects to the right most inlet of [pddom.to~] in the mono version? In you multichannel version there are only tilde outlets in [pddom4.from~] and the right most inlet of [pddom4.to~] receives nothing. I tried to modify it accordingly but with no luck. Could you help?
On Fri, Nov 16, 2012 at 10:43 AM, Enrique Erne enrique@netpd.org wrote:
how can you control the abstractions you add to nodes, say with a slider? Or do you have to create your nodes with abstractions with arguments (like the proposed method in the readme file) and that should be it?
(I forgot to hit reply to all)
It depends on your needs, but [pddom] does not help you building the interface. The examples/ui illustrates simple ways of controlling the dynamically created abstractions with 1 interface.
Another way is to use the abstractions own window, that you can open with [vis $1( where $1 is the position (number) of the instantiated abstraction. This is of corse if you don't mind having each interface in it's own window.
To locate and open exactly the one abstraction vis send a [; $1.$2.vis findparent( command to [namecanvas $1.$2.vis]. This is the only reason why there is a [namecanvas] inside [pddom.from] and [pddom.from~]. This also requires [pddom.from] and [pddom.from~] to be located in the main canvas of each abstraction and not hidden somewhere deeper.
How are you planing to use pddom? Do you open the same abstraction multiple times or do you wish to combine many different abstractions with their own user interface?
The only bad thing is the dsp having to go off and on again.
If you are on OS X turning off/on DSP takes a long time (or at least it used to take over 100ms a few years ago). On other operating systems it was never a problem iirc.
You could try and increase the Delay time under Audio Settings and test if that helps.
Alternatively there is another "trick" that works without turning off/on DSP, this is creating 1 ~ object and deleting it again. See also tests/basic/test-dsp-update~.pd It disables the internal off/on update mechanism by [dsp_ disable( and uses a subpatch for the DSP tree update workaround. See [pd dsp-tree-update-workaround], but all your messages that change the DSP tree need to go through that subpatch.
Thanks for that. Using the two outputs of the four channel version works in stereo now just fine. When I try to delete two outputs and inputs from [pddom2.from~] and [pddom2.to~] respectively, it won't work anymore. Is what I say clear?... Anyway, I guess this way it's fine. Thanks again.
On Wed, Nov 21, 2012 at 8:52 PM, Enrique Erne enrique@netpd.org wrote:
Alexandros, Thanks for reporting, somehow it was registering as no-audio abstraction. This commit should fix it:
https://github.com/thisconnect/pddom/commit/b901f9f66b95e7efb244e27901b4d4db...
Please try the newest verison @ https://github.com/thisconnect/pddom and let me know if that works for you. I suggest to:
- copy/paste the abstractions form examples/multichannel into your project
- rename the abstractions to pddom2.to~ / pddom2.from~
- remove the unused 2 outlets~ s~/r~ parts
Let me know if that works for you, I will have time tomorrow during the day to have a look at it.
On Wed, Nov 21, 2012 at 5:13 PM, Alexandros Drymonitis adrcki@gmail.com wrote:
Enrique, I've been playing around with pddom and it works very nicely, I only have trouble making it stereo. I tried to follow the examples/multi/pd-dom4-help.pd changing it a bit to make it stereo, but
it
won't really work. Is it something to do with the right most outlet of [pddom.from~] that connects to the right most inlet of [pddom.to~] in
the
mono version? In you multichannel version there are only tilde outlets in [pddom4.from~] and the right most inlet of [pddom4.to~] receives
nothing. I
tried to modify it accordingly but with no luck. Could you help?
On Fri, Nov 16, 2012 at 10:43 AM, Enrique Erne enrique@netpd.org
wrote:
how can you control the abstractions you add to nodes, say with a slider? Or do you have to create your nodes with abstractions with
arguments
(like the proposed method in the readme file) and that should be it?
(I forgot to hit reply to all)
It depends on your needs, but [pddom] does not help you building the interface. The examples/ui illustrates simple ways of controlling the dynamically created abstractions with 1 interface.
Another way is to use the abstractions own window, that you can open with [vis $1( where $1 is the position (number) of the instantiated abstraction. This is of corse if you don't mind having each interface in it's own window.
To locate and open exactly the one abstraction vis send a [; $1.$2.vis findparent( command to [namecanvas $1.$2.vis]. This is the only reason why there is a [namecanvas] inside [pddom.from] and [pddom.from~]. This also requires [pddom.from] and [pddom.from~] to be located in the main canvas of each abstraction and not hidden somewhere deeper.
How are you planing to use pddom? Do you open the same abstraction multiple times or do you wish to combine many different abstractions with their own user interface?
The only bad thing is the dsp having to go off and on again.
If you are on OS X turning off/on DSP takes a long time (or at least it used to take over 100ms a few years ago). On other operating systems it was never a problem iirc.
You could try and increase the Delay time under Audio Settings and test if that helps.
Alternatively there is another "trick" that works without turning off/on DSP, this is creating 1 ~ object and deleting it again. See also tests/basic/test-dsp-update~.pd It disables the internal off/on update mechanism by [dsp_ disable( and uses a subpatch for the DSP tree update workaround. See [pd dsp-tree-update-workaround], but all your messages that change the DSP tree need to go through that subpatch.
Le 12/11/2012 16:29, Ángel Faraldo a écrit :
Hi List,
I've been increasingly working with dynamic patching and there is an issue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall one instance of it from the main patch (already computing audio). This is what happens:
The abstraction will not produce sound until I:
no sound is produce until a new DSP graph is created.
it is usually recommended to switch dsp off before dynamically patch audio object, and switch if on after. see ML archives for reasons.
Cheers Cyrille
a) save the patch b) create another abstraction with the same name (another audio object will not work) c) I click on a already existing object in the main patch (clicking on the canvas will not work either) d) I un-compute and re-compute audio (which is not desirable)
I attach an example:
Any insights or ideas about how to solve this?
with kind regards,
Angel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Cyrille Henry ch@chnry.net To: pd-list@iem.at Cc: Sent: Wednesday, November 14, 2012 5:49 AM Subject: Re: [PD] weird behavior with dynamically created abstractions (sound doesn't work)
Le 12/11/2012 16:29, Ángel Faraldo a écrit :
Hi List,
I've been increasingly working with dynamic patching and there is an
issue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall one instance
of it from the main patch (already computing audio). This is what happens:
The abstraction will not produce sound until I:
no sound is produce until a new DSP graph is created.
it is usually recommended to switch dsp off before dynamically patch audio object, and switch if on after. see ML archives for reasons.
If turning off dsp before dynamically patching an audio object is what the user is _supposed_ to do, then why is audio turned off for a dynamically created abstraction? Is there a potential crasher if the behavior were different that can be shown in a short example patch?
Also: Regarding loadbang being suppressed in a dynamically instantiated object-- would there be crashers caused by not suppressing it?
These issues come up time and time again because Pd's behavior is glaringly inconsistent-- a live coder typing <ctrl-1> and the word "foo" in the box gets different behavior than someone doing [obj 20 20 foo(--[sendcanvas]. Since I've _never_ read a message from a live coder who wants loadbangs to cease automatically firing inside abstractions, and I've rarely if ever seen an abstraction in svn that uses [loadbang] to send data to a hot inlet, it'd be nice to have a short example patch that shows how a crash could occur for automated dynamic patching, but not live coding, if loadbangs did fire in both cases.
This inconsistency is the reason the list continues getting these queries. When the behavior clashes so much with the user's own experience, time and time again we see they think it's a problem with _their_ patch, which is why they often don't search the list first for the same issue first. Without a clear counterexample of the edge case that would cause a crash, we can't expect users to understand why behavior they've encountered 1000 times in building patches must change when they automate that same process.
-Jonathan
On Wed, 2012-11-14 at 10:33 -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Cyrille Henry ch@chnry.net To: pd-list@iem.at Cc: Sent: Wednesday, November 14, 2012 5:49 AM Subject: Re: [PD] weird behavior with dynamically created abstractions (sound doesn't work)
Le 12/11/2012 16:29, Ángel Faraldo a écrit :
Hi List,
I've been increasingly working with dynamic patching and there is an
issue that don't understand in relation with creating multiple audio abstractions...
Imagine I put an oscillator inside an abstraction and I recall one instance
of it from the main patch (already computing audio). This is what happens:
The abstraction will not produce sound until I:
no sound is produce until a new DSP graph is created.
it is usually recommended to switch dsp off before dynamically patch audio object, and switch if on after. see ML archives for reasons.
If turning off dsp before dynamically patching an audio object is what the user is _supposed_ to do, then why is audio turned off for a dynamically created abstraction? Is there a potential crasher if the behavior were different that can be shown in a short example patch?
First, dynamic patching - though widely used - is _not_ a documented and officially supported feature. Consider it something that people found out how it works as a hack to do some stuff that wouldn't be possible otherwise. Nevertheless it's not a Pd feature as such and might be subject to change.
I don't know the actual answers to your questions, but I have some guesses. The difference between manual patching and dynamic patching is that for the former every user action is considered finished as soon as the user did something. For instance, whenever a tilde object is created, the graph is recompiled. However, dynamic patching emulates the process of loading a patch. On patch load, only when all objects are instantiated the process is finished and all loadbangs are fired in the order innermost first, the outermost last. Also the graph is then only compiled once, but not on every object creation. When doing dynamic patching however, Pd does not know automatically when process of dynamic patching has finished.
Actually, I consider it a good thing that loadbangs are not fired immediately on dynamic creation. This gives more control to the patch designer as they can let the loadbangs fire when the patch designer considers the dynamic part to be ready. Also it saves a lot of (cpu) time to only recompile the graph once instead of on every tilde object instantiation.
Roman
Also: Regarding loadbang being suppressed in a dynamically instantiated object-- would there be crashers caused by not suppressing it?
These issues come up time and time again because Pd's behavior is glaringly inconsistent-- a live coder typing <ctrl-1> and the word "foo" in the box gets different behavior than someone doing [obj 20 20 foo(--[sendcanvas]. Since I've _never_ read a message from a live coder who wants loadbangs to cease automatically firing inside abstractions, and I've rarely if ever seen an abstraction in svn that uses [loadbang] to send data to a hot inlet, it'd be nice to have a short example patch that shows how a crash could occur for automated dynamic patching, but not live coding, if loadbangs did fire in both cases.
This inconsistency is the reason the list continues getting these queries. When the behavior clashes so much with the user's own experience, time and time again we see they think it's a problem with _their_ patch, which is why they often don't search the list first for the same issue first. Without a clear counterexample of the edge case that would cause a crash, we can't expect users to understand why behavior they've encountered 1000 times in building patches must change when they automate that same process.
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, November 15, 2012 1:13 PM Subject: Re: [PD] weird behavior with dynamically created abstractions (sound doesn't work)
On Wed, 2012-11-14 at 10:33 -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Cyrille Henry ch@chnry.net To: pd-list@iem.at Cc: Sent: Wednesday, November 14, 2012 5:49 AM Subject: Re: [PD] weird behavior with dynamically created abstractions
(sound doesn't work)
Le 12/11/2012 16:29, Ángel Faraldo a écrit :
Hi List,
I've been increasingly working with dynamic patching and
there is an
issue that don't understand in relation with creating multiple
audio
abstractions...
Imagine I put an oscillator inside an abstraction and I recall
one instance
of it from the main patch (already computing audio). This is what
happens:
The abstraction will not produce sound until I:
no sound is produce until a new DSP graph is created.
it is usually recommended to switch dsp off before dynamically patch
audio
object, and switch if on after. see ML archives for reasons.
If turning off dsp before dynamically patching an audio object is what the
user
is _supposed_ to do, then why is audio turned off for a dynamically created abstraction? Is there a potential crasher if the behavior were different
that can
be shown in a short example patch?
First, dynamic patching - though widely used - is _not_ a documented and officially supported feature. Consider it something that people found out how it works as a hack to do some stuff that wouldn't be possible otherwise. Nevertheless it's not a Pd feature as such and might be subject to change.
I don't know the actual answers to your questions, but I have some guesses. The difference between manual patching and dynamic patching is that for the former every user action is considered finished as soon as the user did something. For instance, whenever a tilde object is created, the graph is recompiled. However, dynamic patching emulates the process of loading a patch. On patch load, only when all objects are instantiated the process is finished and all loadbangs are fired in the order innermost first, the outermost last. Also the graph is then only compiled once, but not on every object creation. When doing dynamic patching however, Pd does not know automatically when process of dynamic patching has finished.
That's not a reason to _suppress_ dsp with dynamic patching, because the process would work exactly the same regardless.
#1 Pd in its current state: user makes sure to suppress dsp, dynamically creates patch, then turns on dsp when finished #2 Pd with dynamic patching behavior being the same as the current manual patching behavior: user makes sure to suppress dsp, dynamically creates patch, then turns on dsp when finished
The only difference is that #1 introduces a frustrating inconsistency so that the user who is dynamically instantiating _one_ abstraction with a few tilde objects inside it gets confused and must ask on the list what they did wrong there, and I still haven't seen a clear example of how the behavior I describe would cause a bug or crash. (If it does happen to cause a bug or crash then I would agree the proper response is "this behavior avoids a crash and/or buggy behavior".)
Actually, I consider it a good thing that loadbangs are not fired immediately on dynamic creation. This gives more control to the patch designer as they can let the loadbangs fire when the patch designer considers the dynamic part to be ready.
Dynamically created: [abstraction1]---[abstraction2]
I've never seen an external in svn where [abstraction1] would rely on an internal [loadbang] in order to send a message to its outlet. That would obviously complicate realtime patching, too. Even if you're designing your abstractions for the specific purpose of dynamically patching, it's much more sensible to dynamically create the [loadbang] itself to show clearly what's going on:
[loadbang]--[abstraction1]--[abstraction2]
If the user doesn't know about the canvas "loadbang" method, they can also do this:
[$0-loadbang]--[abstraction1]--[abstraction2]
-Jonathan
Also it saves a lot of (cpu) time to only recompile the graph once instead of on every tilde object instantiation.
Roman
Also: Regarding loadbang being suppressed in a dynamically instantiated object-- would there be crashers caused by not suppressing it?
These issues come up time and time again because Pd's behavior is glaringly inconsistent-- a live coder typing <ctrl-1> and the word
"foo" in the
box gets different behavior than someone doing [obj 20 20
foo(--[sendcanvas].
Since I've _never_ read a message from a live coder who wants loadbangs to cease automatically firing inside abstractions, and I've rarely if
ever seen
an abstraction in svn that uses [loadbang] to send data to a hot inlet,
it'd be
nice to have a short example patch that shows how a crash could occur for automated dynamic patching, but not live coding, if loadbangs did fire
in both
cases.
This inconsistency is the reason the list continues getting these queries.
When the
behavior clashes so much with the user's own experience, time and time again we see they think it's a problem with _their_ patch, which is why
they often
don't search the list first for the same issue first. Without a clear
counterexample of the
edge case that would cause a crash, we can't expect users to understand why behavior they've encountered 1000 times in building patches must
change when
they automate that same process.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 11/19/2012 09:07 PM, Jonathan Wilkes wrote:
----- Original Message -----
That's not a reason to _suppress_ dsp with dynamic patching, because the process would work exactly the same regardless.
i think this is simply a bug in Pd.
i do some live-coding using dynamic patching, and found that saving the patch would re-compute the dsp-graph (i'm using abstractions, so saving will eventually re-instantiate a number of abstractions, which triggers a reavaulation of the dsp-graph; so i found that in practice this bug is not such a big problem for _me_)
I've never seen an external in svn where [abstraction1] would rely on an internal [loadbang] in order to send a message to its outlet.
well, very few *externals* (as in "atomic" (non-openable) objects written mostly in C) do anything with loadbangs.
anyhow, even if we are talking only about abstractions, i think your assumption, that just because [loadbang] is not used in the described way anywhere in the Pd-svn, this behaviour could simply be changed is not a valid one.
i'd very much like to see [initbang] and [closebang] in Pd-proper though.
fgmsdr IOhannes
On 11/19/2012 11:18 PM, IOhannes m zmölnig wrote:
I've never seen an external in svn where [abstraction1] would rely on an internal [loadbang] in order to send a message to its outlet.
well, very few *externals* (as in "atomic" (non-openable) objects written mostly in C) do anything with loadbangs.
and those that do, usually do create output on [loadbang]. e.g. iemguis (both externals and internals), or iemlib's [init] (i know iem-stuff better than other externals, hence the bias in the enumeration).
so those will definitely break your patches.
fgmdasr IOhannes
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Monday, November 19, 2012 5:35 PM Subject: Re: [PD] weird behavior with dynamically created abstractions (sound doesn't work)
On 11/19/2012 11:18 PM, IOhannes m zmölnig wrote:
I've never seen an external in svn where [abstraction1] would rely
on an
internal [loadbang] in order to send a message to its outlet.
well, very few *externals* (as in "atomic" (non-openable) objects written mostly in C) do anything with loadbangs.
and those that do, usually do create output on [loadbang]. e.g. iemguis (both externals and internals), or iemlib's [init] (i know iem-stuff better than other externals, hence the bias in the enumeration).
so those will definitely break your patches.
_If_ you dynamically instantiate them with all their arguments and with the init flag on. That's quite an edge case.
-Jonathan
fgmdasr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Monday, November 19, 2012 5:18 PM Subject: Re: [PD] weird behavior with dynamically created abstractions (sound doesn't work)
On 11/19/2012 09:07 PM, Jonathan Wilkes wrote:
----- Original Message -----
That's not a reason to _suppress_ dsp with dynamic patching, because the process would work exactly the same regardless.
i think this is simply a bug in Pd.
Then let's describe it as a bug when newcomers run into these predictable problems from the buggy behavior, and not as a feature that helps the user handle dsp toggling the "right" way when doing dynamic patching.
i do some live-coding using dynamic patching, and found that saving the patch would re-compute the dsp-graph (i'm using abstractions, so saving will eventually re-instantiate a number of abstractions, which triggers a reavaulation of the dsp-graph; so i found that in practice this bug is not such a big problem for _me_)
I've never seen an external in svn where [abstraction1] would rely on
an
internal [loadbang] in order to send a message to its outlet.
well, very few *externals* (as in "atomic" (non-openable) objects written mostly in C) do anything with loadbangs.
anyhow, even if we are talking only about abstractions, i think your assumption, that just because [loadbang] is not used in the described way anywhere in the Pd-svn, this behaviour could simply be changed is not a valid one.
That's not my assumption. I'm not petitioning for changing Pd's dynamic patching system-- I don't know the details about how it works internally. But virtually no one uses [loadbangs] in the way described in the hypothetical examples used to rationalize why it's desirable for the dynamic patching system to work the way it does. That should be a good indicator that this imaginary library of abstractions which exists only in list responses about dynamic patching should be removed and replaced with a simple statement that "this inconsistent behavior is entrenched in Pd and cannot simply be changed." (If that is indeed the case.)
-Jonathan
i'd very much like to see [initbang] and [closebang] in Pd-proper though.
fgmsdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandros Drymonitis -
Cyrille Henry -
Enrique Erne -
i go bananas -
IOhannes m zmölnig -
Jonathan Wilkes -
Roman Haefeli -
Ángel Faraldo