I found a simple enough poly synth patch taht uses a cloned object to achieve a poly synth from a [osc~] object. I got it working then modified it with a envelope. Now I don't know where Im going wrong the [sel 0] in ploysynthclone dose not seam to work. There always seams to be one underlying note when my external sequencer a "trigger finger pro" stops playing notes.

I should note the poly synth works inside the cloned object. This all began when I added the envelope.

This is the patch I found to handle the envelope. As you can see a clone object is not used so I feel like that is where my issue is I have a feeling this is happening because of the [next $1< message.

Also my patch is not exact to the original I am drawing the envelope line in a separate sub-patch and it is being drawn correctly.

upload-c15db8f4-c71e-48f3-b30c-5464a81f483d.pd

Hi all,

Part of my patch involves a looping sampler with envelope generator. I had it working just fine with sliders to control the points of the envelope but they were kinda clunky GUI-wise so I am trying to draw an envelope on top of the sample array using Purr Data's [draw]. This is giving me some issues:

1. I want a grid of instances of my sample abstraction, like a drumrack, and I want individual ADSR envelopes with each sample. In vanilla I could put a [namecanvas] inside the array but this doesn't seem possible anymore with Purr Data. I figured the way to go would be to put the array in a graph-on-parent subpatch, and use [namecanvas] and [draw] to draw the envelope on top of it. But the bounds rectangles do not seem to be following even though the graphs are, and I'm wondering if I need to use something like [donecanvasdialog( to hack it into shape. Image of this phenomenon attached. The first label is covered up by its symbol box as intended but the next two show up on top of it. When I make another instance on the parent parent patch, the array shows up all the way at x=0 no matter where I put the abstraction. Maybe I need to pass the (x,y) coords of each abstraction as arguments too?

2. In vanilla I could set the arguments of [drawcurve] to variables and it would automatically let me interact with those via click-dragging. I see the "drag" mouse event in the documentation for the new SVG functions, but I am used to the old way and wondering what the new way to do this is.
3. It seems like my initial attempts at using [draw] were drawing underneath whatever was already there, is there a way to make it draw on top instead?

I have put many many hours into this crazy just intonation synthesizer project, have made a ton of progress and would love to share it with you guys once I have something a little more polished, I am just trying to get this GUI a little nicer and it is giving me headache. So thanks in advance for any guidance you may be able to offer.

@planckepoch For ADSR have a look at pd/doc/3.audio.examples/D02.adsr.pd
It is in your Pd installation surrounded by a lot of useful tutorial patches.
The [adsr] is at top left and you can open it to see how it is constructed....... then just copy it into your patch.
You don't need to graph the output.

D05.envelope.pitch.pd shows how to use it for a pitch envelope.

You will probably find everything you need for your project in that documentation.
David.

Hi everyone. I have frequently revised designs for polyphonic envelopes. i've often misunderstood things about vline~ and scheduling voices in such a way to avoid unwanted clicks while also keeping things on time and snappy.

i'd be really happy to know what your methods are for envelopes.

i submit this patch, a reflection on envelope practices and how i address certain challenges. envwork.pd

this patch makes these assertions:

1- because vline~ maintains sample accuracy by scheduling events for the next block, you can switch dsp on in a subpatch with block~ while sending a message to vline~ and the dsp will be active by the start of the vline~ output. This also works if you need to configure a non-signal inlet before triggering a voice. send a message to such an inlet concurrently with a vline~ message and the parameters will update on the block boundary before the vline~ plays.

2- accounting for note stealing can cause issues in a polyphonic patch. if the stealing note has a slow attack and the envelope of the stolen note is not closed, there will be a click as the pitch of the new note jumps. the voices in my patch apply slight portamento to smooth out this click. if, however, the attack time of the stealing note is faster than this slight portamento it is counterproductive and will soften the attack of stolen notes. Stolen notes need every bit of snap they can get because the envelopes may be starting at a non-zero value. so i limit the time of the portamento to the attack time.

3- to make sure a note that is still in its release phase is treated as a stolen note, it is necessary to monitor the state of the envelopes like so:

switching the dsp off too close to the end of the release causes clicks. after testing, my system liked a full 50ms of extra delay after the end of a release before it was safe to switch off dsp. I don't think this is attributable just to the scheduling delay of vline~ but it's a small mystery to me. possibly there's a problem with my voices.

This all gets a little more complex when there are multiple envelopes per voice. The release time that affects the final output of the voice must reset all envelopes to when it is finished and before dsp is switched off. Otherwise an envelope with a long release affecting something like filter frequency can be held at a non-zero value when dsp is switched off and spoil the starting state of the vline~ on a new note.

finally, on vline~ and sample accuracy and timing, let me type out what i believe is the case. i could be wrong about this. if you programmed a synth using line~ for the envelopes, it would be faster than vline~ but not all notes equally faster. all notes would sound at the block boundary. Notes arriving shortly after the last block boundary might take 90% of the block period to sound. notes arriving just before the block boundary might take 10% of the period to sound.

vline~ will always be delayed by 100% of the block boundary. but the events will be scheduled sample-accurately, so the vline~ will trigger at exactly the real time intervals of the input. a synth with line~ envelopes will trigger any two events within a single block at the same time.

this should mean that vline~ envelopes can be accurately delay compensated and stay absolutely true to input timing, in the case of something like a Camomile plugin.

however, if one was to build a synth for something like a raspberry pi that will act as hardware, would it be better to use line~ envelopes and gain a little bit of speed? is the restriction of locking envelopes to block boundaries perceptible under normal playing conditions?! i could test some midi input and see if the notes in a chord ever achieve a timing spread greater than the block period anyway...

Hello. I'm messing about with creating envelope generators in Pd using arrays.

I've tried to make the array's settings easily changeable to allow it to work for amplitude, pitches and other uses, using variables sent to a message for the array.
But I've found that most of the time with this setup I just patched up I will, with a lack of better words, break Pd, get a bunch of error messages in the terminal and number boxes will stop showing changes, alongside dragging in values on the array.

The patch in questions and the error message is shown here:

The values shown in the picture work fine, those are set up as an amp envelope. Changing certain parameters will break it, I can't quite be sure which. Sometimes I will just get the "graph: empty bounds rectangle" message, which will usually be followed by the more verbose error message.

The changes seem to be made, but it just won't show it. I have to completely quit Pd and open it again for it to return to normal.

As soon as the error message occurs, the number boxes will freeze and add "..." to the end, as if the number shown exceeds the width of the box, which is not the case.

I assume I'm running Pd into a wall, placing values that are out of bounds for the given array, but I can't tell how and why. It's my first venture into using graphical envelopes, I've usually just used the more primitive version of line ramps and delayed signals to get regular adsr envelopes.

Can anyone tell me what I might be doing wrong here?

I'm running vanilla 0.47.1 on a Macbook Pro running El Capitan.

Thank you.

Thanks for all the suggestions about this. I'm going to keep plugging away and report back when I find the fix, though I'll probably ultimately take th8a's suggestion of using tables for the envelope segments so I can eliminate the hacky way I'm using threshold~.

I've been building in lots of print and env~ objects to try to figure out where the exact problem is. I believe I've successfully determined that it's NOT the voice stealing or the threshold~ object. All the midi info seems to be getting routed to the right voices, and the decay segment seems to be playing correctly even in notes that get stuck on, which it's the purpose of the threshold~ object to trigger.

For some reason the midi off control seems to be sent to the envelope, but it isn't registering it. I can fake another off event with messages and the envelope releases normally at that point. I've been playing around with a slightly more complex synth patch that uses the same envelope abstraction, which is actually a little more helpful because it has multiple oscillators for each voice, and they do NOT all seem to get stuck on at once. In fact, the base oscillator seems to be the only one that gets stuck on, whereas the 2 suboscillators do not, which suggest to me that I might have screwed up the construction of how the oscillator patch interacts with the envelope. But I'm still only closer to figuring it out; I haven't had much time to mess around with it lately.

I tried messing around with your patch and got good results when I
-replaced env~ with a peak envelope follower (highest~ from my library) rather than an rms one
-used 2 filters everywhere there is 1
-set the q to 10-15 in each bandpass filter
-use a line~ after the envelope follower to convert to signal that has interpolation time equal to the rate of output of the envelope follower
-use a [lop~ 10] between [line~] and [*~ ] to take the high frequencies out of the line~ signal (which has first-derivative discontinuities)
I used a block size of 64 for the envelope follower

Hi guys. I put together an adsr envelope abstraction a while ago to get the functionality I wanted where each segment of the envelope could have its own specified exponential curve. It generally works great, except that when I play glissandi in the synth patch I'm building one note appears to get stuck on every time if I play up to amount of polyphony. I assume there's something going on with the voice stealing, but I can't exactly see what or how I could fix it. Y'all have any advice? I'm attaching the whole synth patch in case it helps to look at it in context. The abstraction is adsr.pd which references expLine.pd to make the curves.

Thanks for any help you can give with this!
Little Ringy.zip

Hello!

I am trying to make an modulation envelope that works with the lop~ filter. The lop~filter uses a control inlet for the filter frequency where vcf~ and bp~ uses a signal inlet. And the envelope I have made works perfectly for the vcf~ & the bp~ but not the lop~.

I tried using snapshot~ to convert from signal to control, but the result is not good, even when I feed the snapshot~with a very fast metro to refresh it rapidly.

My patch looks like this:

The subpatch on the left side is the sequencer so you can see what signal I feed into the envelope. When I am live with the patch I can see that the envelope receives a trigger signal. So I am pretty sure the inlet/trigger part is working, so I dont think that is the issue.

On right side is the envelope that I cannot get working with the lop~ filter.

Does anyone have a suggestion to:
a. What I can do to either get the decay envelope I all ready have working in another way than using snapshot~.

b. Make a new decay envelope that uses control signal. Or maybe there is all ready one? I havent been able to find one....

Any help appreciated!

Thanks, Jaffa!

I thought about the challenge, then I thought lets try 100% vanilla, no mouse external, no canvas, one struct, one inlet, one outlet, no lateral restriction (read I have not done that yet). this where I'm up to

graph-adsr-v2-test.pd
graph-adsr-v2.pd