hi,
here's a patch that use switch~ to turn off/on an effect. using switch~ will save some cpu when the effect is turn off right? so that is good, but the thing is i have a glitch when switching... is there a way to avoid this? or maybe there's a better way for this kind of setup in -> fx1and/or fx2 and/or fx3 -> out.
i will add a dry/wet option to the fx part. pat
On Thu Jan 04, 2007 at 06:39:45PM -0500, patrick wrote:
hi,
here's a patch that use switch~ to turn off/on an effect. using switch~ will save some cpu when the effect is turn off right? so that is good, but the thing is i have a glitch when switching...
06:29 c how do you keep the voices from using CPU when not in use? turn off their abstractions with block~ ? doesnt that cause a dropout as the dsp graph is resorted? 06:29 tim167 c: [switch~] 06:29 c yeah that 06:30 c nothing like pushing core deficiencies up into user level hacks 06:30 c i remeber rigging up a polysynth using switch, and it woul get blips, it hink 06:30 ClaudiusM c: i think switch~ just turns off processing for that abstraction, meaning the input buffers still get filled, the outlet buffers still get read, but nothing gets changed 06:31 ClaudiusM c: which means you have to have zero for a whole block before switching off or you get high pitched noise... 06:32 ClaudiusM c: .. on the other hand no dsp chain sorting issues (NB: i could be talking out of my arse, i just absorb from pd-list and pd-dev, i haven't read the source)
so uh... try zeroing the DSP block, or leaving a block of headroom? or is it causing everything else to glitch too. if thats the case, you probably can't avoid it
a way to avoid this?
You'll probably need to use a [line~] or [vline~] to fade out 1ms or
so before the [switch~].
.hc
On Jan 4, 2007, at 6:39 PM, patrick wrote:
hi,
here's a patch that use switch~ to turn off/on an effect. using
switch~ will save some cpu when the effect is turn off right? so
that is good, but the thing is i have a glitch when switching... is
there a way to avoid this? or maybe there's a better way for this
kind of setup in -> fx1and/or fx2 and/or fx3 -> out.i will add a dry/wet option to the fx part. pat
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
You'll probably need to use a [line~] or [vline~] to fade out 1ms or so before the [switch~].
.hc
On Jan 4, 2007, at 6:39 PM, patrick wrote:
hi,
here's a patch that use switch~ to turn off/on an effect. using switch~ will save some cpu when the effect is turn off right? so that is good, but the thing is i have a glitch when switching... is there a way to avoid this? or maybe there's a better way for this kind of setup in -> fx1and/or fx2 and/or fx3 -> out.
i will add a dry/wet option to the fx part. pat
Yes, see attached patch - this logic needs to be present in all switched patches (thus it is a prime example for an abstraction...), I just did it for the [pd bypass] so you don't get glitches if the sliders are all at the bottom, but you still get glitches if any of the sliders are high.
Claude
hi miller,
my request is to remove this limitation of pd: error: soundfiler_read: truncated to 4000000 elements
is it possible to make it endless? if not then a ./configure option would be neat or maybe hans you can do something for the devel version? i would say computers can compute at least 40000000 (maybe not mine, but some in 2007).
OT: thanks claude for the [switch~ delay patch] it's working (did you make any pd music lately? please share!). see you on #dataflow.
one last pd track. it's using zamatt (thanks hard off for sharing it) and other patchs (live granular (i can't remember who sorry)):
http://www.workinprogress.ca/pd/music/jouer.ogg
pat
Hallo!
my request is to remove this limitation of pd: error: soundfiler_read: truncated to 4000000 elements
is it possible to make it endless? if not then a ./configure option would be neat or maybe hans you can do something for the devel version? i would say computers can compute at least 40000000 (maybe not mine, but some in 2007).
Isn't it possible to set this with -maxsize ?
LG Georg
hi,
you're right, -maxsize is the solution, sorry! i think i've set it too high, pd crash when i load a "big" wav.
pat
On Fri, 5 Jan 2007, patrick wrote:
my request is to remove this limitation of pd: error: soundfiler_read: truncated to 4000000 elements
edit d_soundfile.c, find DEFMAXSIZE, change to a better value.
but I don't recommend setting it to more than 16777216, because that's the maximum size that [tabread~] can take before not doing what you expect from it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada