when dynamically creating signal-processing objects or abstractions, the dsp graph is not automatically recompiled
[...]
I can't recall if it is considered a feature or a bug, but probably it doesn't matter, since dynamic object creation is not officially supported.
[...]
Actually, when creating a tilde object or an abstraction, that processes signals, dynamically it's not taken into account for the currently used dsp graph. However, when you create the second instance (or any other tilde object), the first one is taken into account, but not the second.
This is _not_ only with dynamically created objects. It also happens with manually-created instances of abstractions containing dsp objects.
See the attached patch: open "test.pd", it contains a [catch~ audio] connected to the dac. Then create in it an instance of [myabs~ 500]: it contains an osc connected to a [throw~ audio], and $1 is used as the frequency.
You will hear nothing.
Then create a [myabs~ 700]: now you'll start to hear the previously created one, but not the second. And so on.
So the bug also affects "officially supported" patching and it does matter, though only for "live patching" (everything works fine when you load a saved patch). When you know it it's not a major issue (or an issue at all), but until you realise it, it can be quite confusing when editing the patch and try to figure out what's going on...
First of all, thank you for the support. This patch already gave me some headaches, but with this problem I just couldn't figure out what was going on. For what I understood, the problem is in Pd itself (I didn't understand if that is a pd bug or not though). But, Matteo, if the patch don't create objects dynamically It will always be limited by the number of allocable objects, isn't it? The other solution could work, and I'll probably do something like that since right now is much more important for me to get my piece done, although I can't help having a sensation of cheating (but this is of course just my compulsive neurosis).
But why again dynamic object creation is not officially supported? It works fine in pd vanilla, wich was the one I used to build this patch, but it does have some problems. Isn't it usefull?
Anyway, what you guys said was very very helpfull. And about the inconvenience, I was woried that I could not explain my problem in the subject and did not know how to search in the archive about this. So someone would have to look at my patch to understand what I was saying wich I find a little boring. Like all newbies, I was just worried of making a stupid question.
Bye Caio Barros
2010/2/26 Matteo Sisti Sette matteosistisette@gmail.com
when dynamically creating signal-processing objects or abstractions, the dsp graph is not automatically recompiled
[...]
I can't recall if it is considered a feature or a bug, but probably it doesn't matter, since dynamic object creation is not officially supported.
[...]
Actually, when creating a tilde object or an abstraction, that processes signals, dynamically it's not taken into account for the currently used dsp graph. However, when you create the second instance (or any other tilde object), the first one is taken into account, but not the second.
This is _not_ only with dynamically created objects. It also happens with manually-created instances of abstractions containing dsp objects.
See the attached patch: open "test.pd", it contains a [catch~ audio] connected to the dac. Then create in it an instance of [myabs~ 500]: it contains an osc connected to a [throw~ audio], and $1 is used as the frequency.
You will hear nothing.
Then create a [myabs~ 700]: now you'll start to hear the previously created one, but not the second. And so on.
So the bug also affects "officially supported" patching and it does matter, though only for "live patching" (everything works fine when you load a saved patch). When you know it it's not a major issue (or an issue at all), but until you realise it, it can be quite confusing when editing the patch and try to figure out what's going on...
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Caio Barros escribió:
But, Matteo, if the patch don't create objects dynamically It will always be limited by the number of allocable objects, isn't it?
Yes of course. However, infinite does not exist in real life. There must be a number that you can assume your number of objects never exceeds. In any case, your number of (even dynamically created) objects will always be limited to the number of objects that don't eat up your CPU and memory. So you can have as many statically created objects as that: if they are only switch~ed on when used, they won't consume CPU.
However I understand this would be a radical change in architecture for your patch and if you get the dynamical solution working there's no reason to change that.
But why again dynamic object creation is not officially supported? It works fine in pd vanilla, wich was the one I used to build this patch, but it does have some problems. Isn't it usefull?
I think it is because A) it does not offer an enough elegant, clean, and complete interface (by interface I mean the kind of messages you use to do it) B) it allows you to do things that will hang (or maybe even crash?) Pd
It is a "low level" implementation feature (the creation of objects by hand and the construction of patches when loaded are both implemented in terms of messages that dynamically create objects) that is left "exposed" to the user without (by now) all the needed safety mechanisms (which would be very hard to implement and probably even to devise).
I don't think it's not considered useful: if it weren't, it would have been "inhibited" (or not "exposed"). (sorry for the algebraic negations)
Anybody please correct me where I'm wrong.
Selon Matteo Sisti Sette matteosistisette@gmail.com:
Caio Barros escribió:
But why again dynamic object creation is not officially supported?
I think it is because
...
<snip> ... > B) it allows you to do things that will hang (or maybe even crash?) Pd
Anybody please correct me where I'm wrong.
I don't think you're wrong on this but, what about [until] object that can just crash/hung the COMPUTER and not only pd?
colet.patrice@free.fr wrote:
Selon Matteo Sisti Sette matteosistisette@gmail.com:
Caio Barros escribió:
But why again dynamic object creation is not officially supported?
I think it is because
...
<snip> ... > B) it allows you to do things that will hang (or maybe even crash?) Pd
Anybody please correct me where I'm wrong.
I don't think you're wrong on this but, what about [until] object that can just crash/hung the COMPUTER and not only pd?
If you can crash or hang your computer with an [until], that is not a PD bug as much as an operating system bug, I would report that to your OS vendor.
colet.patrice@free.fr escribió:
I don't think you're wrong on this but, what about [until] object that can just crash/hung the COMPUTER and not only pd?
Yeah, that's an issue that should be addressed.
bang an [until] object, but maybe it's because I'm on a dual core machine), it is the operating system's fault. No matter how bad a program hangs (even in the case of a malicious program), the operating system must guarantee that the whole system keeps working and that you have at least the ability to kill the hung/offending program 2) When you trigger an infinite loop, Pd shouldn't hung: it should warn you that a possibly infinite message tree is hanging the execution of the patch, and it should allow you to interrupt it, at the very least to save unsaved patches and exit. Or it could not warn you at all but some "kill" button should then always be available on the console window (for example).
As I see it, Pd is a virtual machine and the patch is the program that runs on that virtual machine. So if your patch is buggy (i.e. triggers an infinite loop), the virtual machine can hang, that's ok, it's the patcher's fault, but the virtual machine is virtual and should only "virtually" hang. Pd, which simulates the virtual machine, is also an application, and the patch is its input: and no matter the input, the application as such shouldn't hang.
Flash Player for example does that: if your script gets trapped in an infinite while, the player (the virtual machine) prompts the user to decide whether to interrupt the execution (it can't know whether the loop is infinite or just very long, and so can't pd know - but it detects a possible hanging and prompts the user whether she wants to interrupt it or keep waiting, in which case the prompt pops up again later). It seems to me that this often fails to work properly in Flash Player however.
Btw I thought I had heard of a "watchdog" process of Pd (there would be three processes: gui, engine and watchdog) whose function would be to avoid Pd hanging your computer......
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
As I see it, Pd is a virtual machine and the patch is the program that runs on that virtual machine. So if your patch is buggy (i.e. triggers an infinite loop), the virtual machine can hang, that's ok, it's the patcher's fault, but the virtual machine is virtual and should only "virtually" hang. Pd, which simulates the virtual machine, is also an application, and the patch is its input: and no matter the input, the application as such shouldn't hang.
so how do you determine whether the loop is an infinite one? and who will pay the numerous custodians in the galleries needed to click on "yes, i really want this loop?".
that's not to say, that it would be nice to be able to halt the virtual machine without quitting Pd. it would also be nice to have a step-debug mode...
fadr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
colet.patrice@free.fr wrote:
Selon Matteo Sisti Sette matteosistisette@gmail.com:
Caio Barros escribió:
But why again dynamic object creation is not officially supported?
I think it is because
...
<snip> ... > B) it allows you to do things that will hang (or maybe even crash?) Pd
i don't know either but i guess it's something like
C) making it "official" would effectively prohibit changes to the internally used protocol for creating patches (not that this is likely, giving the history of backward-compatibility in Pd). it's similar with all those private headers, used by numerous externals...
Anybody please correct me where I'm wrong.
I don't think you're wrong on this but, what about [until] object that can just crash/hung the COMPUTER and not only pd?
if this crashes your COMPUTER, than you have tweaked your OS-settings in a way that allows an ordinary user-space application to take all the ressources available. read: you asked for being able to fry your computer. normally an open [until] will only hang Pd.
an ordinary [osc~ 1000]->[dac~] can fry your ears without being a "bug".
fgmasdr IOhannes
--- On Sat, 2/27/10, IOhannes m zmölnig zmoelnig@iem.at wrote:
From: IOhannes m zmölnig zmoelnig@iem.at Subject: Re: [PD] Strange bug in my patch To: pd-list@iem.at Date: Saturday, February 27, 2010, 9:34 PM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
colet.patrice@free.fr wrote:
Selon Matteo Sisti Sette matteosistisette@gmail.com:
Caio Barros escribió:
But why again dynamic object creation is not
officially supported?
I think it is because
...
<snip> ... > B) it allows you to do things that will hang (or
maybe even crash?) Pd
i don't know either but i guess it's something like
C) making it "official" would effectively prohibit changes to the internally used protocol for creating patches (not that this is likely, giving the history of backward-compatibility in Pd). it's similar with all those private headers, used by numerous externals...
Anybody please correct me where I'm wrong.
I don't think you're wrong on this but, what about
[until] object that can just
crash/hung the COMPUTER and not only pd?
if this crashes your COMPUTER, than you have tweaked your OS-settings in a way that allows an ordinary user-space application to take all the ressources available. read: you asked for being able to fry your computer. normally an open [until] will only hang Pd.
On winxp it will consistently freeze the computer, forcing a reboot.
-Jonathan