## Re: [LMMS-devel] Expected envelope behavior

 Re: [LMMS-devel] Expected envelope behavior From: Jason Wuertz - 2013-05-14 02:03:21 Attachments: Message as HTML ```So if the knobs are now time based should there maybe be a selection for how long the intervals are? Similar to the controls of an LFO, where you have 1, x100, 1/100, buttons on the side. Also are these taking the bpm into account? If the knobs don't calculate in seconds this is all irrelevant and should be ignored :3 I'm just skimming through the thread and these are some things that came to mind. Regards, Jason Paul Giblock wrote: >On Mon, May 13, 2013 at 5:55 PM, John Serafino >wrote: > >> Looks good if I understand it. I'm a little unclear on a couple of >things >> though: >> >> 1. Order of operations is not 100% clear. Are we doing >> parenthesis->multiplication(and division)->addition, or something >else? I >> usually just use a million parenthesis. ;) >> > >Yeah, standard order of operations: parenthesis, exponentiation, >multiplication, division, addition, subtraction. It may seem odd that >the >resonance and cutoff knob values are not multiplied by the 2.0 or >6000.0 >scale factor, but that is because the knob value is already in the >appropriate unit (Q or Hz). Perhaps that scale factor can be removed if >we >push the units to the GUI. But, I honestly think that might just >confuse >the user more since the ultimate cutoff would be a function of the >knob, >the envelope, and the lfo. > > >> 2. X squared keeping the original sign is not (|x| + x). I'm just >> assuming that (x^2) means x squared keeping original sign, and not... >that >> other thing. >> >Ooops, Typeo: it should be |x| * x, where |x| is the absolute value of >x. >Or, in other words: > >-x * x, if x < 0 >x * x, otherwise > >Thanks for the feedback! Also, I apologize to everyone else if this >thread >is off topic. I was hoping it may help shed some light on the internal >working of the current LMMS filters as well. > >-- Paul > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ >AlienVault Unified Security Management (USM) platform delivers complete >security visibility with the essential security capabilities. Easily >and >efficiently configure, manage, and operate all of your security >controls >from a single console and one unified framework. Download a free trial. >http://p.sf.net/sfu/alienvault_d2d > >------------------------------------------------------------------------ > >_______________________________________________ >LMMS-devel mailing list >LMMS-devel@... >https://lists.sourceforge.net/lists/listinfo/lmms-devel -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.```

 [LMMS-devel] Expected envelope behavior From: Paul Giblock - 2013-05-11 17:48:39 Attachments: Message as HTML ```Tobias, and anyone else who cares to weigh in on this: As you may know, I'm working on porting the LMMS instruments to LV2 for use in other hosts (https://github.com/pgiblox/lmms-lv2). I have some time to finish this project over the next few weeks as I just completed my course work for school. I break compatibility where needed in order to gain better quality (antialiased oscillators, etc.) Anyway, I'm at the point where I need to either maintain or reject compatibility on a few fronts. The latest issue is envelope modulation. The current behavior surprises me, even after reading the source code. For example, here is a graph from Audacity when playing the same triple oscillator preset with the Volume Envelope Amount = {1.0, 0.5, -0.5, and -1.0} in that order: http://www.pgiblock.net/lmms/env_1_0.5_-0.5_-1.png Source file: http://www.pgiblock.net/lmms/env_1_0.5_-0.5_-1.mmpz The first curve (amt=1.0) is as I would expect. The LMMS source code seems to state that the volume envelope (as opposed to cut or reso envelopes) works as a "mix". That is, the volume is always 100% if the envelope is disabled, or the envelope has full-effect if the amount is 1.0. Thus, I would expect, at 0.5, that the volume starts at 0.5, ramps up to 1.0 during attack, then releases to 0.5. However, we see that the volume starts at less than 0.5, and is over 1.0 during the hold. Then the exciting part: The volume instantly decreases from the sustain level to a much smaller level at the beginning of the release. The negative modulations are strange too: what is going on with the release? I'd expect the volume to increase. There is the discontinuity between sustain and release here too. So, my question to LMMS users: Does this behavior seem intuitive? I don't believe it is. What behavior would YOU expect? Finally, Toby: does this experiment properly illustrate the intended effect? Much thanks, Paul P.S: now that most of the scaffolding is done for this project, I will quickly add other plugins. Please watch the github site for updates if you are interested in this, as I could use some beta testers. ```
 Re: [LMMS-devel] Expected envelope behavior From: John Serafino - 2013-05-11 18:27:03 Attachments: Message as HTML ```I try to avoid LMMS's native envelopes for this reason. They do not seem at all intuitive, nor do they mirror any other envelopes I've used thus far. I would expect amt knob to do anything consistent that makes sense. I would expect attack to effect how long the envelope to to reach the instrument volume, which it would stay on for the length of hold. Then I would expect it to take decay amount of time to move to sustain, finally taking release amount of time to drop to zero. Again, this is merely what I would expect. I can work with envelopes that work different ways, especially if they have an accurate visualization. I just couldn't figure LMMS's out before giving up. ```
 Re: [LMMS-devel] Expected envelope behavior From: Paul Giblock - 2013-05-11 19:00:19 Attachments: Message as HTML ```Alright, it seems like your and my intuition agree to some extent. Here is what I'm considering: Any "time" based controls will remapped from [0..1] to an actual duration in seconds, for instance [0sec..5sec]. It also seems like the sustain knob is backwards in LMMS. Next, is dealing with the Amount (AMT) knob. I agree with LMMS that the AMT knob for volume envelope should control a mix between the envelope and 100% gate. The user can use the channel's volume control if they wish to change the maximum volume. That leaves us with this fomula volume = envelope_level * amt + (1-amt), if amt >= 0 volume = envelope_level * amt + 1, otherwise ... or something like that. The case for cutoff and resonance filters will be slightly different. I haven't decided exactly how, yet :) -- Paul On Sat, May 11, 2013 at 2:26 PM, John Serafino wrote: > I try to avoid LMMS's native envelopes for this reason. They do not seem > at all intuitive, nor do they mirror any other envelopes I've used thus > far. I would expect amt knob to do anything consistent that makes sense. I > would expect attack to effect how long the envelope to to reach the > instrument volume, which it would stay on for the length of hold. Then I > would expect it to take decay amount of time to move to sustain, finally > taking release amount of time to drop to zero. > > Again, this is merely what I would expect. I can work with envelopes that > work different ways, especially if they have an accurate visualization. I > just couldn't figure LMMS's out before giving up. > ```
 Re: [LMMS-devel] Expected envelope behavior From: Paul Giblock - 2013-05-13 20:48:43 Attachments: Message as HTML ```For anyone interested, here is how I decided to resolve this for the lmms-lv2 port: All three envelopes (vol, cut, res) behave the same: attack controls how long the envelope takes to reach 100% value, where it says for the length of hold (or until the note is released). The sustain amount is now a percentage of the maximum value instead of (1-max) as in LMMS. Thus, decay is how long it takes to reach the sustain level. Finally, release is how long it takes for the envelope to reach zero from the current value -- regardless of the current state of the envelope. This provides a continuous function, and is in-line with all the descriptions of an AHDSR envelope that I've read. Note, channel (instrument) volume is not a factor here, that is performed AFTER mixing all the instrument's notes together. The big mystery in LMMS is how this envelope level (assume the output is between 0 and 1) maps to instrument parameters. For this, we let amt be the modulation amount (between -1 and 1). lfo_volume is the value of the volume LFO (between -1 and 1). Also, I use (x^2) as a shorthand for (|x| + x), that is: x squared, while maintaining the original sign. envelope_volume = envelope_level * amt + (1-amt), if amt >= 0 envelope_volume = envelope_level * amt + 1, otherwise volume = (envelope_volume * lfo_volume)^2, if lfo_modulate_env volume = (envelope_volume + lfo_volume)^2, otherwise LMMS, thus maps the envelope value to a velocity quadratically instead of linear or exponentially. Perhaps due to the perceived volume difference? Also, the volume envelope "Amount" knob is the ratio of enveloped to non-enveloped signal -- not the maximum volume. This seems fine to me, although I might adjust the quadratic mapping to something more musical such as dB? The cutoff and resonance envelopes do not perform the same "mixing" operation. Thus, the amt value is actually the magnitude of the envelope: envelope_cut = envelope_level * amt cut = knob_cut + (envelope_cut * lfo_cut)^2 * 6000.0, if lfo_modulate_env cut = knob_cut + (envelope_cut + lfo_cut)^2 * 6000.0, otherwise The resonance envelope and LFO behave the same as the cutoff, but is scaled to 2.0 instead of 6000.0. I personally feel this whole system is adequate and fairly straight-forward. However, I will try to replace as many of these magic [0..1] or [-1..1] parameters with proper values and units. Seconds for attack, hold, decay, release. Percentage for sustain. Perhaps dB for volume amount and Hz for cutoff -- although that may not be possible due to the dynamic nature of those two knobs. -- Paul ```
 Re: [LMMS-devel] Expected envelope behavior From: Raine M. Ekman - 2013-05-14 07:19:44 ```Quoting Paul Giblock : > The big mystery in LMMS is how this envelope level (assume the output is > between 0 and 1) maps to instrument parameters. For this, we let amt be the > modulation amount (between -1 and 1). lfo_volume is the value of the volume > LFO (between -1 and 1). Also, I use (x^2) as a shorthand for (|x| + x), > that is: x squared, while maintaining the original sign. > > envelope_volume = envelope_level * amt + (1-amt), if amt >= 0 > envelope_volume = envelope_level * amt + 1, otherwise So, negative amt gives an inverted envelope going from 1 -> 0 -> sustain -> 1. Makes sense. > volume = (envelope_volume * lfo_volume)^2, if lfo_modulate_env > volume = (envelope_volume + lfo_volume)^2, otherwise ((envelope_volume + lfo_volume) / 2)^2 would be a more intuitive mix, if one likes to keep the level between -1 and 1. Typo? > Also, the volume envelope "Amount" knob is the ratio of enveloped to > non-enveloped signal -- not the maximum volume. This seems fine to me, > although I might adjust the quadratic mapping to something more musical > such as dB? The cutoff and resonance envelopes do not perform the same > "mixing" operation. Thus, the amt value is actually the magnitude of the > envelope: > > envelope_cut = envelope_level * amt > > cut = knob_cut + (envelope_cut * lfo_cut)^2 * 6000.0, if lfo_modulate_env > cut = knob_cut + (envelope_cut + lfo_cut)^2 * 6000.0, otherwise > > The resonance envelope and LFO behave the same as the cutoff, but is scaled > to 2.0 instead of 6000.0. I personally feel this whole system is adequate > and fairly straight-forward. However, I will try to replace as many of > these magic [0..1] or [-1..1] parameters with proper values and units. > Seconds for attack, hold, decay, release. Percentage for sustain. Perhaps > dB for volume amount and Hz for cutoff -- although that may not be possible > due to the dynamic nature of those two knobs. Cutoff in Hz with envelope and LFO amounts in octaves (say, -2 to 2) would of course make sense musically: cut = knob_cut * 2^( envelope_cut * lfo_cut ) // lfo_modulate_env == true cut = knob_cut * 2^( envelope_cut + lfo_cut ) -- raine@... http://www.mikseri.net/radioproject ```
 Re: [LMMS-devel] Expected envelope behavior From: John Serafino - 2013-05-13 21:56:12 Attachments: Message as HTML ```Looks good if I understand it. I'm a little unclear on a couple of things though: 1. Order of operations is not 100% clear. Are we doing parenthesis->multiplication(and division)->addition, or something else? I usually just use a million parenthesis. ;) 2. X squared keeping the original sign is not (|x| + x). I'm just assuming that (x^2) means x squared keeping original sign, and not... that other thing. On Mon, May 13, 2013 at 3:48 PM, Paul Giblock wrote: > For anyone interested, here is how I decided to resolve this for the > lmms-lv2 port: > > All three envelopes (vol, cut, res) behave the same: attack controls how > long the envelope takes to reach 100% value, where it says for the length > of hold (or until the note is released). The sustain amount is now a > percentage of the maximum value instead of (1-max) as in LMMS. Thus, decay > is how long it takes to reach the sustain level. Finally, release is how > long it takes for the envelope to reach zero from the current value -- > regardless of the current state of the envelope. This provides a continuous > function, and is in-line with all the descriptions of an AHDSR envelope > that I've read. Note, channel (instrument) volume is not a factor here, > that is performed AFTER mixing all the instrument's notes together. > > The big mystery in LMMS is how this envelope level (assume the output is > between 0 and 1) maps to instrument parameters. For this, we let amt be the > modulation amount (between -1 and 1). lfo_volume is the value of the volume > LFO (between -1 and 1). Also, I use (x^2) as a shorthand for (|x| + x), > that is: x squared, while maintaining the original sign. > > envelope_volume = envelope_level * amt + (1-amt), if amt >= 0 > envelope_volume = envelope_level * amt + 1, otherwise > > volume = (envelope_volume * lfo_volume)^2, if lfo_modulate_env > volume = (envelope_volume + lfo_volume)^2, otherwise > > LMMS, thus maps the envelope value to a velocity quadratically instead of > linear or exponentially. Perhaps due to the perceived volume difference? > Also, the volume envelope "Amount" knob is the ratio of enveloped to > non-enveloped signal -- not the maximum volume. This seems fine to me, > although I might adjust the quadratic mapping to something more musical > such as dB? The cutoff and resonance envelopes do not perform the same > "mixing" operation. Thus, the amt value is actually the magnitude of the > envelope: > > envelope_cut = envelope_level * amt > > cut = knob_cut + (envelope_cut * lfo_cut)^2 * 6000.0, if lfo_modulate_env > cut = knob_cut + (envelope_cut + lfo_cut)^2 * 6000.0, otherwise > > The resonance envelope and LFO behave the same as the cutoff, but is > scaled to 2.0 instead of 6000.0. I personally feel this whole system is > adequate and fairly straight-forward. However, I will try to replace as > many of these magic [0..1] or [-1..1] parameters with proper values and > units. Seconds for attack, hold, decay, release. Percentage for sustain. > Perhaps dB for volume amount and Hz for cutoff -- although that may not be > possible due to the dynamic nature of those two knobs. > > -- Paul > > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > LMMS-devel mailing list > LMMS-devel@... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > > -- Johnny ```
 Re: [LMMS-devel] Expected envelope behavior From: Paul Giblock - 2013-05-14 01:02:24 Attachments: Message as HTML ```On Mon, May 13, 2013 at 5:55 PM, John Serafino wrote: > Looks good if I understand it. I'm a little unclear on a couple of things > though: > > 1. Order of operations is not 100% clear. Are we doing > parenthesis->multiplication(and division)->addition, or something else? I > usually just use a million parenthesis. ;) > Yeah, standard order of operations: parenthesis, exponentiation, multiplication, division, addition, subtraction. It may seem odd that the resonance and cutoff knob values are not multiplied by the 2.0 or 6000.0 scale factor, but that is because the knob value is already in the appropriate unit (Q or Hz). Perhaps that scale factor can be removed if we push the units to the GUI. But, I honestly think that might just confuse the user more since the ultimate cutoff would be a function of the knob, the envelope, and the lfo. > 2. X squared keeping the original sign is not (|x| + x). I'm just > assuming that (x^2) means x squared keeping original sign, and not... that > other thing. > Ooops, Typeo: it should be |x| * x, where |x| is the absolute value of x. Or, in other words: -x * x, if x < 0 x * x, otherwise Thanks for the feedback! Also, I apologize to everyone else if this thread is off topic. I was hoping it may help shed some light on the internal working of the current LMMS filters as well. -- Paul ```
 Re: [LMMS-devel] Expected envelope behavior From: Jason Wuertz - 2013-05-14 02:03:21 Attachments: Message as HTML ```So if the knobs are now time based should there maybe be a selection for how long the intervals are? Similar to the controls of an LFO, where you have 1, x100, 1/100, buttons on the side. Also are these taking the bpm into account? If the knobs don't calculate in seconds this is all irrelevant and should be ignored :3 I'm just skimming through the thread and these are some things that came to mind. Regards, Jason Paul Giblock wrote: >On Mon, May 13, 2013 at 5:55 PM, John Serafino >wrote: > >> Looks good if I understand it. I'm a little unclear on a couple of >things >> though: >> >> 1. Order of operations is not 100% clear. Are we doing >> parenthesis->multiplication(and division)->addition, or something >else? I >> usually just use a million parenthesis. ;) >> > >Yeah, standard order of operations: parenthesis, exponentiation, >multiplication, division, addition, subtraction. It may seem odd that >the >resonance and cutoff knob values are not multiplied by the 2.0 or >6000.0 >scale factor, but that is because the knob value is already in the >appropriate unit (Q or Hz). Perhaps that scale factor can be removed if >we >push the units to the GUI. But, I honestly think that might just >confuse >the user more since the ultimate cutoff would be a function of the >knob, >the envelope, and the lfo. > > >> 2. X squared keeping the original sign is not (|x| + x). I'm just >> assuming that (x^2) means x squared keeping original sign, and not... >that >> other thing. >> >Ooops, Typeo: it should be |x| * x, where |x| is the absolute value of >x. >Or, in other words: > >-x * x, if x < 0 >x * x, otherwise > >Thanks for the feedback! Also, I apologize to everyone else if this >thread >is off topic. I was hoping it may help shed some light on the internal >working of the current LMMS filters as well. > >-- Paul > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ >AlienVault Unified Security Management (USM) platform delivers complete >security visibility with the essential security capabilities. Easily >and >efficiently configure, manage, and operate all of your security >controls >from a single console and one unified framework. Download a free trial. >http://p.sf.net/sfu/alienvault_d2d > >------------------------------------------------------------------------ > >_______________________________________________ >LMMS-devel mailing list >LMMS-devel@... >https://lists.sourceforge.net/lists/listinfo/lmms-devel -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.```
 Re: [LMMS-devel] Expected envelope behavior From: Paul Giblock - 2013-05-14 02:24:47 Attachments: Message as HTML ```On Mon, May 13, 2013 at 9:24 PM, Jason Wuertz wrote: > So if the knobs are now time based should there maybe be a selection for > how long the intervals are? Similar to the controls of an LFO, where you > have 1, x100, 1/100, buttons on the side. > That is a good point, and is another reason why I don't want to use an arbitrary interval such as [0..1] and instead a concrete value such as seconds or milliseconds. LMMS considers the x100 button as part of the model, but really, to me: this is a presentation issue. The model (the actual envelope and LFO implementation) should just take a value in seconds and roll with it. The x100 selector is really just a convenience to make the knob's accuracy more closely represent the range that the user wishes to work in. So really, the maximum time of an envelope segment, or the period of an LFO need not be limited, (except maybe the lower bound by the nyquist frequency). Perhaps a more intelligent knob widget could allow the user to right click and specify the range they wish to tweak. Any thoughts on an appropriate human interface? > Also are these taking the bpm into account? > Nope. The "tempo-sync" feature allows the user to specify a value in beats, but this is ultimately converted to seconds before reaching the area of code that I am currently discussing. I don't even want to think about tempo-sync at this point. I may have to rely on midi-beat-clock or an additional LV2 extension to support this. Definitely a version 2.0 thing. -- Paul ```