Brennon Bortz

I have built a patch that reads amplitude values in from a [buffer~] to create a breakpoint function for a [function]. When I draw a simple envelope in the [function] and [bang] it out to a [line~], all is well. However, when my patch loads the [buffer~] data into the [function] (with lots of breakpoints for more accuracy), banging the [function] works, but the output from the [line~] is SERIOUSLY rushed--on the order of 1000 faster when using 1000 breakpoints. Is this normal behavior? I've noticed that if I take the time to manually remove breakpoints, the [line~] output time slowly increases toward the correct duration. Any ideas?

I have built a patch that reads amplitude values in from a [buffer~] to create a breakpoint function for a [function].  When I draw a simple envelope in the [function] and [bang] it out to a [line~], all is well.  However, when my patch loads the [buffer~] data into the [function] (with lots of breakpoints for more accuracy), banging the [function] works, but the output from the [line~] is SERIOUSLY rushed--on the order of 1000 faster when using 1000 breakpoints.  Is this normal behavior?  I've noticed that if I take the time to manually remove breakpoints, the [line~] output time slowly increases toward the correct duration.  Any ideas?

function-chokes-on-too-many-breakpoints

I thought something in my [buffer~]->[function] logic was what was causing this problem. However, this "dumbed down" patch shows that the problem exists either way.

I see that I can use [function] with this many points safely if I drive a [line]'s output through the [function] instead. However, as this is driving amplitudes, I will (and do) get ramping noise. If this is what kills my idea, I think I'll go walk into the Irish Sea for the sweet relief of hypothermia. Nevertheless, thanks for looking!

I thought something in my [buffer~]->[function] logic was what was causing this problem.  However, this "dumbed down" patch shows that the problem exists either way.

I see that I can use [function] with this many points safely if I drive a [line]'s output through the [function] instead.  However, as this is driving amplitudes, I will (and do) get ramping noise.  If this is what kills my idea, I think I'll go walk into the Irish Sea for the sweet relief of hypothermia.  Nevertheless, thanks for looking!

On 20 janv. 09, at 17:07, Brennon Bortz wrote:

> I thought something in my [buffer~]->[function] logic was what was 

> causing this problem. However, this "dumbed down" patch shows that 

The length of the list coming from the "line format" output of 

[function] is 198, i.e. 99 pairs with a 1ms delta time, so it will 

I don't know why this is so and don't have time to investigate 

further, but please don't dive into the irish sea, I tried once and it 

Centre de Recherches et de Formation Musicales de Wallonie asbl

>
> I thought something in my [buffer~]->[function] logic was what was  
> causing this problem.  However, this "dumbed down" patch shows that  
> the problem exists either way.

The length of the list coming from the "line format" output of  
[function] is 198, i.e. 99 pairs with a 1ms delta time, so it will  
take 100ms to reach the end.
I don't know why this is so and don't have time to investigate  
further, but please don't dive into the irish sea, I tried once and it  
is very cold.

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl
http://www.crfmw.be/max


I get 99 pairs, as well. What is even stranger, the sampling rate has a DRASTIC effect on the time it takes. Like it or not, I may have to take a trip to the beach, as this is make or break for me. :)

I get 99 pairs, as well.  What is even stranger, the sampling rate has a DRASTIC effect on the time it takes.  Like it or not, I may have to take a trip to the beach, as this is make or break for me. :)


I've confirmed that this has nothing to do with the fact that there is a breakpoint at every integer. Rather, [line] seems to store, save, and display as many breakpoints as you have the sanity to set. I've tested this with both my [line]/[function] test, as well as by checking values at indices higher than 99. It simply won't dump any more than 99 pairs out the second outlet, however. Am I missing something here? Is this a bug, "feature", setting I'm missing? Has anyone found a workaround for this? Thanks!

I've confirmed that this has nothing to do with the fact that there is a breakpoint at every integer.  Rather, [line] seems to store, save, and display as many breakpoints as you have the sanity to set.  I've tested this with both my [line]/[function] test, as well as by checking values at indices higher than 99.  It simply won't dump any more than 99 pairs out the second outlet, however.  Am I missing something here?  Is this a bug, "feature", setting I'm missing?  Has anyone found a workaround for this?  Thanks!


On 20 janv. 09, at 19:18, Brennon Bortz wrote:

> I've confirmed that this has nothing to do with the fact that there 

>
> I've confirmed that this has nothing to do with the fact that there  
> is a breakpoint at every integer.

Not yet, but I will give it a shot. Thank you!

Not yet, but I will give it a shot.  Thank you!


Quote: stefantiedje wrote on Sat, 24 January 2009 12:14

----------------------------------------------------

> Actually, with that many points I would do all in the audio domain, 

