MUtility little requests

[Hanz Meyzer]

Hi,

MUtility really is a great helper tool for lot of missing features in lot of DAWs. But maybe could be even improved, easily?

Some requests:

- Add positive gain until +60dB for left and right. Sometimes even such a gain maybe is required.

- Negative delay (+reporting)

- Variable Phase rotation

- Manual DC offset ( I guess its some like add in math device? )

- L / R delay separately, where the maximum value causing the reported value?

Thanks for consideration!

[MeldaProduction]

Hi there,

well, gain range cannot be changed, backwards compatibility. Latency reporting will be there. Variable phase rotation no, sorry. DC doesn't really make much sense to me to be honest. Separate L/R is again more like for a dedicated plugin, and you can do that already with 2 MUtility instances, just in case you need such a thing.

[Hanz Meyzer]

Thanks.

[mcbpete]

Would it be possible to have a tab that has calculatory things like this in it: http://musiccalculator.com/
(alternatively any chance of a MCalculator )

[MeldaProduction]

Well, I don't really like that to be honest. I mean these should be audio processing things. In case MNotepad it at least makes a little sense, since it lets you put notes to any place in the project. But calculator, that seems a little out of the scope so to speak . Better things to do I'm afraid .

[Hanz Meyzer]

I would like to add another request here:

- The delay slider without "zipper" sound on automation: A intelligent multi crossfade algorithm instead, so you wont hear any pitch change on automation.

BTW. on start on automating the delay value, there will be always a crackle.

[vectorwarrior]

The delay in MUtility is not mean to be used for that sort of purpose. It's meant to be a static delay for utilitarian purposes, for alignment etc not automating delay times. Melda has a delay effect for more creative purposes like this and I believe they may make a Turbo Delay or something in the future for more flexible delay effects, or at least that's what Vojtech's hinted at in the past... although personally I'd rather they focus on more unusual effects, but that's just me

[MeldaProduction]

Hanz, what you want is actually impossible . By changing delay time you basically cheat time and physics, so the plugin needs to do something to make that possible - and as a result, you can either have the pitch change or hardcore zipper noise. In our plugins that's always (I think) pitch change. No way around it.

[Hanz Meyzer]

Vojtech, but I have seen that already in real nature (just forgot what plugin it was). I think it is actually possible, like thinking in grain way or something. I even once found a scientific dsp paper about that.

I would think in this way:
The feedback buffer is constantly filled with dry signal + itself. Now if you change the buffer size, you could actually use a new feedback buffer for the new value. And then crossfade the buffers quickly, and destroy the oldest one. Like kind of two dimensional recursion.

The buffer size value change would required to be delayed, so the parameter change resolution is lowered. But in the end, the recent value is used.

For a punctual buffer size change it is very easy. Now create new buffers for each change, like class instances, which will destroy themselves after a while or similar. And make sure that the frequency of size change is very low.

And isn't wavetable a similar concept? Let's say the waveform was not a sample, but a dynamical signal instead.

[MeldaProduction]

I have bad news for you Hanz, I tried that long time ago . That's one of the obvious ideas, I even had a precreated crossfading system and guess what, I don't use it at all now! The problem is, that crossfading anything leads to all kinds of problems such as phasing. And there's a huge (pretty much impossible to solve) problem with continous changing of the parameter (in our case delay length).

One usually tries to invent these schematics when he finds about the problem the first time, but eventually one ends up with the sad fact, that with signal processing stuff just doesn't work this simple way and one needs to deal with the actual physics. And in this case there are 2 options:
- Resize the whole buffer - works the best imho, but causes the pitch changes. Like the magnetic tapes for instance.
- No really physical approach - cheat time by ignoring part of the buffer and trying to connect at zero crossings - that partly works if a single change occurs, but when it is continous, it just zippers as hell...

So that's it I'm afraid. One could theoretically do some hardcore mangling in spectral domain, but that usually causes yet another set of artifacts, plus latency, so... everything comes with a price .

[Hanz Meyzer]

