MuLab 6.5.29 released
- KVRAF
- Topic Starter
- 13867 posts since 24 Jun, 2008 from Europe
- KVRAF
- 3162 posts since 28 Mar, 2008 from a Galaxy S7 far far away
- KVRAF
- Topic Starter
- 13867 posts since 24 Jun, 2008 from Europe
- KVRAF
- 3207 posts since 17 Apr, 2010 from Slovenia
Yeah, I think so, too. Certain things would naturally happen, if you designed it that way and it would be too much to ask for MUX to kind of go "fool proof", hehe, so to say.
Why is 0 attack bad: Because of the way sound works! On a computer it's much more harsh than in reality, of course, because digital signals can jump from 0 to 100 instantly. While in the analogue world things would have to rise, no matter how fast it is set, there always will be in between values between 0 and 100.
Now, imagine a digital waveform being expressed via your speakers membranes:
The speakers membrane actually is controlled by digital values, your sample! This speaker acts stunningly fast, though. That means, if your sample value goes from 0 to 100 in the very next step, the speaker membrane will snap from its 0 position to its 100 position instantly, creating a click, as the resonance of the membrane vibrates out that massive kick you just gave it. It's quite high pitch, because you just hear those tiny vibrations of the rest of the membrane. That's why ideally your waveform always starts from 0 and ends on 0, unless you want square or saw waves, for example, but that's where they get their high frequencies from, you see?
Why is 0 attack bad: Because of the way sound works! On a computer it's much more harsh than in reality, of course, because digital signals can jump from 0 to 100 instantly. While in the analogue world things would have to rise, no matter how fast it is set, there always will be in between values between 0 and 100.
Now, imagine a digital waveform being expressed via your speakers membranes:
The speakers membrane actually is controlled by digital values, your sample! This speaker acts stunningly fast, though. That means, if your sample value goes from 0 to 100 in the very next step, the speaker membrane will snap from its 0 position to its 100 position instantly, creating a click, as the resonance of the membrane vibrates out that massive kick you just gave it. It's quite high pitch, because you just hear those tiny vibrations of the rest of the membrane. That's why ideally your waveform always starts from 0 and ends on 0, unless you want square or saw waves, for example, but that's where they get their high frequencies from, you see?
-
- KVRian
- 855 posts since 3 Mar, 2009
Sorry if i created misunderstandings.
Sure you should use Attack=0, there is just the possibility for clicks. And who am i to say that clicks are a bad thing.
So, next time i'll put any potential sarcasm in quotes
Sure you should use Attack=0, there is just the possibility for clicks. And who am i to say that clicks are a bad thing.
So, next time i'll put any potential sarcasm in quotes
- KVRian
- 1451 posts since 4 Oct, 2012 from Utah
AndreasD wrote:Sorry if i created misunderstandings.
Sure you should use Attack=0, there is just the possibility for clicks. And who am i to say that clicks are a bad thing.
So, next time i'll put any potential sarcasm in quotes
Software portfolio
M.N.I.E - soon to be my musical portfolio
Hey, I'm Eurydice(Izzy for short) - she/her
M.N.I.E - soon to be my musical portfolio
Hey, I'm Eurydice(Izzy for short) - she/her
- KVRAF
- Topic Starter
- 13867 posts since 24 Jun, 2008 from Europe
New MuLab 6.5.19 test version in http://www.mutools.com/forsythia
Latest changes:
OSX: Simply replace the MuLab.app by the new version.
Windows: Simply replace the MuLab.exe + MuLab.ID files by the new versions.
How to upgrade from earlier versions eg M6.4: Make a full new install from the M6.5.7 package cfr the info on
http://www.mutools.com/info/docs/mulab/ ... ation.html
Then apply the new M6.5.8 app patch.
Latest changes:
- Added 3 extra fine beat grids: 1/256th, 1/512th, 1/1024th. At 120.0 BPM the most fine grid (1/1024th) corresponds to 1.95 ms per grid point.
- Multi-Point Envelope editor window now is resizable, and can be zoomed in more so to comfortably make very precise edits.
- Optimized the horizontal overview function for envelopes. (previously the result could be much too wide in case of short envelopes)
OSX: Simply replace the MuLab.app by the new version.
Windows: Simply replace the MuLab.exe + MuLab.ID files by the new versions.
How to upgrade from earlier versions eg M6.4: Make a full new install from the M6.5.7 package cfr the info on
http://www.mutools.com/info/docs/mulab/ ... ation.html
Then apply the new M6.5.8 app patch.
- KVRAF
- Topic Starter
- 13867 posts since 24 Jun, 2008 from Europe
Ok, i had a detailed look at Dakkra's / Taron's patch. Bottomline is that, for performance reasons, the modulation system is making a little compromise: While effectively rendering the envelopes that you draw, the curves are translated into short linear lines. How 'short' these lies are depends on your audio engine buffer size. The smaller the buffer size, the more accurate the envelope can be rendered. For example: If a certain envelope segment is 500 ms long, and your buffer size is 10 ms, then that specific segment is rendered as 50 straight lines which will be quite accurate in almost all practical cases.
Now in this case you're using a very short envelope segment of about 14.6 ms (1/128th grid on 128 BPM) using a very non-linear curve so to do a little fade-in for the gating effect. Using a common audio engine buffer size of about 10 ms (512 samples on 44.1 kHz) this means that this short unlinear envelope segment can only be very roughly rendered using 1 or 2 lines. And that's why several of the gates sound with a softer attack as intended. So the 'clicks' are correct (Andreas is right, the curves are still to steep to prevent clicks), the non-clicks are the result of the performance compromise. Solution is to finetune the gate envelope pattern and make these attack segments linear. Now as a linear fade-in of 14.6 ms is too soft (we lose the solid attack feel) it's better to use a smaller fade-in time of say 2-3 ms. That prevents clicks, but still gives a solid attack feel.
For tempo-synced envelopes the smallest beat grid is 1/128th which corresponds to 15.6 ms at 120 BPM. In the next version i've added 3 extra fine grids of 1/256th, 1/512th and 1/1024th. At 120.0 BPM that most fine grid (1/1024th) corresponds to 1.95 ms per grid point. That's quite fine to create/edit a perfect gate envelope pattern.
Ideally the modulation system would work on audio rate, but that would take more CPU, so that's why there is a little compromise that works well in most cases, but it can give some artifacts when using very unlinear curves on very short time intervals / high frequency loops. Note however that the modulation system always perfectly renders every envelope point you've created, without any compromise. And linear curves are also always perfectly rendered. So with this background info you can create even more accurate envelope patterns.
Will post an example soon unlss someone beats me in time cause i'm on for a beer now.
Now in this case you're using a very short envelope segment of about 14.6 ms (1/128th grid on 128 BPM) using a very non-linear curve so to do a little fade-in for the gating effect. Using a common audio engine buffer size of about 10 ms (512 samples on 44.1 kHz) this means that this short unlinear envelope segment can only be very roughly rendered using 1 or 2 lines. And that's why several of the gates sound with a softer attack as intended. So the 'clicks' are correct (Andreas is right, the curves are still to steep to prevent clicks), the non-clicks are the result of the performance compromise. Solution is to finetune the gate envelope pattern and make these attack segments linear. Now as a linear fade-in of 14.6 ms is too soft (we lose the solid attack feel) it's better to use a smaller fade-in time of say 2-3 ms. That prevents clicks, but still gives a solid attack feel.
For tempo-synced envelopes the smallest beat grid is 1/128th which corresponds to 15.6 ms at 120 BPM. In the next version i've added 3 extra fine grids of 1/256th, 1/512th and 1/1024th. At 120.0 BPM that most fine grid (1/1024th) corresponds to 1.95 ms per grid point. That's quite fine to create/edit a perfect gate envelope pattern.
Ideally the modulation system would work on audio rate, but that would take more CPU, so that's why there is a little compromise that works well in most cases, but it can give some artifacts when using very unlinear curves on very short time intervals / high frequency loops. Note however that the modulation system always perfectly renders every envelope point you've created, without any compromise. And linear curves are also always perfectly rendered. So with this background info you can create even more accurate envelope patterns.
Will post an example soon unlss someone beats me in time cause i'm on for a beer now.
- KVRAF
- 3207 posts since 17 Apr, 2010 from Slovenia
Sweet, I'm very happy about the improved zoom depth! That troubled me a little before.

