vojko v

I have a set of arbitrary values stored inside a buffer~ and I want to find out which one of those values is the nearest to my input that is going into a gen~ object.

In the patch that I am copying below the arbitrary values stored in the buffer are [10 20 30 40 50 60] and the gen~ code gives the expected result in all cases (e.g. for input value "28" the nearest is "30") except when input value drops below 15, the gen~ gives the nearest value to be 0, not the expected value "10".

Does anyone have an idea why is that happening?

P.S. I am doing this gen~ code to implement a version of it inside the "Chopper_repeat" example to modify it so it plays chords.

Hi,
I have a set of arbitrary values stored inside a buffer~ and I want to find out which one of those values is the nearest to my input ... 

finding-the-nearest-value-in-buffer~-inside-gen~-codebox

This seems to work. I've only just started using Genexpr so this was good practice but keep in mind that the buffersize is hardcoded. I don't know how you can get the numbers of samples in a buffer but i'm sure there is something like "buffer.size()" you can replace it with.

The second for-loop had the error, you had "j=1" so it never checked the first index. 


And i fixed my patch as well. I found the dim(buffer) in your patch and added it.


Even with the "j=0" it still gives the same error, it gives that nearest number to 11 out of the list [10 20 30 40 50 60] is 0.

but your example seems to work well, thanks

Noone looks at "expected results" ofcourse :p 


Honestly i didn't look at that, the third-outlet of your genpatch gives the correct index though and if you feed that into index you'll get the correct corresponding number.

And actually wouldn't it be the correct  result? 11 is closest to 10 and 10 is at the 0 index of your buffer so it's correct after all right?

Finding the nearest value in buffer~ inside gen~ codebox

nouserid

Hey there,  I'm trying to modify this lovely bit of code from Kengo to have the option to play the grains in reverse but can't seem to work it out.  Any help would be very much appreciated.  

Hey there,  I'm trying to modify this lovely bit of code from Kengo to have the option to play the grains in reverse but can't seem to work ... 

grain-reversal-codebox

Grain reversal codebox

billyz123

I dove right into gen~ by trying some granular time stretching. I ran into some issues when adding more than one peek~ object. My temporary solution was to just use a delay which works fine, but is there any reason my other idea isn't possible? ...or am I doing something wrong? 

granular-stretching-in-gen-issues

The problem is that the second peek jumps position in the buffer at the high point of the envelope, rather than the zero point; hence the clicking. What you'll want instead is to ensure that the each peek switches position only when the envelope is at the zero point.

Also for using peek you probably want to use @interp linear or better to avoid noisy aliasing.

It's probably easier to run a phasor for the first peek, and using it to drive the envelope as well as the grain index. The offset into the buffer (according to speed) should be independent, and you want to only sample this when the envelope is at zero, i.e. when the phasor wraps. A [sah] could be one way to do this.

Then a second phasor can be derived from the first simply by adding 0.5, mod 1, and duplicating the rest of the envelope/peek processing.

If you want more concrete examples, let me know.

Thanks for your help Graham!
I ended using phasors outside gen and that worked. I was trying to avoid using [sah] because even within gen you still have to set it to trigger at 0.001(i think) for it to work with phasors... no matter where the phasor is (inside gen or outside). My main goal was to use strictly samples, so that's why I converted everything to integers inside gen. This works but not completely. Either way I'm happy with the results :)
Also, is there a way to trigger the phase offset of the phasor within gen?


There isn't a way to reset the phasor phase currently, but a phasor is basically just an accumulator, so it shouldn't be too difficult to construct from a [+= @max 1]. 

The [sah] can be be triggered easily using [delta] -> [sah 0], it will trigger when the phasor loops. Take a look at the gen~.pitchshift.maxpat in /examples/gen, or the gen~.slicer.maxpat, both of which are similar to what you're doing.


Thank you sir, i will check that out because I didn't even know it was there :)
I'm still confused about how you would reset an accumulator but I guess it doesn't matter because using the phasor from outside gen seems to work amazingly. 

