I was experimenting with pd, when I came upon the following:

( In advance I want to say it is much easier to understand making use the .pd attached )

Using [metro] and [tabwrite~] I graph all the audio output.
I'm making a sound with an [osc] and [pow~] and connect it to the [tabwrite~] as well as the [dac~], thus he [tabwrite~] and the [dac~] get the same signal.
The strange thing is: I can hear the sound but the graph displays nothing!
And even peculiar, when i add the signal coming from [pow~] to an [osc~] ,doing nothing but sitting around and being connected ( no frq specified ), I CAN see it in the graph.

Is this a bug?
Or do I just don't know what I'm doing.

Thanks for your help.

http://www.pdpatchrepo.info/hurleur/wat_is_deze.pd

what do you want pd to do?

Strange, it seems to work over here (audio and graph). Maybe you could resize the graph a bit because tcl/tk (the library used to give pd its visual aspect) sometimes lags behind... But that's really a very wild guess...

@sunji said:

what do you want pd to do?

I want pd to graph al the output.

@domien said:

Strange, it seems to work over here (audio and graph). Maybe you could resize the graph a bit because tcl/tk (the library used to give pd its visual aspect) sometimes lags behind... But that's really a very wild guess...

Even if you disconnect the osc which is doing nothing?

When i disconnect it there's no graphing. But then the [pow~] needs something feeding its right inlet, then it works.

@domien said:

When i disconnect it there's no graphing. But then the [pow~] needs something feeding its right inlet, then it works.

But then, how do you explain there IS sound and no graphing!

what's your soundcard's sampling rate? tabwrite~ will only display the graph once all the data has been read into the graph.

your graph is 6000 samples long, and your metro is 200ms. so at 44100hz, 200ms = 8820 samples, so because the graph is full, it is displayed.

but if you have a lower sampling rate, say 22050hz, then 200ms will only graph 4410 samples. because this is less than the size of the graph, the tabwrite~ is retriggered before the graph is full, and thus will not display the output. a smaller graph should help, hopefully.

oh, ignore that last post. i see what u mean now.

it also looks to me like you have discovered some 'buggy' behaviour, but before you go ringing the pd bug hotline, consider the following;

[pow~] is an external object to pd. it is not part of the core pd distribution.

for a 'vanilla' approach, you would use [expr~ pow($v1, n)], where n = the power you wish to raise your signal to.

you have not given an argument for [pow~]. if you want to square the signal, for example, you would use [pow~ 2]. technically, [pow~ 0] should always equal one, so you should just get a flat line, and why you get a square wave, i really don't understand. that looks like some sort of bug to.

anyway, personally i wouldn't use the [pow~] object because it is not officially supported in pd (there isn't even a help file for it, as far as i can see). [expr~] has a little bit more jargon, but always works fine for me.

...after further reading i discovered this:

">3) What is the quantity 0^0 (zero to the zeroth power)? Would it be
>0, since 0 times anything is 0, or would it be 1, since anything to
>the 0 power is 1? Or is this undefined, too?

This, too, is an indeterminate form. Its logarithm is 0 * infinity."

because your pow~ object has no argument, you are taking the power of zero, so when the wave is at zero, it's going to make weirdness.

oh by the way, if you just want to multiply your wave by itself (power of 2), then the easy way is just:

[osc~]
/\
/ \
[*~]

Hardoff has got it. if you connect a number box up to the right inlet of the pow~, and send it any value greater than zero, you get your signal and your visualized wave. When you send it a zero, it periodically is either 0 or 1. Interesting way to generate a square wave, though I'm not gonna rely on a bug for a true wave shape.

> I'm not gonna rely on a bug for a true wave shape.

Generally, beware of using [pow~] at the moment. There is an apocalypse coming soon. The [pow~] in Zexy was coded with an error (presumed since it's out of keeping with all other objects) such that the inlets are reversed. Miller has added [pow~] into vanilla, (and it will eventually filter into extended) with the inlets the CORRECT way round.

So, all patches that use Zexy [pow~] will eventually break. Including dozens of mine. We discussed this on list a while ago and the feeling was that [pow~] isn't used that much anyway, so let's break with past and correct it while it's not too late. I agreed with Miller and some others that this was a necessary evil and take the broken patches problem on the chin as payment for having a correct [pow~] in vanilla.

So for future reference, if you have a patch that seems broken and it contains an old [pow~] just try reversing the inlets.

a.

Ha Guys, thanks for al you posts.
I've read them all, but I am still wondering,
why do I see NO graph
but I CAN hear sound

While they are using the same output as their input. ( the graph and the dac )

( By the way it is not my sound card, and reducing the graph has no use either )

Thanks,

well, it seems to be related to the fact that connecting the dummy [osc~] also starts the graph working.

i don't know the exact answer, but you are asking the pow~ object to do calculations for which the solution is undefined using normal, real numbers. it makes weirdness, that can be somehow rectified a by adding a dummy osc~ or connecting to a [dac~], but not rectified by sending to a graph.