Well, I use your utility for a multi-device XY(Z)-pad reverb setup in Renoise. And yes, I also modulate the pre-delay when modulating y-position. Now since it is zipping while changes, you can hear that, that faster the changes are. It's like a huge chorus effect, or a drunken-man-effect.

I wouldn't care here for phasing in my scenario. I would strongly believe phasing still sounds better than pitching

But did you get exactly, what I meant? I mean, maybe I did not described it too precisely.

Let's take a delay that has two feedback buffers only, which will be switched on every parameter change. This would already work for punctual parameter changes. I don't understand why here now would a phasing issue happen? Now let's assume this double-buffer case would be working (of course without any massive parameter change), wouldn't it be just enough to lower the maximum change frequency of the buffer size, to exact the time the last buffer needs to be filled? So if you are moving the buffer size slider around, it still only updates in a slow manner.

And why should here a latency happen? Don't understand that.

From musical point of view, those zipper / pitching in a delay effect only makes sense if I do some dub music. But I don't make dub music We need a perfectly clean sample delay, which is fully automate able. People maybe don't know yet, but they need it.

[MeldaProduction]

Hehe Hanz, this double-buffering of yours is classic and sadly it doesn't work. You cannot just change 2 buffers, it would zipper, a lot, not like what you experience now, like 100x more. So you'd need to crossfade and there you'd have the phasing, plus it wouldn't actually fix the zipper, just attenuate it in exchange for phasing. The less zipper, the more phasing, and vice versa. And then you have the ultimate problem I described - what if you change parameters faster than your cross-fade time (which considering that crossfade from my experience needs to be like 50ms is more than expected). Then you are just doomed .

Sorry, this is a question scientists are trying to solve for decades, and if there is a solution, then it won't be straightforward. I personally think there isn't a perfect solution. As for the latency - I mean that for spectral processing. I don't think anyone tried that yet, and it would be ugly complex, but that's something that could avoid zipper & pitch changes, well, in exchange for other artifacts as always .

[Hanz Meyzer]

Ok, I don't doubt your scientific knowledge. But maybe you still did not get / I did not explain properly the purpose for this:

Not in a delay effect, but an automatable sample delay, so delaying an audio signal 100% wet without feedback etc. In this situation it makes no sense to

- make it zipping
- frequent updates on parameter change

Also scientists often have lost the connection to a real world usage So I don't really care what they say, if they are no audiophiles at the same time. Lot of scientists even can not drive a car.

Also your current delay in MUtility crackles AT THE BEGINNING and is not really automatable. Imho this is a bug.
And also I talked about double buffering only as simplified example, but actually meant n-times-buffering.
And who cares for phasing for the period of the buffer size change? Don't geddit...

[MeldaProduction]

Hanz, could you post an example of what MUtility does? It seems working fine here.

As for the rest of it I'm afraid I just don't know what to say, I probably don't understand it . I already explained all methods I'm aware of with their pros and cons, you just somehow disagree, sorry, no time to repeat again or something.

[Hanz Meyzer]

Heh ok No problem, and sorry for being so stubborn.

Regarding the "crackle at beginning":

I just plugin any synth sound (also the audibility seems to depend on the type of sound), add the mutility and then live move around the samples delay knob of the delay section. Then I hear quite a bunch of crackles, esp. if the delay values are small. The crackle seems to appear only at the beginning of a movement.

If I now automate the sample delay (and make sure that the automation is a line, not only points), I can totally clearly hear a single click at the first point where the automation starts / the first change appears.

Below is a renoise song example. How to open:

1. Since your plugins use ".bin" in the binary only on OSX, you only can open this song in Renoise OSX only. But you can patch the song.xml if you want to load it into Renoise Windows:
1a. Rename .xrns into .zip. Unpack. Open song.xml in a text editor, search for ".bin" and remove it. Save song.xml. Pack the whole without outer dir, rename to .xrns again.

2. In the song, expand mutility parameters (left next to "Ext. Editor"), find "Delay Samples" and click the highlighted automation icon right next to the slider. Now you see exactly, where the automation starts.

3. You can open the FFT analyzer/spectrum pane above. You will see that at the crackle, there will be noise out of the range of the instrument.