Hi,
Attached is a simple abstraction that contains an osc, a dac, a loadbang that triggers a random that sets the osc's freq, and a print that shows the frequency at loadbang.
Now, do the following experiment:
On a new patch, create an instance of [oscabs].
Surprise! It doesn't sound! However it does print the frequency, so the loadbang was triggered.
Now, create another instance of [oscabs] in the main patch. Surprise! The old one starts playing, and the new one is silent.
You could go on like this: when you add the N-th instance, the N-1-th starts playing.
Now suppose you have created 2 instances and only the first one is playing. Delete the first one: Surprise! The second one starts playing.
Indeed, if you have N instances and the N-th is not playing, you can delete any of the first N-1, and the N-th will start playing.
Now delete all and start from scratch.
You create one [oscabs], it doesn't play. Now select it and do CTRL+D (duplicate) to create a new one. Surprise! Both start playing at the same time, the old and the new one.
If I save the main patch, close and reopen it, all instances are playing, as expected.
Can anyone explain this crazy behaviour?
Testing with 0.40.1 on Windows XP.
hard off wrote:
what's [oscabs] ???
the abtraction in the missing attachment (containing an [osc~])
Oh sorry, here it is.
I had attached it, but then changed it and did something wrong when reattaching it in google webmail (i guess I removed the attached file and just forgot to reattach it).
matteo sisti sette wrote:
Testing with 0.40.1 on Windows XP.
hi. i remember the same (or very similar) behaviour a few years ago (on linux). my base patch was very similar (random oscillators, but also controlled oscillators) so it did not bother me too much (as i had several 100 to 1000 of them; 1 missing would not make a big difference) i have not investigated why it is like this. probably time to do it.
mfga.sdr IOhannes
I noticed something similar on 0.40 (pure:dyne)
Something to do with DACs. I had a patch where the [dac~] I was adding or deleteing didn't have any correspondence to the signal it was (supposed to be) outputting.
Drives me insane, so I avoid that version now.
And it's intermittent/random/sensitive to initial conditions. Sometimes a patch gets the problem, sometimes not.
On Thu, 31 Jan 2008 16:30:09 +0100 "matteo sisti sette" matteosistisette@gmail.com wrote:
Hi,
Attached is a simple abstraction that contains an osc, a dac, a loadbang that triggers a random that sets the osc's freq, and a print that shows the frequency at loadbang.
Now, do the following experiment:
On a new patch, create an instance of [oscabs].
Surprise! It doesn't sound! However it does print the frequency, so the loadbang was triggered.
Now, create another instance of [oscabs] in the main patch. Surprise! The old one starts playing, and the new one is silent.
You could go on like this: when you add the N-th instance, the N-1-th starts playing.
Now suppose you have created 2 instances and only the first one is playing. Delete the first one: Surprise! The second one starts playing.
Indeed, if you have N instances and the N-th is not playing, you can delete any of the first N-1, and the N-th will start playing.
Now delete all and start from scratch.
You create one [oscabs], it doesn't play. Now select it and do CTRL+D (duplicate) to create a new one. Surprise! Both start playing at the same time, the old and the new one.
If I save the main patch, close and reopen it, all instances are playing, as expected.
Can anyone explain this crazy behaviour?
Testing with 0.40.1 on Windows XP.
-- 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
Andy Farnell wrote:
I noticed something similar on 0.40 (pure:dyne)
Something to do with DACs. I had a patch where the [dac~] I was adding or deleteing didn't have any correspondence to the signal it was (supposed to be) outputting.
i don't think it is related to [dac~].
take attached abstraction and put it into your searchpath.
create a new patch and turn audio on.
add an instance of [randosc~ a]: a value is printed to the console. add another instance of [randosc~ b]: the [env~] in [randosc~ a] starts to work and prints to the console; the [env~] in [randosc~ b] does not work.
or another example (empty your patch): add an instance of [randosc~ a]: a value is printed to the console. add a [dac~]; the [env~] is still not working connect the [randosc~ a] to [dac~]: you will hear a sine and the [env~] within [randosc~ a] gets evaluated and printed to the console.
so: when adding a new abstraction (that is not connected yet to any other object in the patch!), the dsp-tree gets re-evaluated _but_ the newly added object is not part of it! forcing the dsp-tree to re-evaluate (e.g. by turning audio off&on; or adding another object; or connecting to ~-objects) adds the abstraction to the dsp-tree and it starts working...
fmgasdr. IOhannes
#N canvas 0 0 450 377 10; #X obj 188 184 osc~; #X obj 177 42 loadbang; #X obj 186 61 random 500; #X obj 191 225 *~ 0.1; #X obj 186 154 t f f; #X obj 235 153 print randosc; #X obj 187 110 + 100; #X obj 317 249 env~; #X obj 327 304 print $1-env; #X obj 112 298 outlet~; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 6 0; #X connect 3 0 7 0; #X connect 3 0 9 0; #X connect 4 0 0 0; #X connect 4 1 5 0; #X connect 6 0 4 0; #X connect 7 0 8 0;
do you see something unusual in this patch?
i have never noticed anything like that .. i only might have had something similar when i didn't know what hot and cold inlets are .. :)
errordeveloper@gmail.com wrote:
do you see something unusual in this patch?
i don't even see the patch!
i have never noticed anything like that ..
feel free to write your own (known to be good) version of [testosc~] and run the procedure as described in my email.
fgamdr IOhannes
-
Andy Farnell -
errordeveloper＠gmail.com -
hard off -
IOhannes m zmoelnig -
Matteo Sisti Sette -
matteo sisti sette