I have problems creating signal patches by message. I attached a patch with problematic behavior.
First i put DSP on. Then open the bug-patch.pd and click on the message box and open the newly created bug-patch, now there is no output from noise~ . If you now force a recomputation of the computation graph there it an output.
I consider this as a bug but it migth be a "feature".
How could I fix this problem?
Best regards --PLu
Peter Lunden The Interactive Institute Box 24 081 SE-104 50 STOCKHOLM, Sweden Phone: +46-8-783 24 59 Cell: +46-70-845 53 03 ICQ: 253544648
#N canvas 548 166 460 310 10; #X msg 163 56 ; pd-bug-patch.pd obj 10 10 bug-patch; #X obj 46 163 noise~; #X obj 47 185 env~; #X floatatom 47 207 5 0 0 0 - - -; #X connect 1 0 2 0; #X connect 2 0 3 0;
Hallo, Peter Lundén hat gesagt: // Peter Lundén wrote:
I have problems creating signal patches by message. I attached a patch with problematic behavior.
First i put DSP on. Then open the bug-patch.pd and click on the message box and open the newly created bug-patch, now there is no output from noise~ . If you now force a recomputation of the computation graph there it an output.
I consider this as a bug but it migth be a "feature".
One problem is of course, that you are creating a recursive and endless loop here. You use bug-patch.pd inside bug-patch.pd, which is a bad idea anyways.
ciao
Frank Barknecht _ ______footils.org__
hoi zäme
although the [env~] says zero, i think there is sound there.
another test: create the bug-patch.pd by message. the [env~] of the abstraction sends value 0. create a [dac~] and then connect [noise~] with [dac~] at the moment when connection is done [env~] begins to show the correct values.
if save bug-patch.pd with the [dac~], and you create then the abstraction, you can delete the [dac~] in the parent window and you'll still here the noise.
but it's a very interesting problem, you discovered here. thank you for bringing me the idea how to create an object by message. I didn't know you could do this with pd.
Roman
----- Original Message ----- From: "Peter Lundén" plu@tii.se To: pd-list@iem.at Sent: Tuesday, March 09, 2004 9:45 AM Subject: [PD] Creating signal patches by messages
I have problems creating signal patches by message. I attached a patch with problematic behavior.
First i put DSP on. Then open the bug-patch.pd and click on the message box and open the newly created bug-patch, now there is no output from noise~ . If you now force a recomputation of the computation graph there it an output.
I consider this as a bug but it migth be a "feature".
How could I fix this problem?
Best regards --PLu
Peter Lunden The Interactive Institute Box 24 081 SE-104 50 STOCKHOLM, Sweden Phone: +46-8-783 24 59 Cell: +46-70-845 53 03 ICQ: 253544648
#N canvas 548 166 460 310 10; #X msg 163 56 ; pd-bug-patch.pd obj 10 10 bug-patch; #X obj 46 163 noise~; #X obj 47 185 env~; #X floatatom 47 207 5 0 0 0 - - -; #X connect 1 0 2 0; #X connect 2 0 3 0;
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
although the [env~] says zero, i think there is sound there.
No, it isn't. :(
I went the manual route using an abstraction whose content is:
[osc~ 440] | [*~ 0.5] | [dac]
Starting Pd, switching on audio, creating a new empty patch and an instance of above abstraction inside does not create sound. (using MSP-certified Pd 0.37-1)
Switching audio off and on again fixes this.
ciao
Frank Barknecht _ ______footils.org__
Sorry
that was not true what i wrote.
try the same test i described with an [osc~] (not too high f, so you will better hear a posssible distortion). when you create the abstraction, sound is still ok, which means you hear only one [osc~]. change the position of any object (or do another action in edit-mode) and you will hear distortion, beacause there are now 2 [osc~] you hear (chance is 50:50 that the phases of the 2 sinuswaves result in an amplification, so try it a few times.)
it seems that computation of audio is only updated by any "manual" action in edit mode. i think every time you do something the pd-patch is "rewritten" in the background, but not if changes are made by a message.
Roman
----- Original Message ----- From: "Peter Lundén" plu@tii.se To: pd-list@iem.at Sent: Tuesday, March 09, 2004 9:45 AM Subject: [PD] Creating signal patches by messages
I have problems creating signal patches by message. I attached a patch with problematic behavior.
First i put DSP on. Then open the bug-patch.pd and click on the message box and open the newly created bug-patch, now there is no output from noise~ . If you now force a recomputation of the computation graph there it an output.
I consider this as a bug but it migth be a "feature".
How could I fix this problem?
Best regards --PLu
Peter Lunden The Interactive Institute Box 24 081 SE-104 50 STOCKHOLM, Sweden Phone: +46-8-783 24 59 Cell: +46-70-845 53 03 ICQ: 253544648
#N canvas 548 166 460 310 10; #X msg 163 56 ; pd-bug-patch.pd obj 10 10 bug-patch; #X obj 46 163 noise~; #X obj 47 185 env~; #X floatatom 47 207 5 0 0 0 - - -; #X connect 1 0 2 0; #X connect 2 0 3 0;
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
it seems that computation of audio is only updated by any "manual" action in edit mode. i think every time you do something the pd-patch is "rewritten" in the background, but not if changes are made by a message.
Some more tests here revealed, that it has to do something with the dsp chain, which seems to not be update when DSP is on, but an abstraction with dsp code inside is instatiated.
In the example I posted earlier, you can do edits as long as you do not affect the dsp chain. So you can create a number box or so, but you cannot do things like moving the osc~ object without turning on audio finally.
ciao
Frank Barknecht _ ______footils.org__
I suppose the computation graph for the DSP is not updated correctly when creating a new box which contains DSP, but when you load (open) a DSP patch into a running application is done correctly. So there is no reson that it needs to behave like this, its a very anoying problem as Im depending on dynamic creation in a running application. I can not simply fix the problem by turning DSP off and on again to get the computation graph right.
--PLu
Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
it seems that computation of audio is only updated by any "manual" action in edit mode. i think every time you do something the pd-patch is "rewritten" in the background, but not if changes are made by a message.
Some more tests here revealed, that it has to do something with the dsp chain, which seems to not be update when DSP is on, but an abstraction with dsp code inside is instatiated.
In the example I posted earlier, you can do edits as long as you do not affect the dsp chain. So you can create a number box or so, but you cannot do things like moving the osc~ object without turning on audio finally.
ciao
Ongoing sounds from other part of application will be interrupted.
--PLu
IOhannes m zmoelnig wrote:
Peter Lundén wrote:
I can not simply fix the problem by turning DSP off and on again to get the computation graph right.
but why not ?
mfg.as.dr IOhannes
Peter Lundén wrote:
Ongoing sounds from other part of application will be interrupted.
ah indeed. i had thought that with restarting tha audio-engine with a message like [; pd dsp 0; pd dsp 1(, there would be no drop out. but i was wrong...
and even turning the dsp on again (without prior turning of) does not help.
but the patches created prior to the last one will start sounding. so if you could afford creating a dummy after each realy "bug"-object, you will get what you want (though it is not very elegant)
mfg.adsr IOhannes
Here's an idea... send a "paste" to any subpatch (perhaps making sure there's nothing in the "paste" buffer by sending "copy" first). This forces a DSP resort without restarting the audio driver.
cheers Miller
On Wed, Mar 10, 2004 at 05:51:27PM +0100, Peter Lundn wrote:
Ongoing sounds from other part of application will be interrupted.
--PLu
IOhannes m zmoelnig wrote:
Peter Lundén wrote:
I can not simply fix the problem by turning DSP off and on again to get the computation graph right.
but why not ?
mfg.as.dr IOhannes
--
--PLu
Peter Lunden The Interactive Institute Box 24 081 SE-104 50 STOCKHOLM, Sweden Phone: +46-8-783 24 59 Cell: +46-70-845 53 03 ICQ: 253544648
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Thanks Miller, it works fine.
--PLu
Miller Puckette wrote:
Here's an idea... send a "paste" to any subpatch (perhaps making sure there's nothing in the "paste" buffer by sending "copy" first). This forces a DSP resort without restarting the audio driver.
cheers Miller
On Wed, Mar 10, 2004 at 05:51:27PM +0100, Peter Lundn wrote:
Ongoing sounds from other part of application will be interrupted.
--PLu
IOhannes m zmoelnig wrote:
Peter Lundén wrote:
I can not simply fix the problem by turning DSP off and on again to get the computation graph right.
but why not ?
mfg.as.dr IOhannes
--
--PLu
Peter Lunden The Interactive Institute Box 24 081 SE-104 50 STOCKHOLM, Sweden Phone: +46-8-783 24 59 Cell: +46-70-845 53 03 ICQ: 253544648
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
hi Miller,
perhaps, there could be a 'resetdsp' message to pd, or the message 'dsp' taking an optional second argument: ``do not touch audio hardware'' flag ?
Btw, am I right, that all well-behaving tilde-externals should be transparent to the dsp graph resorting, i.e. they are expected not to reset their state. For example a filter should not clear its memory, etc?
I think, no tilde-internal in Pd resets state in its dsp routine, unless the sr or the block size changes. That is really great. It is a different story in max (which is easy to check with the tapin/tapout pair).
Krzysztof
Miller Puckette wrote:
Here's an idea... send a "paste" to any subpatch (perhaps making sure there's nothing in the "paste" buffer by sending "copy" first). This forces a DSP resort without restarting the audio driver.
-
Frank Barknecht -
IOhannes m zmoelnig -
Krzysztof Czaja -
Miller Puckette -
Peter Lundén -
Roman Haefeli