Switch~ clicks
Hi,
This is a noob question, but is there an easy way to stop clicks from turning switch~ on and off?
Right now I'm trying to fade out my signal using vline~ and then switching the subpatch off, and likewise fading the signal in after switching on. It seems to work fine on os x, but I'm running the patch on an iPad with a blocksize of 16 and it clicks every time.
Thanks for your time
-chmod
if that patch is the way you're doing it, then you might be running into the same problem another person was talking about the other day - that pd's blocks are not always in sync.
also, you probably also want to send one block of zero's in to clear the audio buffer before switching, so i think it's generally a good idea to have 2-3 blocks of headroom between the line down time and the block switch.
if THAT doesn't help, then i can unfortunately suggest that you might be asking a bit much of the iOS and iPad to go down to blocksize of 16. try it with a block of 64 and see what happens.
There might be another reason too, of course...that's just all i can think of right now.
OH, unless of course you're running No GUI, in which case, there is a quite qell documented bug of delays not being set properly. Not sure if that has been fixed since i last checked, but if not, it might be affecting [pipe] as well. From memory, i think the easiest workaround was to dynamically turn dsp on and off and on again, but again, i can't be sure.
@mod said:
also, you probably also want to send one block of zero's in to clear the audio buffer before switching, so i think it's generally a good idea to have 2-3 blocks of headroom between the line down time and the block switch.
Thanks for your reply, can you tell me how to do this?
Also in case you're wondering, I'm using RJDJ's libpd for iOS, so there's no GUI.
There's atually a pretty nasty bug in Pd where audio objects that rely on the blocksize for their timing don't work right with blocksizes below 64. [vline~] is one of them. [bang~] is another. Try using [timer] to measure the time between bangs from [bang~] at low blocksizes to see whay I mean.
I see. I ended up using the dsp on and off workaround. Thanks though!
i didn't realize [vline~] was like that too.
good to know.
Hello again,
I'm still getting this issue at a different part in my patch, is there any way I can get rid of the clicks without having to resort to turning dsp on and off?
If there isn't, it isn't such a big deal.
Thanks!
Did you try just using [line~] instead? [switch~] and [line~] both snap to block boundaries, so I don't think there's really an advantage to using [vline~] anyway.
What is this dsp on/off workaround?
@chmod said:
@mod said:
also, you probably also want to send one block of zero's in to clear the audio buffer before switching, so i think it's generally a good idea to have 2-3 blocks of headroom between the line down time and the block switch.
Thanks for your reply, can you tell me how to do this?
Also in case you're wondering, I'm using RJDJ's libpd for iOS, so there's no GUI.
Hi chmod,
Even if no GUI is displayed, I believe that gui objects within the patch can still be processed. I would recommend making sure that there are no updating GUIs in your patch.
Can you attach your patch so we can see what you're doing?
Also, are you sure you're achieving a block size of 16? The default in libpd is 64, and while you might request a specific block size, there is no certainty that iOS will provide it - especially running at 44.1
Cheers,
Joe
Ahh, delaying a switch and fading at the same time is my favourite past-time 
If you're interested, this the current abstraction I've been using to standardise across the scenes we make.
Info:
Inlet 0: switch control inlet
Inlet 1: fade up time (so when it's turned on)
Inlet 2: fade down time
Outlet 0: delayed switch message
Outlet 1: input switch message (from inlet 0) for sending on to spigot controls
Outlet 2: a fade list in the format 'volume timeinms' e.g. [1 1000 (
You can set the fade times easily as arguments.
Let me know what you think!
Thanks for the patch Jwif, it works beautifully on os x, but unfortunately there's still a click on the device. I'm running at 22050Hz, and setting the tick rate to 64 causes the entire audio signal to click rapidly. I think I might just have to live with a very soft click in that part of the patch.
But thank you for your help and suggestions~
Oops! Looks like something went wrong!
