From the original SynthMaker forum (2004–2014), with its members’ names and dates.
MyCo ·
Hi!
OK, now after nobody give me his version for an exponential envelope, I did it myself. I don't know if it is stable under all conditions, but in my tests I haven't found any problems til now. But before I convert it into assembler, maybe here are some testers who can find something.
Or some professionals can give any optimization tipps before it is converted into "unreadable huge" assembler mess.
Hey it's a project, please help or you are not allowed to use it 😈 😈 😈
MegaHurtz ·
yust a question, is this to accheive a double exponential volume curve?
kirkagur ·
Hi
after a short test I think it works well.
but with a short decay you can see that it has steps in the curve I think its because the hop 128.
and I think its a long way to make an env (lots of code) .
I will try to make one too.... 🙂
EDIT:did you look at this one?
[old link]
MegaHurtz ·
http://en.wikipedia.org/wiki/Decibel
MyCo ·
OK, here now the optimized assembler version.
kirkagur ·
at close look its a perfect env!!!
Nice Work! 🙂
aliasant ·
Myco.
That one is pretty sweet. Finally someone made an envelope that is, as Kirk said, perfect.
There is one thing Im wondering about.
Attack 0.5, Decay 0.5 ,Sustain 0 and release 1
This way the env rises and then dies failry quick but the release stage holds the voice even though the sustain has made it 0. It doesnt output an envelope but if i play more then one notes it will just keep adding active voices until the final release stage is finished.
Heres the question.
Is it possible to mod it so that the voice is killed if output is 0? That would save a lot of voices if it is possible to do.
Heres is my mod so that you can see how I did the test.
exonerate ·
aliasant wrote: Myco.
That one is pretty sweet. Finally someone made an envelope that is, as Kirk said, perfect.
There is one thing Im wondering about.
Attack 0.5, Decay 0.5 ,Sustain 0 and release 1
This way the env rises and then dies failry quick but the release stage holds the voice even though the sustain has made it 0. It doesnt output an envelope but if i play more then one notes it will just keep adding active voices until the final release stage is finished.
Heres the question.
Is it possible to mod it so that the voice is killed if output is 0? That would save a lot of voices if it is possible to do.
Heres is my mod so that you can see how I did the test.
Fixed 😀
Also I added something extra to prevent hanging of voices, when playing very fast notes. With the env as it was before a voice could only be killed after 128 samples. You need to kill the voice at samplerate to avoid possible hangs.
I added some comments and noted where changes were made.
Cheers 😉
Exo
aliasant ·
Wow.
That really fixed the voices. SWEEEET.
Got two more questions.
1: If i eg. change the sustain level during playing nothing happens. I have to play a new note to hear the difference.
Is there no way of makeing the changes to the Sustain "live" ?
2: How do I retrigger it from eg, a sequencer ?
MyCo ·
aliasant wrote: 1: If i eg. change the sustain level during playing nothing happens. I have to play a new note to hear the difference.
Is there no way of makeing the changes to the Sustain "live" ?
I built it the way,that it samples each used input on a state trigger. eg. it sample start and end points. If you don't do that, and turn a knob when you are in the corresponding state you could hear the hop steps.
aliasant wrote: 2: How do I retrigger it from eg, a sequencer ?
Replace the "env" primitve with the "Gate" Module from the "multi stage envelope". I kept it simple as a replacement for a linear envelope, so I don't need that.
aliasant ·
Thanx Myco. I can live with the sustain.
It is one sweet envelope 🙂
MyCo ·
@Exo:
Isn't the first hop executed on the first sample? So "morethanhop" is never -1 at the end of the code?
MyCo ·
OK, here is my fix for the zero release output...
exonerate ·
MyCo wrote: @Exo:
Isn't the first hop executed on the first sample? So "morethanhop" is never -1 at the end of the code?
No Processing starts on the 128 sample, the envelopes output for the first 128 samples will be zero because this is "out"s initial value.
Cheers 😉
Exo
MyCo ·
I don't think so...
exonerate ·
MyCo wrote: I don't think so...
Ah I see. 😀
I thought it started on the 128 sample because if you look at the multi env in an analyser the first 128 samples are zeros. I figured this was because the hop started on the 128th sample.
Now I see that it is actually a bug with the multi env, the multi env needs the code I added or else voices will hang.
I don't see why the multi env doesn't start processing for 128 samples. 😕 Your envelope is very similar in design to the multi env. I'll have to look into this further.
Here's a quick osm just to show this happens with the multi env.
Any ideas why?
Cheers 😉
Exo
MyCo ·
yeah, because you ignore the "on" stage of the env primitive. In the "Finish" module replace this line:
gate = (env>1) & (env<4);
with this:
gate = (env>0) & (env<4);
exonerate ·
MyCo wrote: yeah, because you ignore the "on" stage of the env primitive. In the "Finish" module replace this line:
gate = (env>1) & (env<4);
with this:
gate = (env>0) & (env<4);
😀 Thanks that was so simple an error! 😊 .
I remember when I started working on the multi env over a year a go now. I just got it into my head that the hop started on the 128th sample. I never actually tested if this was the case, but I've thought it ever since! My eyes have been opened. hehe
Means I can remove the section = -1 stuff then. 😀
Sambean must have thought the same, because it was him who implemented the section = -1 stuff to prevent hanging voices.
Cheers 😉
Exo
stw ·
MyCo wrote: I don't think so...
😮 that was new to me as well. Never prooved that...
So the logical way to put it the other way round (if needed) is this:
MyCo ·
yeah or you could use any other value for "cmp", to delay the hop. Could be usefull when you have severall hop codes in the project, and you don't want that every hop is executed on the same sample.
stw ·
MyCo wrote: yeah or you could use any other value for "cmp", to delay the hop. Could be usefull when you have severall hop codes in the project, and you don't want that every hop is executed on the same sample.
Good idea! I always asked myself if it's clever to hop anything to the same amount which probably causes very uneven CPU usages. Still don't know if it really does but somewhere the calculations have to be done 😀
Anyway maybe it's worth to be mentioned that your suggestion only works for lower values than the hop. If you try with greater values the cmp will always stay zero because it'll never be reached.
aliasant ·
Ouch. I now have 3 almost identical envelopes.
2 from Myco and Exos.
Wich one should I use?
I tried to comapare them to eachother and they do give different results. Not much but still. Enough to confuse me... 🙂
MyCo ·
you should use the last from me or the one from exo... Both should work the same, Exos version is just a little bit overcautious.
infuzion ·
MyCo wrote: OK, here is my fix for the zero release output...
Attachments
exp_env_p8.osm
(771.91 KiB) Downloaded 14 times
Sad news: I turned down the Curve & got clicking. 🙁
Here is the exact same file as posted above. The only thing I changed was turned on the filter, & moved some knobs on the first MYCOs Envelope 20 modded. You can easily see the click at the end, caused by the value jumping up after it should have returned to 0 after the release.
I did a quick study between yours, SM1.1.3b6's Code ADSR, & SM1.1.3b6's MultiStage Envelope.
You have the killvoice flag set inside the hop(), while SM's ADSR done flag is set outside the hop. SM's MSE's finish flag is set inside the hop(), but there is a done section flag set inside stage(3), which is then processed by Section Manager Code & may trigger the finish via section==ReleaseSection.
I hope that helps you!
edit: attachment deleted; no longer needed
MyCo ·
well, I've found out that this problem only exists in the exponential and parabolic version... in the linear version everything is ok...
Ok, the reason therefor is: ratio gets higher than 1... by limiting it with min(ratio,1), there is no click anymore, but I don't know why it gets higher than 1 right now
MyCo ·
OK, here is the temporarly fixed version.
I guess the bug itself is caused by a behaviour of the S|M voice system. It looks like there is a delay between the "true" killvoice signal and S|M kills the voice. Or maybe I've looked at the totaly wrong place. If you look at the scope, you see that the release makes several steps (4-5 or so), but the realease time is actually only 2 steps. So after these 2 steps, the ratio counter goes above 1, resulting in a rising wave...
infuzion ·
MyCo wrote: OK, here is the temporarly fixed version.
I guess the bug itself is caused by a behaviour of the S|M voice system. It looks like there is a delay between the "true" killvoice signal and S|M kills the voice.
That works fine! Thanks 😇
There may be a larger delay between the killvoice flag & SM actually killing the voice, but the other SM envelopes seem to work properly. Maybe they take the delay into account? Also, your fix action seems to be the same as SM's ADSR:
SM:
val = (stage==2)&s + (stage!=2)&val;
val = min(val,1);
MyCo:
ratio = ratio+stepsize;
ratio = min(ratio,1); // TEMP FIX
For some reason, I think I found SM's bug also, something about the env output going above 1.0...
Also, the hop(128) delays the triggering it seems. If I were to decrease the hop(), I know I need to change the blockdelta line, but what else will I need to change please?
Was the inverse relationship (one curves out while the other curves in) between the Attack curve & the Decay/Release curve on purpose?
MyCo ·
Was the inverse relationship (one curves out while the other curves in) between the Attack curve & the Decay/Release curve on purpose?
Yes, that's actually how exponential envelopes look like.
If I were to decrease the hop(), I know I need to change the blockdelta line, but what else will I need to change please?
In the "hop range" modules are div 128, that you have to change, and in the code you have to change the variable "HOPDIV"
Nu Audio Science ·
Anybody ever get this to work without pops ?
No matter what i do it pops on attack of every single note
Cheers
NAS
MyCo ·
Here is a small update, that fixes a release bug. I've found out that every envelope control has an undocumented stage 5 output. This caused this exp. env. code to release longer than it should do.
For those who want to update the wiki: Stage 5 means: The voice could be killed, but only if there is no other envelope still holding the voice. For the S|M users it means: stop or reset your envelope and output a zero level.
aliasant ·
Nice one.
Maybe its time to start looking at my old synth project again..............
MichaelBenjamin ·
MyCo wrote: Stage 5 means: The voice could be killed, but only if there is no other envelope still holding the voice. For the S|M users it means: stop or reset your envelope and output a zero level.
finally you solved it. congratulations. how did you find this out?
i thought the env module was bugged and just hardclipped it at 4.
MyCo ·
you can find it, when you use 2 envelopes, both with hold=true and one with short release and the other with a very long. When you put a readout on the stage output of the one with the short release, and play a note, you'll see it directly after the release is done.
Malc confirmed it, it is not a bug, he just forgot to document it.
aliasant ·
MyCo wrote: Malc confirmed it, it is not a bug, he just forgot to document it.
LOL !
Nu Audio Science ·
Clicks when used polyphoniclly
Malc had a quick look at it but "The other envelope you have in there doesn't seem to work properly either. Unfortunately I can't tell why. It's all assembler and to get my head round what it's doing would take quite some time."
I understand his point entirely there
Anyway just thought i would let you know
NAS
MichaelBenjamin ·
can you post this osm to check?
Nu Audio Science ·
No sorry i can't i'm afraid
But Malc checked it anyway so i'm sure he is right
If not then my bad
NAS
MyCo ·
another bugfix: When you set a high decay value and played a short note, then the envelope never triggered a release state. It is fixed with 2 new assembler code lines as first step in the hop block. In the code version, it was easier to fix, it was only a wrong comparison ("less than or equal" is changed to "less than").
Twisted_Chrylle ·
Hi guys..
I had nothing else to do and thought about making this to a triggered Env from a LFo.
But it triggers when using attack and nothing else. 😕
Have I missed something or is it a bug?
Cheers
MyCo ·
actually your envelope modification is OK, but your Step-LFO Modifications is wrong, because it doesn't output a gate signal. It just sends a trigger signal (a gate which is only 1 sample long)...
Twisted_Chrylle ·
Ok ok, hmmmm...
But if I try my modified step LFo with an standard AHD in the tollbox it gets gated.
What do I have to change to make it work with your Envelope?
Sorry if this maybe get alittle offtopic but I thought if it works with the standard AHD I may work the same way with yours. 😕
Cheers
infuzion ·
I just want to thank you again MyCo for all your hard work on this. 😍
MyCo ·
Twisted_Chrylle wrote: What do I have to change to make it work with your Envelope?
Hm... I don't know, but it looks like you have to get the "fast release" output of the "env" module somehow into the code. But right now I don't know what it should do there
Twisted_Chrylle ·
Ok, thanks Myco.
A very nice job you have done with this and I'll try to make it work with a standard LFo.
(even if I at the moment dont reallt know where to start)
Cheers
Wrote something here? To have a post removed or your name hidden, write to [email protected].