Obviously there's a lot going on now with Max/Msp/Gen ... I've never really had a clear understanding of the precision of it all which is probably why I was excited that Gen would work on the sample level. I made a version of this stretcher using only phase and floats and it works great.
So my question now:
  Is there some kind of precision conversion from outside Gen into Gen? ...or can you direct me to an explanation/breakdown of the signal level of Max/Msp. I understand all the Max Scheduler stuff perfectly fine as I've been working with this program for many years, but when it comes to :
 I/0 vector size
 Signal vector size
 Vector Optimization
 ...and now Gen, well I'm afraid you've lost me :)

Thanks for posting this, V interesting. One question, though, is it me or is the mirrored stuff on the right hand side of the gen object (the overlapping grain stuff?) actually outputting anything?


I'm guessing you don't own gen so here is a simple test to prove it does output something... in fact, without it's output we are all doomed... dooooommmmed!


Try this one - the second gen~ contains all the phasor & gate functionality embedded within it. I built phasors out of history, + and wrap. Because the history is named, it can be used as a parameter, which is how it can be reset:


Graham - I love you.  I've been looking for wrap and didn't even realize it (I'm building a very specialized phasor, myself) - this is perfect.  Thank you!


Thanks Graham, great ideas!
Don't forget to subtract the grain-size right before the [peek] :)
Plus, I get clipping sounds or whatever when changing grain size... I'm guessing it's an {sah] thing but I haven't figured it out yet.
I'm not really sure there's a point to having the phasor inside gen, at least in this case... but it is cool :)  Something I'll definitely use. Thanks!


OK, I'm going to mildly hijack this thread, I hope that's OK, Billyz.  The phasor I've been working on, needs a 'stall time' as well as phase control similar to the built in MSP phasor.  Stall time is set in MS - essentially, the phasor does one ramp, then sits at 0 until the stall time has passed, then does another ramp from 0 to 1.

Included in the patch are two possible options - the first one doesn't work completely, but it's nice and clean.  Sadly, doing the phase merely as a [+] before wrapping, makes the stalltime function screw up majorly.

The second option is MUCH more complex, but it was the only way I could come up with to make phase work, as well as stall time. But it's just... so ugly!  And the phase isn't clean, nor is it elegant - it's essentially a delay, but I'm sure after a while it would cause multiple stall-phasors to fall out of sync a touch. (Also I never thought to use a named history object before, so the 'reset' function on it is still clunky).

Anyone have any great insights on how to make the simpler patch do what I need it to do?


I'm all done with this thread btw :)
I am curious though... what is point/purpose of this "stall time?"


@billyz123: yes, I forgot to add the [- grain_size] there. To avoid the clipping sounds when changing grain_size, yes, need to use another [sah] and trigger it at the envelope end. Be careful to set @min and @max on grain_size then; e.g. it won't handle negative sizes very well...
Having the phasor inside might be slightly more efficient, but also opens up the possibilities of doing other things to it... 