> record or peek the envelope into a buffer~, and then use a 

> grove~/play~/wave~ to create your values...

> You can also draw more precisely in waveform~ than in function...

I'm afraid I may not have explained what I'm trying to do very clearly... I would like to use an existing waveform as an envelope, not the other way around. For the moment, I have resolved this by loading only 100 amplitude value/delta time pairs into a [function]. I don't like this though, as (1) it is very inefficient, and (2) loses a great deal of resolution due to quantization.

So, I'm now trying to devise a way to take an existing waveform in a [buffer~], allow the user to select a portion of this buffer in a [waveform~] object, and load this selection into a new [buffer~] to be used as the envelope. I have no problem doing most of this. However, in my patch I'm creating both an amplitude envelope and a frequency envelope. The frequency envelope is easy enough. The amplitude envelope, on the other hand, must necessarily have values that lie between 0. and 1. In order to make this transformation between the two [buffer~]s, I need to compute the maximum and minimum amplitude values of the existing waveform, which I'm having problems doing successfully. I can get close with various combinations of [peek~], [snapshot~], etc., but can't seem to find a way to get the EXACT maximum and minimum values. Any advice you might have would be very helpful. Thanks!

Quote: stefantiedje wrote on Sat, 24 January 2009 12:14
----------------------------------------------------
> Actually, with that many points I would do all in the audio domain, 
> record or peek the envelope into a buffer~, and then use a 
> grove~/play~/wave~ to create your values...
> You can also draw more precisely in waveform~ than in function...

I'm afraid I may not have explained what I'm trying to do very clearly...  I would like to use an existing waveform as an envelope, not the other way around.  For the moment, I have resolved this by loading only 100 amplitude value/delta time pairs into a [function].  I don't like this though, as (1) it is very inefficient, and (2) loses a great deal of resolution due to quantization.

So, I'm now trying to devise a way to take an existing waveform in a [buffer~], allow the user to select a portion of this buffer in a [waveform~] object, and load this selection into a new [buffer~] to be used as the envelope.  I have no problem doing most of this.  However, in my patch I'm creating both an amplitude envelope and a frequency envelope.  The frequency envelope is easy enough.  The amplitude envelope, on the other hand, must necessarily have values that lie between 0. and 1.  In order to make this transformation between the two [buffer~]s, I need to compute the maximum and minimum amplitude values of the existing waveform, which I'm having problems doing successfully.  I can get close with various combinations of [peek~], [snapshot~], etc., but can't seem to find a way to get the EXACT maximum and minimum values.  Any advice you might have would be very helpful.  Thanks!


Stefan, I just saw your post on this thread:

https://cycling74.com/forums/index.php?t=msg&th=37580&start=0&rid=4817&S=a0afc3a23a6e93f115ae219d74ad1080

Looks like that's what I need to do...thanks!

Quote: stefantiedje wrote on Sat, 24 January 2009 20:00

> What I understood is, that you have an existing waveform (jumping

> between plus and minus fast) and wanted to extract an envelope. (just

> the peaks and connect those with each other).

> Search for envelope following, you want to take the abs~ value of your 

> original sound. Then connect the peaks with rampsmooth~ with a short 

> attack time and a long release. That will give you an envelope. Just 

> paint a waveform on paper, and draw the waveform. The rampsmooth~ won't 

> connect the peaks exactly, but exactly enough for practical purposes...

Actually, these will be "enveloping" frequency as well as amplitude, so it's important to preserve the negative amplitudes. As what I'm building can be used as a sort of FM/AM instrument as well (with appropriate envelope selections), greater resolution than [function] can provide is important, so I agree with you. Has anyone already established what the smallest reasonably efficient values of the rampup and rampdown arguments for [rampsmooth~] are?

Quote: stefantiedje wrote on Sat, 24 January 2009 20:00
----------------------------------------------------
> What I understood is, that you have an existing waveform (jumping
> between plus and minus fast) and wanted to extract an envelope. (just
> the peaks and connect those with each other).

> You only need the absolute maximum...
> Search for envelope following, you want to take the abs~ value of your 
> original sound. Then connect the peaks with rampsmooth~ with a short 
> attack time and a long release. That will give you an envelope. Just 
> paint a waveform on paper, and draw the waveform. The rampsmooth~ won't 
> connect the peaks exactly, but exactly enough for practical purposes...

Actually, these will be "enveloping" frequency as well as amplitude, so it's important to preserve the negative amplitudes.  As what I'm building can be used as a sort of FM/AM instrument as well (with appropriate envelope selections), greater resolution than [function] can provide is important, so I agree with you.  Has anyone already established what the smallest reasonably efficient values of the rampup and rampdown arguments for [rampsmooth~] are?

[function] chokes on too many breakpoints?