[function] chokes on too many breakpoints?

Jan 20, 2009 at 3:27pm

[function] chokes on too many breakpoints?

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?

– Pasted Max Patch, click to expand. –
#41856
Jan 20, 2009 at 4:07pm

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!

– Pasted Max Patch, click to expand. –
#149350
Jan 20, 2009 at 4:46pm

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 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.

p

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl

http://www.crfmw.be/max

#149351
Jan 20, 2009 at 5:53pm

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. :)

#149352
Jan 20, 2009 at 6:18pm

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!

#149353
Jan 21, 2009 at 7:39am

Did you try with [ej.function] ?

p

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

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

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl

http://www.crfmw.be/max

#149354
Jan 21, 2009 at 2:39pm

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

#149355
Jan 24, 2009 at 12:14pm

#149356
Jan 24, 2009 at 12:54pm

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…

Hi Stefan,

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!

#149357
Jan 24, 2009 at 1:04pm

Stefan, I just saw your post on this thread:

http://www.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!

#149358
Jan 24, 2009 at 8:00pm

#149359
Jan 24, 2009 at 8:14pm

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).

Then you understood correctly–sorry! :)

> 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?

Thanks again,
BB

#149360
Jan 24, 2009 at 11:27pm

#149361

You must be logged in to reply to this topic.