@MuShoo: You were on the right track with the first one. Try the following patcher. (I took out the [param phase] stuff for now to keep it simple, I wasn't 100% sure what you wanted it to do). The main logic is to use the reset inputs of the [+=] objects to ensure that only one of them is accumulating at any time. While the first accumulator is doing the 0..1 ramp, it keeps sending a '1' to the second accumulator to keep it at zero. Once the first accumulator goes above 1, the gate closes and output becomes zero, and the second accumulator is allowed to start counting. Once the second accumulator reaches the stall time, it triggers a reset on the first accumulator again (same as you had it), which will feed back to reset the second. It's super useful to have a couple of extra [out] objects while debugging gen~ patchers to see what signals are passing through. I've left one in that shows the reset trigger from the second accumulator. 

BTW there's a feature coming in the next update (v. soon) which will offer a very different and probably much easier way of doing this.


Graham - I'll likely wait until the next update, then!  I'd programmed this exact thing in Java, and it was rather simple (mainly because I could do multi-requirement if/then statements, and such.  I'm sure there's a way to do them in Gen~ but logic gates confuse me sometimes.)

Sadly I need the phase function to work almost exactly like it does with phasor~ - if I send one phasor~ a 0, and another one .5, simultaneously, their ramps will be .5 apart, always.  The second of my examples allows for this, but it handles it by having 3 accumulators - one for the main ramp, one for stall time, and one to phase-lock (if I remember correctly, at least.  It's been a while since I really looked at that one). So when phase is changed, it forces the other two accumulators to 0, until the phase accumulator has counted (at the current main-phasor frequency) to the number specified as the phase.

Which, honestly, works 'okay' - it's just ugly and in-elegant. 

Your patch seems to be functionally the same (though with different objects, and for some reason I can't have a stall time of 0) as my latest attempt (minus the phase-locking).  I do, however, like the use of += for the main accumulator in yours, because I feel like there's something that could be done with the @min and @max options, though I'm not completely certain how to make them work.


I'm resurrecting this old topic as I'm trying to make a time stretch patch with an instrument input and want this to work completely inside gen so I'll need to use a data object instead of a buffer. I'm not really familiar with working with real time data buffers inside gen and can't seem to make it work.

granular stretching in gen~ (issues)

Ryan Lieber

I programmed a sine oscillator in gen~ that works fine when the input frequency in Hz is greater than "1.0".  However, when the input frequency is less than "1.0" (e.g.  0.5), the gen~ oscillator looks like it's being re-triggered when the amplitude value hits "-1.0". 

A regular phasor~ to cos~ connection is shown for comparison's sake. Hopefully the included pictures illustrate what I mean. 

Any ideas on what am I missing in my gen~ oscillator?
Thanks!!!

Gen-Osc.png

Comparison-1.png

Comparison-2.png

Hi!
I programmed a sine oscillator in gen~ that works fine when the input frequency in Hz is greater than "1.0". 

gen~-sinusoidal-oscillator-is-re-triggering-for-some-reason

by using 'counter' that way, you end up putting the multiplier in the wrong place(you could use counter if you feed it the fractional value [1]->[/ samplerate] and then multiply that before going into counter)... i prefer the accumulator op since it feels simpler:


but here's that same patch with counter just to be complete:


(and i used the 'sin' op since we're talking about sine waves, but they basically sound the same ...the difference is mainly when you hard-sync... and i put the click~ and phasor~ in to show that as well - [edit: just to avoid confusion, figured i should also mention that the phasor~ scope is set to range 0. and 1. while gen~-sin is set to a range of -1. and 1. in the above patch unlike in my pic])

Yo Raja, thanks for the help! I see what you mean about the count or accumulation beginning after the multiplication.

Why that matters, I definitely don't know haha. I'm still a beginner at this level of DSP and math. :)

ah, no worries, i should explain that part better:
-first, when driving a sine oscillator in radians, the count being multiplied by 'twopi' will act on the phase of the sine-oscillator as if wrapping anything outside the range of twopi, back within it; this is the magic of 'radians' - they radiate in a circle when they apply to phase :)... (for example, "6 * π " is the same as "2 * π", "-5.2 * π" is the same as "-1.2 * π"(5.2/2 = 2 with remainder 1.2, and then you just account for the negative-sign... not to go off to much on this tangent, but negative radians is simply the same as negative-phase... add a [wrap -pi pi] after the [* twopi], you'll notice there's no difference in behavior), etc.)

-given the above point, you don't want a ramp from 0 to 1, multiplied by 'twopi', to fail at completing the full ramp(when it doesn't span the complete distance of twopi before resetting back to 0, it will have the effect of resetting the phase of your sine-oscillator)

-by working in fractional increments relative to the duration of a single sample at your samplerate(1/samplerate), and then multiplying that by the frequency desired simply to stretch the duration of each sample-increment, the 'counter/accum/+=' ops will be allowed to count upward continuously(and you'll never end up breaking the progression between 0 and twopi), thus allowing the phase of your sine-oscillator to be ever-continuous as well

(^reading that all back, i realize i'm a bit wordy haha, not quite the 'scholar' in terms of my semantics, apologies, but hopefully it makes sense, and if not, i usually get this far on DSP, just by working example values through each part of the dsp-chain... so at the point where you might multiply a ramp from 0 to 1, by 0.5, it would only go from 0. to 0.5, then from there from 0 to π(instead of the full range of twopi), and then it was easy to see how it would break the phase of the sine from there... working backwards, you'd then just figure out how to make the count continous: by allowing a multiplier to only change the increment fed in by which it counts, and not allowing a drastic change to occur at the output of the count itself)

Hey Raja, thanks  for your explanation! It may not sound 'academic' but it sure is helpful to me. To question and to clarify...

Is the value after 'twopi' considered a radian? Not a degree?

Is the value after 'sin' considered an amplitude?

Is essentially the whole 'game' of oscillators just turning radians into amplitudes but in a sample-to-sample fashion via some accumulator or counter type function? Or is it about turning 'angular frequencies' into amplitudes. It seems radians and angular frequencies are almost interchangeable?

correct! to answer another question you asked: 0 to 'twopi' could be said to represent degrees from 0º to 360º... but the actual input going to 'sin'/'cos' is in 'radians' ...this is how they are interchangeable in reference, but not in usage. while you'd just have to scale '0 to twopi' into the range of '0 to 360' if you wanted degrees... 'sin' and 'cos' work directly with radians because they're functions which trace the radius around a unit circle.
this video might explain that better than i could(but i recommend going to the 'settings' icon near bottom right of the video, and playing it at 1.5 speed to save you time :D):

yes, exactly... (an amplitude between -1 and 1, how you use 'amplitude' depends on context too:
https://en.wikipedia.org/wiki/Amplitude )
this is why i don't claim to be 'scholarly': there are others who might be able to give you a clearer definition that might govern all contexts(i also get confused often because when working with FFT, you'll find 'magnitude' is very similar, but not exactly the same).

Is essentially the whole 'game' of oscillators just turning radians into  amplitudes but in a sample-to-sample fashion via some accumulator or  counter type function?

short answer: you could say this about working with functions being generated to 'oscillate' within a specific range, in real-time within a digital-system that runs at a specific sample-rate(such as using sin/cos/etc. to 'generate' the values per-sample)... and just to be clear, the radians aren't turned directly into amplitudes but rather used to drive a function(usually trigonometric in nature) which will then draw out or stream a specific shape of amplitude.

but long answer: i hesitate to summarize the whole game even there, as you'll run into other contexts such as wavetables where they can serve as oscillators, but might just take 'phase' from 0 to 1; see the 'cycle' op within gen~, it can be changed with the @index attribute to be driven by 'phase'(in which case you're connecting an external accumulator such as 'phasor', or anything you can create which would ramp or traverse the range between 0 and 1)... even their terminology there is slightly confusing... when you option/alt-click on the op to get quick-help on it, it claims it defaults to being 'driven by a frequency input', but the word 'driven' in this case means two completely different things, really what they mean is that you can either 'control' the frequency by default(in that case, it will be 'driven' by an internal phase-accumulator), or you can 'drive' the phase of its internal wavetable from the outside, using a connected phasor:


here's a patch that can show some of the things i've been mentioning so far a bit better:

...then there's various types of other oscillators which don't necessarily need to work this way depending on how you construct them(i.e. lfo oscillators, or chaotic oscillators(which would introduce chaos to break up the symmetry/asymmetry a bit), or oscillators which don't need to work within audio ranges, could therefore use other methods beyond accumulators  - 'strange attractors' are a bit like this, they can be said to 'oscillate' at times depending on their settings, and are also somewhat chaotic by nature).

but basically, while an 'oscillator' can be anything that oscillates between a high and low value, i think you understand it perfectly as it applies to making oscillators from real-time generated functions such as 'sin'/'cos' within a digital/sample-based system 👍

Also, the 'GO' book here is one of the best i've found to help understand much of this at a more in-depth level, i'd also describe it as falling at a nice 'intermediate' level where both beginners and advanced will gain a lot from reading it:
https://cycling74.com/books/go 
(chapter 3 in particular helps you build oscillators from 'sin'/'cos'/'phasor'/'triangle' to form many more shapes than just the basic ones)


Hey Raja, sorry for the late reply, but I need at least a few days to read and digest your replies lol. Surprisingly, everything you're saying makes sense!  

You've definitely opened a can of worms in your patch by including a low pass filter, something I know very little about. 

Is filter design a pretty logical thing to learn alongside oscillator design? I assume there's a lot of overlap in regards to calculus-type functions? I guess filters are where you start running into delay lines? Oscillators in and of themselves don't really rely too much on delay lines, I suppose?

I was pondering buying the new Gen book, I think I'll give it a go! Thanks again for your help!!!

Is filter design a pretty logical thing to learn alongside oscillator  design? I assume there's a lot of overlap in regards to calculus-type  functions? I guess filters are where you start running into delay lines?  Oscillators in and of themselves don't really rely too much on delay  lines, I suppose?

filters can be set to self-oscillate, so there is some crossover(oscillation is just a stream of values oscillating within a range)... learning everything alongside everything else will always inform in the best, well-rounded way(there are medical studies that show the older people get the more they can resist certain affects of aging on the brain by learning new things that call into question what they already know, as opposed to simply building up their already established expertise on one single thing: i think some older people i've met, their mind can fall like a house of cards, you don't want to build it straight up in one column, you build a well-rounded foundation and then build from there, maybe creating more and more more branches and additions further on in life... i went off on a tangent, but it's a problem i see here on forums and on the internet in general: we want to only focus on the information we're searching for, but then we might miss so many other things that could've helped us approach that focus from a wider perspective).

but ya, try out the book, it'll go over all these things even better than i can(if i try to explain this stuff to you, i'll just end up opening you up to more questions which i won't be the best at answering) :D

Gen~ Sinusoidal Oscillator is re-triggering for some reason

.quasar

Played around recently with Digital Waveguide Meshes in gen~  to model membranes. Used this thesis as a basis.

There are a few examples in max for rectilinear Waveguide Mesh patches but from what I read so far, the "triangular" meshes offer some advantages in terms of dispersion.

This is a 3 nodes triangular Digital Waveguide Mesh examples (each node consist of 6 waveguides). Implemented a few other options like damping and nonlinearity. 

Tell me if you're missing any abstraction of gendsp file but i think everything is in there !

Played around recently with Digital Waveguide Meshes in gen~  to model membranes. Used this thesis as a basis.
There are a few examples in m

-sharing-digital-waveguide-mesh

great patch, thanks!

Just a small suggestion to replace the third party object dcblock~ with a simple gen~ abstraction (native dcblock) or with [biquad~ 1. -1. 0. -0.9997 0] to prevent errors in the absence of the object (my case…).

Thanks ! Did not spot that one, usually I actually use the native gen~ version ;)

The msp dcblock~ external comes from the Percolate package. great one btw => there's is actually a rectilinear waveguide mesh external in it (mesh2d~)

I totally missed this when it was first posted. This is fantastic!

thank you for bumping this thread, i totally forgot who's patch i've been using for years now(i had it named "Quasarwavgd" and thought 'Quasar' was a certain kind of technique... haha, now i can give proper credit for this version i turned into MC), Thank you @.Quasar!

Thank you for bumping this thread, i totally forgot who's patch this was(had it saved as "Quasarwvgd" and thought 'Quasar' was the name of a certain waveguide-technique, haha). AND THANK YOU, @.QUASAR!

it sounded so good, i turned it into an MC-ified version when i first saw it(you might want to add a limiter to the last vst~ in the chain before output just to be safe... the other vst~s before that were for compressor, reverb, and eq... in that reverse order before the final limiter)...
but first! you'll need this special mc-based UI thingie i made to send different permutations of MC signals in as parameter controls, save it as "mcui.maxpat" in the same folder as the bottom patch:


(the sequenced preset object will take care of parameter changes for you along with the sequence of notes(sorry for the cheesiness of the melodies, haha), but you'll want to set the style of mc-dispersion yourself to something other than the default 'deviate' for many things... see this video for one way👇)

[sharing] Digital Waveguide Mesh 

Dan Gayle

In the new gen~ book code examples, there's a gendsp file called go.allpass.diffuser.stereo.gendsp, but I can't find it in the book and don't know exactly what it is doing. 

In the new gen~ book code examples, there's a gendsp file called go.allpass.diffuser.stereo.gendsp, but I can't find it in the book and ... 

stereo-all-pass-diffuser-sample-code-from-gen~-book

I see it used in the interpolating_glides example as a reverb

Stereo all pass diffuser sample code from gen~ book

Anthony Scott

In other languages like Faust, conditional routing will still evaluate the unselected branch, and can’t be used to avoid unnecessary or forbidden computations (like divide by zero). 

I noticed the gate operator will feed zeros, but I can’t find anything about the other ones. 

In other languages like Faust, conditional routing will still evaluate the unselected branch, and can’t be used to avoid unnecessary or ... 

do-routeconditional-operators-compute-all-branches

In MSP (audio), there is a single audio network that's evaluated completely for each signal vector. So, gate~, matrix~ and other output zeros, etc.
In Max (messages, numbers), gate, route, sel, etc output the data selectively: using [route 0] and just the right outlet is indeed a way to filter out 0s.

and while you could interrupt and recompile an audio network in MSP by scripting or with the help of mute~ or poly~, afaik in gen~ it is impossible to "turn a connection off" to save processing power.

Do route/conditional operators still compute all branches?

Misemao

I am wondering if there are any resources on optimizing performance in gen~ specifically, but also in Max/MSP in general. This includes things like genexpr vs gen-objects, loops, branching, using multiple gen-patchers vs combining as much as possible in one gen patcher, gen vs rbno ect.
I've found some bits of information in different forum threads and videos, but I couldn't find any definitive guides on performance-optimization. I also would be interested what the best way to do performance comparisons in Max/MSP is. 

Hello,
I am wondering if there are any resources on optimizing performance in gen~ specifically, but also in Max/MSP in general. 

optimizing-performance-in-gen~

Which performance do you want to improve, specifically?
A good old way of comparing performances in Max/Jitter world uses the [timer] object. Here for instance comparing [jit.op] and [jit.expr]:


Optimizing Performance in gen~ 

stringtapper

So I'm working on building filters in gen~ and I made a biquad based on the Direct Form 2 block diagram you can see here:

http://upload.wikimedia.org/wikipedia/commons/5/5e/Biquad_filter_DF-II.svg

So it seems like my patch is working pretty well except that I get some clicking when I start moving the filtergraph~ center frequency around rapidly. This doesn't happen with the official "gen~.biquad.maxpat" patch that is included with Max (and looks to be based on the Direct Form 1). 

Any ideas what's happening and how to fix it?

direct-form-2-biquad

it seems that there is something wrong in your implementation. not too much time now to check. also, remember, you are using param and thus lower control rate via message rate to the implementation which does not help. i think the direct form one msp [biquad~] object has some sort of protection against this.

a while ago i posted three forms of biquad in both gen~ and GenExpr implementations to the forum here:

perhaps that will help if you compare them. although i have not looked at the patch in a while!


Thanks for the response stkr. I have been studying your GenExpr [Bp~] and Six-Pole Butterworth filters, so thanks for those as well!

When I compare the inside of my biquad gen~ with the inside of your "Direct Form 2 as gen~ patch" I can't find any difference between the two. Cosmetically, yes, but it seems like the configuration is ultimately the same. The biggest difference seems to be the use of [param] operators versus inputs.

I didn't figure that there would be a difference between using [param] operators and using input operators because the official "gen~.biquad" example patch uses [param] and it doesn't get the clicks that I'm getting.

Stkr is exactly right: [param] only updates at 'message rate' so it is essentially driving the filter coefficients with a step function. The fact that the direct form 1 doesn't click with small parameter changes is just a lucky artefact. Adding some kind of smoothing to the filter parameters coefficients is a good idea in most cases. 

Ok this is really good to know. So by "smoothing" we're essentially talking driving the coefficients with signals being sent into the gen~… right?

Ok I think this modified version does the trick. I basically mirrored what stkr did in his patch using signals to control the coefficients. Well at least I can be satisfied that I built the overall structure of the filter correctly! Thanks for the help guys.

Would anyone like to take a look at my Direct Form I Biquad made in Codebox? It's my first foray into this and it seems like it should work but it seems like only the low pass is working. Thanks for any advice.

To make this code work you would need to swap assignments of x1, x2 and y1, y2 variables!

Direct Form 2 Biquad

I've been trying to generate ramps based on a sequence of variably spaced impulses (that is, we don't know what the spacing between the pulses is) --- but have been coming up short. I've been trying various approaches based on accumulators (e.g. [+= 1]) but the issue I run in to is the scale factor of the resulting ramps --- they're all over the place, and I'd like them to be always be a full ramp between 0 and 1. I've also tried spike~ but this doesn't really cut it due to timing issues or not always getting a full ramp.

For context, the impulse sequence is being derived from a shape~ object --- basically what I really want is a full ramp for every 'segment' in the shape~. 

Here's an example patch showing what I've tried so far:


and an image showing what I'm after (desired ramps drawn in green):




Any help would be greatly appreciated, thanks in advance!

desiredresult.png

Hi all,
I've been trying to generate ramps based on a sequence of variably spaced impulses (that is, we don't know what the spacing between ... 

impulses-to-ramps-mspgen~

I may be misunderstanding the question, but if not...

If you don't know the duration advance, you can't know how quickly to make the ramp rise. That's because, to create a ramp that hits 1.0 after a certain duration, the rate the ramp needs to rise is duration_in_samples / samplerate.  There's just no mathematical way to compute the rate of rise without knowing the duration. 

This is one of the reasons that triggers are not an ideal way of telling the passage of time. Between each trigger you know nothing about what is happening. It's mostly easy to go from ramps to triggers, but much more difficult to go from triggers to ramps. 

Fair enough, I can understand the logic, just thought there might have been a clever way of computing the durations on the fly (e.g. using a counter/accumulator). Tried to do something based on the delta times of the function feeding the shape~ but haven't had much luck on that front yet... Guess I just need to rethink my whole approach...

thought there might have been a clever way of computing the durations on the fly

if you create a set of multiple random shapes in advance all at once, then you would know their durations at that point(at least, this would work whenever the set was static or not transitioning to a new set)... and we do know the durations in advance in this case because function has the general timing in milliseconds, just need to compute that as a ratio to the total of 1000ms in order to translate into the space of phasor~ between 0 and 1, here i've almost got it but just for this set, just to explain the concept, but the floating-point inaccuracy keeps it from making a full ramp:

you could take the mathematical idea of this patch and try to work it into a fully signal realm, sorry if i couldn't figure it out completely(the inputs to selector~ here need to change when you change the function graph, and not be sig~s with a static value... and there's some additional inaccuracy with one delta~ -> abs~ that might include a drastic slope at times... but hopefully those times coincide with a reset anyways 😅), but hoping you get the idea:

use the space in milliseconds of each ramp, figure out what fraction that is of 1000ms in order to translate between 0 and 1 of your master phasor~, then use that as a multiplier to multiply the slope of your master phasor~(in order to get it to ramp faster according to the duration of each segment), and then use the tick output to reset those ramps per segment. (my wording probably confuses more, but hopefully with the patch you'll see what i'm saying, hope it helps)

Thank you so much - this helps immensely! I'm thinking I could probably use stash~ to store the ramp times from the function dynamically --- will have a play around anyway and see what I can come with! Thank you again for the help, this is pretty much what I was trying to do but just couldn't quite realise it...

Edit: Here we go - got it all 'automated'! The list processing part (to get the durations from the function into a single list) seems pretty slow but otherwise pretty happy with this I think.

Cycling '74 Forums

Finding the nearest value in buffer~ inside gen~ codebox

Noone looks at "expected results" ofcourse :p Honestly i didn't look at that, the third-outlet of your genpatch gives the correct index ...

Grain reversal codebox

Hey there, I'm trying to modify this lovely bit of code from Kengo to have the option to play the grains in reverse but can't seem to work ...

granular stretching in gen~ (issues)

I'm resurrecting this old topic as I'm trying to make a time stretch patch with an instrument input and want this to work completely inside ...

Gen~ Sinusoidal Oscillator is re-triggering for some reason

Sounds good, Raja. Thanks again!

[sharing] Digital Waveguide Mesh

snaregurdy~

Stereo all pass diffuser sample code from gen~ book

I see it used in the interpolating_glides example as a reverb

Do route/conditional operators still compute all branches?

and while you could interrupt and recompile an audio network in MSP by scripting or with the help of mute~ or poly~, afaik in gen~ it is ...

Optimizing Performance in gen~

Which performance do you want to improve, specifically? A good old way of comparing performances in Max/Jitter world uses the [timer] ...

Direct Form 2 Biquad

Hey, Dave! To make this code work you would need to swap assignments of x1, x2 and y1, y2 variables! Here is the fixed version: All the ...

Impulses to Ramps (MSP/gen~)

Thank you so much - this helps immensely! I'm thinking I could probably use stash~ to store the ramp times from the function dynamically ...