...soooo, AndreasD is right, but I wasn't helpful in pinpointing immediately and accurately that the gate caused the trouble.
...you make it sound like I was "wrong", pffff. 
Why make me feel sorry to help?
I'm just wondering about that every now and then. But I wonder even more why I still bother.
Guess I'll just take that as a "Thanks, Taron!".
...soooo, AndreasD is right, but I wasn't helpful in pinpointing immediately and accurately that the gate caused the trouble.
Why make me feel sorry to help?
I'm just wondering about that every now and then. But I wonder even more why I still bother.
Guess I'll just take that as a "Thanks, Taron!".
- KVRAF
- Topic Starter
- 13867 posts since 24 Jun, 2008 from Europe
Huh?? Which words gave you that impression??Taron wrote:...soooo, AndreasD is right, but I wasn't helpful in pinpointing immediately and accurately that the gate caused the trouble. you make it sound like I was "wrong", pffff.
Didn't i thank you for isolating the clicks and feedback?Why make me feel sorry to help?
Yes i did: http://www.kvraudio.com/forum/viewtopic ... 0#p6171480
No prob to thank you again: Thanks Taron!
- KVRAF
- 3207 posts since 17 Apr, 2010 from Slovenia
- KVRian
- 1451 posts since 4 Oct, 2012 from Utah
Thanks for the explanation Jo! Makes perfect sense. Thanks for the update too! 
I fall in love with Mulab more and more each update!
Dakkra
EDIT: a little heads up that you have M6.5.18 posted twice in the changelog
I fall in love with Mulab more and more each update!
Dakkra
EDIT: a little heads up that you have M6.5.18 posted twice in the changelog
Software portfolio
M.N.I.E - soon to be my musical portfolio
Hey, I'm Eurydice(Izzy for short) - she/her
M.N.I.E - soon to be my musical portfolio
Hey, I'm Eurydice(Izzy for short) - she/her
- KVRAF
- Topic Starter
- 13867 posts since 24 Jun, 2008 from Europe
Ah i see, will be corrected on next upload. Thx.dakkra wrote:EDIT: a little heads up that you have M6.5.18 posted twice in the changelog
- KVRAF
- Topic Starter
- 13867 posts since 24 Jun, 2008 from Europe
Attached a MUX patch that demonstrates that typical trance stutter gate. Go into the deep editor and open the multi-point envelope, there you'll see that i used a 1/1024th grid with only 1 grid length to do the attacks, using a linear line. At 128 BPM that's an gating attack of 1.8 ms, that sounds fine.
NB: Note that you can go for even shorter attacks if you want, then just edit the point time in detail at the bottom left or double-click a point. MuLab uses 12000 ticks per beat, so for example if you set an attack time of 26 ticks that corresponds to +-1 ms at 128 BPM.
NB: Note that you can go for even shorter attacks if you want, then just edit the point time in detail at the bottom left or double-click a point. MuLab uses 12000 ticks per beat, so for example if you set an attack time of 26 ticks that corresponds to +-1 ms at 128 BPM.
You do not have the required permissions to view the files attached to this post.
