Hi there , this is my first post ! I'm looking for an extern which avoids clips in signals [~] i dont know if it exist on pd own objects or if it is on the repositori. I coudnt find an efficent way to know which are the externs in the repositori, looking in each folder is the only way to know it's content ?
Here goes a detailed explanation of what i mean by avoid clipping:
I'm playing blocks of signal from diferent arrays, when one stops playing the other starts, the problem is that most of them dosnt start and end at 0 value and a clip sounds between in the change of block. Due to the whole project aim i cannot use crossfading between blocks.
I've been thinking in a possible solution :
1- take the last value of one block and build a linear ramp of N samples to the N value of the subsequent block and add all the values to that ramp this solution would require the whole block as an input and wouldnt work as a in-out object ->[~smoothclips]->
2- Dettect a clip as a suddent fall of values between two samples * abs(X(-1)-X(0))>threshold* and for the N subsequent samples X(i) do : X(0)= 0.8*X(-1) + 0.2* (0) X(1)= 0.6*X(-1) + 0.4* (1) X(2)= 0.4*X(-1) + 0.6* (2) ... and so on
Thank you !
Hi Lau,
I guess you're building a beat concatenator so you have no room for introducing timing offsets.
First, termminology - let's not call these "clips", I think discontinuities is a better word.
Your first solution is similar to what is being discussed in another thread on dynamic delays - Millers "rendezvous" algorithm where the two segments are spliced via a DC offset introduced by a ramp.
The second one really amounts to crossfading or short window average filter. Further, how can you be sure your detector won't have a false positive from a fast signal slew rate?
If my assumption is right then for simplicity I suggest revising your constraints. A 64 sample crossfade will introduce negligable timing problems.
Am I missing something or wouldn't it be simplest to add a quick and dirty 5 ms or so fade in/out envelope that follows the timing of the array triggers?
~Kyle
On Fri, Jun 6, 2008 at 12:17 PM, Andy Farnell padawan12@obiwannabe.co.uk wrote:
Hi Lau,
I guess you're building a beat concatenator so you have no room for introducing timing offsets.
First, termminology - let's not call these "clips", I think discontinuities is a better word.
Your first solution is similar to what is being discussed in another thread on dynamic delays - Millers "rendezvous" algorithm where the two segments are spliced via a DC offset introduced by a ramp.
The second one really amounts to crossfading or short window average filter. Further, how can you be sure your detector won't have a false positive from a fast signal slew rate?
If my assumption is right then for simplicity I suggest revising your constraints. A 64 sample crossfade will introduce negligable timing problems.
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I made a lot of assumptions about Laus program there - but wouldn't a 5ms fade out and in cause a nasty 'drop out' ? A 10ms gap is certainly something you'd hear, and I guessed Lau was trying for a perfectly smooth join. (?)
On Fri, 13 Jun 2008 13:51:39 -0500 "Kyle Klipowicz" kyleklip@gmail.com wrote:
Am I missing something or wouldn't it be simplest to add a quick and dirty 5 ms or so fade in/out envelope that follows the timing of the array triggers?
~Kyle
On Fri, Jun 6, 2008 at 12:17 PM, Andy Farnell padawan12@obiwannabe.co.uk wrote:
Hi Lau,
I guess you're building a beat concatenator so you have no room for introducing timing offsets.
First, termminology - let's not call these "clips", I think discontinuities is a better word.
Your first solution is similar to what is being discussed in another thread on dynamic delays - Millers "rendezvous" algorithm where the two segments are spliced via a DC offset introduced by a ramp.
The second one really amounts to crossfading or short window average filter. Further, how can you be sure your detector won't have a false positive from a fast signal slew rate?
If my assumption is right then for simplicity I suggest revising your constraints. A 64 sample crossfade will introduce negligable timing problems.
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz