hi all ...
at the moment the scalar dsp fuctions are working on one float ... if this float changes it will most likely produce an audible click:
|float 1( | | |*~ 0| |
the usual way to avoid that in pd is to use a line~ object, that both uses cpu power itself and adds overhead since it's a vector/vector operation, not a vector/scalar operation any more ...
it would be possible to implement an interpolation between the two scalars (for one dsp block or so) and thus smooth the transition from one float argument to another ...
on the one hand this would add some overhead (the check if the scalar has been changed), but it would be possible to replace line~ objects with line objects that don't have the dsp overhead ...
i'm curious, what other people think of this ... i could change the behaviour of the pd interal object or write an external for that ...
cheers ... tim
I have pieces & abstractions in which such clicks play an integral part. Perhaps it's completely selfish, but I'd rather you did not change this behaviour in the internal objects.
Best regards,
Chris.
On Thu, Sep 02, 2004 at 11:08:25PM +0200, Tim Blechmann wrote:
hi all ...
at the moment the scalar dsp fuctions are working on one float ... if this float changes it will most likely produce an audible click:
|float 1(| | |*~ 0| |
the usual way to avoid that in pd is to use a line~ object, that both uses cpu power itself and adds overhead since it's a vector/vector operation, not a vector/scalar operation any more ...
it would be possible to implement an interpolation between the two scalars (for one dsp block or so) and thus smooth the transition from one float argument to another ...
on the one hand this would add some overhead (the check if the scalar has been changed), but it would be possible to replace line~ objects with line objects that don't have the dsp overhead ...
i'm curious, what other people think of this ... i could change the behaviour of the pd interal object or write an external for that ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
------------------- chris@mccormick.cx http://mccormick.cx
Tim Blechmann wrote:
hi all ...
i'm curious, what other people think of this ... i could change the behaviour of the pd interal object or write an external for that ...
i don't think that i would like this, but i am a very old-school plain pd patcher and i don't want pd to become a reactor-like app that takes care of everything. (i still get melancholic when i think that once you needed 3 objects~ to build a simple sine-wave-oscillator instead of just [osc~])
and then: interpolating for one block-size might produce clicks or not (depending on the blocksize, samplerate): so what you'd gain ? nothing but confusion why it works or not.
mfg.asd.r IOhannes
and then: interpolating for one block-size might produce clicks or not (depending on the blocksize, samplerate): so what you'd gain ? nothing but confusion why it works or not.
currently a volume control looks like this:
|line~| | |*~| |
means there is a line~ object that's consuming cpu power and a vector/vector multiplication that comsumes cpu power ...
if it's only something like this:
|line| | |*~| |
line is only generating messages and the multiplication is a vector/scaler multiplication ... (except for the interpolating part)
what you gain? free cpu power ... i once did some profiling on my performace patch an was suprised how much cpu usage line~ takes ...
cheers ... tim
what you gain? free cpu power ... i once did some profiling on my performace patch an was suprised how much cpu usage line~ takes ...
hmm. is it really that much?
maybe i miss the point, but what you explained could be put in an external, no? like 'dezip~' or something, to make it just as fast as built in support for this (which i do not like either)
and, btw, [lop~] with a frequency of 5-10 hz works fine too. don't know if it's faster/slower than line~
hmm. is it really that much?
it was about 5 % of my patch ...
and, btw, [lop~] with a frequency of 5-10 hz works fine too. don't know if it's faster/slower than line~
since a filer is hardly performing very good, since it's not possible to make use of simd instructions ...
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
it would be possible to implement an interpolation between the two scalars (for one dsp block or so) and thus smooth the transition from one float argument to another ...
I think, there should not *have to* be an interpolation going on between those two floats. I suppose people don't always want smoothness.
Ciao
I think, there should not *have to* be an interpolation going on between those two floats. I suppose people don't always want smoothness.
it was just a suggestion to make pd a bit faster ... i'll write an external for it ...
tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
I think, there should not *have to* be an interpolation going on between those two floats. I suppose people don't always want smoothness.
it was just a suggestion to make pd a bit faster ... i'll write an external for it ...
Did you take a look a matrix~ in zexy yet? I often use matrix~ for dealing with volumes in greater numbers of sound paths. It has interpolation built in, but I never benchmarked it. I do however have the strong "feeling" that it is faster than using a lot of [line~]s or maybe even [line]s.
Ciao
Did you take a look a matrix~ in zexy yet? I often use matrix~ for dealing with volumes in greater numbers of sound paths. It has interpolation built in, but I never benchmarked it. I do however have the strong "feeling" that it is faster than using a lot of [line~]s or maybe even [line]s.
well, matrix~ is not using any loop unrolling / vectorizing features ... if i've got a simple volume control, it's more or less a vector/scalar multiplication, sometimes this scalar will change ... so a |*~ 0| would perform best ... is suppose matrix~ will add some overhead (no benchmark, though)
cheers... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
well, matrix~ is not using any loop unrolling / vectorizing features ... if i've got a simple volume control, it's more or less a vector/scalar multiplication, sometimes this scalar will change ... so a |*~ 0| would perform best ... is suppose matrix~ will add some overhead (no benchmark, though)
True, but the difference between [line[ and [line~] itself is not big, it will get a problem if you need and create a lot of [line~] objects. In this case, [matrix~] might have less overhead in the end, as it could provide room for optimizations. I didn't check if it does, though ...
BTW: I now found, that matrix~ is available in zexy and in creb. I'd say zexy has the older rights. ;)
Ciao
On Thursday 02 September 2004 17:08, Tim Blechmann wrote:
hi all ...
at the moment the scalar dsp fuctions are working on one float ... if
this float changes it will most likely produce an audible click: |float 1( | |*~ 0|
the usual way to avoid that in pd is to use a line~ object, that both uses cpu power itself and adds overhead since it's a vector/vector operation, not a vector/scalar operation any more ...
it would be possible to implement an interpolation between the two scalars (for one dsp block or so) and thus smooth the transition from one float argument to another ...
on the one hand this would add some overhead (the check if the scalar has been changed), but it would be possible to replace line~ objects with line objects that don't have the dsp overhead ...
i'm curious, what other people think of this ... i could change the behaviour of the pd interal object or write an external for that ...
cheers ... tim
As others have suggested, I don't think changing the behavior of such a basic object would be very wise, because it would break a lot of existing uses.
For example, I use *~ all the time in the chain to set the pitch of a poly instrument patch. Although portemento is usefull sometimes, I wouldn't want it forced. In a patch used in a poly setting, for example, this would cause the new pitch to ramp from the old pitch of the last event using that voice, which is usually not what you would want.
Larry
As others have suggested, I don't think changing the behavior of such a basic object would be very wise, because it would break a lot of existing uses.
for my use, a volume control, i wrote an optimized external ...
i'll probably add some interpolating scalar dsp functions to sc4pd ... some kind of sc*~ or so ...
cheers ... tim
-
Chris McCormick -
Frank Barknecht -
IOhannes m zmoelnig -
Larry Troxler -
Tim Blechmann -
Tom Schouten