I'm storing a ~curve line into a buffer for use in gen since the gen.curve patch included doesn't take S curves or lists larger than 3 points. I have no issue getting the curve to properly store in a buffer and be recalled.

I'm trying to make it trigger at a repeated interval, but as you can see in the included patch, the reproduced curve line coming out of ~gen does not match the ~curve line.

In theory they should be identical, but it's not applying the curve from 1.0, its starting at 0. and playing the curve then back to 0. 

I have a feeling this is something simple I'm overlooking, but I can't figure it out.

message

curve~

scope~

loadbang

poke~

count~

buffer~

toggle

qmetro

gen~

buffer

param

peek

comment

mstosamps

history

counter

button

click~

ezdac~

I'm storing a ~curve line into a buffer for use in gen since the gen.curve patch included doesn't take S curves or lists larger than 3 points.  I have no issue getting the curve to properly store in a buffer and be recalled.

I'm trying to make it trigger at a repeated interval, but as you can see in the included patch, the reproduced curve line coming out of ~gen does not match the ~curve line.  

In theory they should be identical, but it's not applying the curve from 1.0, its starting at 0. and playing the curve then back to 0.  

I have a feeling this is something simple I'm overlooking, but I can't figure it out. 

Hey everyone,
I'm storing a ~curve line into a buffer for use in gen since the gen.curve patch included doesn't take S curves or lists large

storing-~curve-in-gen-buffer-not-producing-identical-results-to-actual-~curve-object

Maybe posted a bit prematurely! I think I figured it out.

Actually in comparison between the two, there's some amount of latency on playback from the gen version. Why might that be?

Actually in comparison between the two, there's some amount of latency on playback from the gen version.  Why might that be? 

looking within the buffer~, the way you've written curve~ into it, caused it to not write perfectly starting from the beginning of the buffer~(so basically, you figured it out, it's just that there's a bit of delay written directly into buffer~ before the actual curve~ was written).... would be my best guess(controlling the triggering/sync/stop of recording by events causes this innaccuracy).

Screen Shot 2020-11-06 at 9.50.31 AM.png

looking within the buffer~, the way you've written curve~ into it, caused it to not write perfectly starting from the beginning of the buffer~(so basically, you figured it out, it's just that there's a bit of delay written directly into buffer~ before the actual curve~ was written).... would be my best guess(controlling the triggering/sync/stop of recording by events causes this innaccuracy).


That makes sense. What would be a better way of recording the curve into the buffer to eliminate this delay?

i'm not entirely sure, was trying to figure this out real quick and couldn't come up with an easy solution: but basically, you need one or the other signals coming in to drive the other(normally, i would use the index counter(like count~/phasor~/etc.), to drive curve~... but curve~ can't be controlled by signals, so then i thought maybe as soon as curve~ goes from 0 to positive, it could start count~, but when i tried this it didn't work either...)... so basically, i'm stumped on that part in this case, too 😅

(another thought might be to use the techno~ object for the curvature, then you can drive that by signal in tandem with the index counting.... or zigzag~ going into slide~ or something similar...)

hopefully someone else might be able to offer more solutions.

i'm not entirely sure, was trying to figure this out real quick and couldn't come up with an easy solution: but basically, you need one or the other signals coming in to drive the other(normally, i would use the index counter(like count~/phasor~/etc.), to drive curve~... but curve~ can't be controlled by signals, so then i thought maybe as soon as curve~ goes from 0 to positive, it could start count~, but when i tried this it didn't work either...)... so basically, i'm stumped on that part in this case, too 😅
(another thought might be to use the techno~ object for the curvature, then you can drive that by signal in tandem with the index counting.... or zigzag~ going into slide~ or something similar...)

hopefully someone else might be able to offer more solutions.


I tried those as well and couldn't figure it out too...

I'm wondering if there's a better method to achieve the same result - essentially all I'm trying to do is keep everything gen based but I need curve~ to take a full curve list. The gen example of curve doesn't take lists so buffer is where I ended up. 

Is there a better way to take a curve drawn in function and get it into gen other than by using buffer?

I tried those as well and couldn't figure it out too... 

I'm wondering if there's a better method to achieve the same result - essentially all I'm trying to do is keep everything gen based but I need curve~ to take a full curve list.  The gen example of curve doesn't take lists so buffer is where I ended up.    

Is there a better way to take a curve drawn in function and get it into gen other than by using buffer? 

here's an example just showing how the signal-driver can sync everything nicely, using line~ to drive zigzag~... but unfortunately, it probably won't be the exact curvature you want:

not really for 'function' into gen~, but the peek~ object can be used to write in non-real-time/faster-than-realtime, see under the 'writing' tab in the helpfile for peek~, but i'm not sure how you'd get a sample-by-sample element list out of function for that, so it might not be that helpful(but using peek~ in non-realtime is one way to take exact curvature-algorithms which can define the curve sample-by-sample and write into buffer~.... if you can work this angle, it's probably the best way for initializing a buffer~)

Wow, this is perfect! Brilliant! Thank you so much.

word: Thank You from me too, Kyle! (got so addicted to adsr~ by itself, i didn't really familiarize with function properly, seeing how it can work element-by-element with left-outlet is going to inspire me) 🙌

So I've been toying around with this and it's definitely working, but I've run into one problem I can't seem to figure out.

You can trigger multiple curves lists into one curve~ - I've recreated the line~ function in gen to trigger the curves recorded into the buffer.

The issue happens when you try to combine the two buffer curves to trigger into the same outlet (in this case scope~). It's doubling the signal because they're both going from 0.-1., but I can't figure out how to combine them in a way that it allows both to be trigged without doubling the signal - i.e. exactly like curve.

At it's core, I'm really trying to recreate the functionality of curve~ in gen. The gen.curve example included in Max doesn't work quite the way I need it to as you can't easily retrigger the same curve (or multiple) into one instance quite the same way. Buffer seems ideal as it draws precisely the same curve drawn into function, it just isn't playing well with multiple.

Hopefully this makes sense - I can answer more questions if need!

The issue happens when you try to combine the two buffer curves to trigger into the same outlet (in this case scope~).  It's doubling the signal because they're both going from 0.-1., but I can't figure out how to combine them in a way that it allows both to be trigged without doubling the signal - i.e. exactly like curve.

At it's core, I'm really trying to recreate the functionality of curve~ in gen.  The gen.curve example included in Max doesn't work quite the way I need it to as you can't easily retrigger the same curve (or multiple) into one instance quite the same way.  Buffer seems ideal as it draws precisely the same curve drawn into function, it just isn't playing well with multiple.  

I think I figured it out - there might be a more efficient way of trigger these buffers, but I at least got them combining properly.

Storing ~curve in gen buffer not producing identical results to actual ~curve object