Moving parameters while playing

malc · 9 Feb 2005

Hi clang,

Welcome to the forum.

You're dead right and this is a known problem which has been refered to as 'zipper noise'. We should finally get round to fixing this soon.

In the meantime the following thread may be of some interest to you: LPF on float/ineger signals?

lalo · 9 Feb 2005

this is one of my favourite topics 🙂

i'm reconsidering my position of an 'internal' (hidden in SM framework and audio engine code) smoothing and de-zippering thing.. i'm now most in a way of a module to do that as most efficient as possible in terms of cpu...maybe just a code component algo with a good interpolation formula...i don't really know if this would be more heavy on cpu than an 'hardwired' solution.. so one can choose the right interpolation for every situation and then just incorporate those in the schematics... the only question is all about the relationship between GUI controls, exported VST/i automatable parameters, and eventually Midi CC in the schematic.. feel free to continue this thread if my statement seems confusing... as it is i guess 😀

lalo

clang · 9 Feb 2005

malc: 😀 I'm happy the 'zipper noise' fix is on the list! I'll wait patiently. lalo: yes! your statement is a bit confusing! 😀 But consider I know nothing about DSP (I'll learn!), so I think others would understand better! If you find any solution, let us know!

clang

malc · 9 Feb 2005

Hi clang,

Forgive me if I'm telling you something you don't already know. The noise is caused by sudden changes in the signal from one value to another as you turn a knob or move a slider. The transitions need to be smoothed out in order to avoid the blips and crackles.

Hi lalo,

Yes, I know this is an issue close to your heart 😉

I think what you're saying is that you prefer to have a module that does the smoothing over a solution that would be automatically applied to any transition that might take place.

It's always been our philosophy to allow you to have absolute control in SynthMaker. I know Jorge has a particular solution in mind, I just can't remember exactly what it is 🙂. But I'm sure it will give you the flexibility to decide how and whether the smoothing is performed without making it a chore.

lalo · 9 Feb 2005

clang wrote: malc: 😀 I'm happy the 'zipper noise' fix is on the list! I'll wait patiently. lalo: yes! your statement is a bit confusing! 😀 But consider I know nothing about DSP (I'll learn!), so I think others would understand better! If you find any solution, let us know!

clang

hi clang! sorry for my mess 😀 ..i'd have to see my schematics...or my studio/bedroom...they are more a mess too 🙂

i was talkin' about doing an 'internal' solution of the 'zipper-noise' (a solution coded inside the SM .exe) or a 'modular' solution... a module that can just smooth signals in a easy and cpu-light way..

i'd prefer the second 🙂

hope i've been clearer this time 🙂

lalo

clang · 9 Feb 2005

Yes, you and malc made it clear. I prefer the 'internal' solution! 🙂 I understand your point about cpu load, but the cons of having a dedicated module is the cluttering of the schematic. As malc said, I hope we'll have a flexible solution: light for the cpu and light for the view 😉 Maybe the 'internal' should be the default (make it simple for newbies!). Btw, I've no experience, so I probably missing something, but is there any case which the 'internal' smoothing isn't required?

clang

lalo · 9 Feb 2005

clang wrote: Yes, you and malc made it clear. I prefer the 'internal' solution! 🙂 I understand your point about cpu load, but the cons of having a dedicated module is the cluttering of the schematic. As malc said, I hope we'll have a flexible solution: light for the cpu and light for the view 😉 Maybe the 'internal' should be the default (make it simple for newbies!). Btw, I've no experience, so I probably missing something, but is there any case which the 'internal' smoothing isn't required?

clang

you can always 'hidden' the smoothing module inside a sub-module... but yours is a good point... another solution to not clutter schematics can be have a kind of...send/receive mechanism a-la pd/max.msp...where you have a module called send and one receive...if you give them the same argument as 'send A' and 'receive A' this work like a cable where send is the outlet and receive is the inlet... and have multiple windows inside the same schematic lalo

clang · 9 Feb 2005

you can always 'hidden' the smoothing module inside a sub-module...

Of course, and for sure I'd put that module on the palette! But even a small module is cluttering, especially if I have to put it on every parameters (for example ADSR would need 4 'smoother'!)

you have a module called send and one receive...if you give them the same argument as 'send A' and 'receive A' this work like a cable where send is the outlet and receive is the inlet

That's wireless? 🙂 Don't know... seems to me that it could lead to some confusion.

multiple windows inside the same schematic

Hey! I'm a Tracktion user (the uncluttered-one-window sequencer)! Don't even speak about multiple windows! LOL 😀 btw: I've read the vst generated in SM don't work in Tracktion... hope they will in future!

malc · 9 Feb 2005

Exported VSTi's will work in Tracktion. There was a bug in an earlier release that caused a problem but that is fixed now.

That said, we have spotted another small bug that causes the sound to go wrong after you hide and then re-open the VSTi window in Tracktion and a crash on closing. We know what is causing this and should get it fixed soon. I'll let you know.

tedburt · 9 Feb 2005

Hi, newb here as well, don't know if anyone's interested, but I developed a custom smoothing algorithm a while ago. It does virtually perfect smoothing (retains symmetry - will turn a pulse into an almost exact sine), and will smooth over an unlimited period with no loss of accuracy/increase in computation.

However, it's acceleration/decceleration modelled, and therefore lacks the linearity of a filter algorithm making it less open to optimisations. Because it's not filter based though, it's possible to use a linearly interpolated version of it, (say every 64 samples), which is way more efficient than even a simple filter, and produces far superior results. The downside is that beyond a certain resolution, you have linear interpolation of the signal. However, I know from experience with it that this just isn't noticable on control signals...

If you were interested you'd be welcome to use it...

malc · 9 Feb 2005

Hi tedburt and welcome on board.

Thanks for your post, your algorithm sounds great, I'd love to see it.

lalo · 9 Feb 2005

tedburt wrote: Hi, newb here as well, don't know if anyone's interested, but I developed a custom smoothing algorithm a while ago. It does virtually perfect smoothing (retains symmetry - will turn a pulse into an almost exact sine), and will smooth over an unlimited period with no loss of accuracy/increase in computation.

However, it's acceleration/decceleration modelled, and therefore lacks the linearity of a filter algorithm making it less open to optimisations. Because it's not filter based though, it's possible to use a linearly interpolated version of it, (say every 64 samples), which is way more efficient than even a simple filter, and produces far superior results. The downside is that beyond a certain resolution, you have linear interpolation of the signal. However, I know from experience with it that this just isn't noticable on control signals...

If you were interested you'd be welcome to use it...

yeah tedburt..i'd like to see it too... i don't think u're a math-newbie 😀 infact I am 🙂

tedburt · 11 Feb 2005

Hi, Was having a think about this, and the 2 options (internal or module).

Internal would be useful, especially for beginners, but the problem is that to smooth every possible parameter would be overkill & very inefficient. What you would have to do in practise is analyse each possible flow to each audio out, and smooth only the parameters of the final module in each of the flows. This doesn't allow you much control though.

A compromise would be to have an internal system (so as not to clutter up the schematics), which you turned on for a particular parameter by right clicking the input you want smoothed and selecting 'set smoothing on' on a context menu. You could allow the smoothing time to be adjustable graphically once it was turned on (maybe a little resizable symbol attached to the back of the input).

This would let you retain control whilst not causing clutter.

Would something like this be possible to do with the GUI?

stefan · 11 Feb 2005

The problem is that the values cannot be smoothened until you convert them to poly or mono connections, which usually is quite far from the actual gui component and it's connections. Also, this way, you can smooth several gui components values after you've "mixed" them (for instance if having several sliders/buttons/knobs affecting the pitch of an oscillator).

I posted a simple and cpu efficient code snippet for smoothing earlier one, basicly it's just:

polyin in; polyout out; float cutoff = 0.9; out = out * (1.0 - cutoff) + in * cutoff;

by adjusting the cutoff (in the range 0..1) you can change how smooth you want the signal to be.

clang · 11 Feb 2005

A compromise would be to have an internal system (so as not to clutter up the schematics), which you turned on for a particular parameter by right clicking the input you want smoothed and selecting 'set smoothing on' on a context menu. You could allow the smoothing time to be adjustable graphically once it was turned on (maybe a little resizable symbol attached to the back of the input).

Seems cool to me! 🙂 But I'd like to understand stefancrs post: the zipper noise is caused by sudden changes in the signal from value x to y in a very short time t. Smoothing means making the change slower, so the signal changes from x to y in a time ts > or >> t. As tedburt suggested, you could set ts time graphically. Is your code snippet doing this? Another thought: if sudden changes are determined only by gui components, couldn't the smoothing be applied just before their output? Maybe your code snippet is doing this! Sorry I'm a bit confused!

jorge · 11 Feb 2005

I actually have the smoothing component half done.

At the moment, because there is no other way of smoothing a float transition, stefan's way is the best one. The disadvantage of stefan's way, because it is implemented with poly code is that it becomes part of the compiled code that runs a sampling rate, should be very fast but nevertheless it adds a little bit of processing to the sound code.

The way which I think is the best and the way I'm implementing it is to have a new smoothing primitive with a green float input and a green float output. The green connectors work with triggers and dont add any processing at sampling rate. When a smoothing primitive receives a new float, it will start a timer which will be used to generate the intermediate values from the old float to the new one, when they're the same, the timer is killed. I think this is the most efficient implementation. There will probably be a second input connector to specify the rate of the timer.

lalo · 11 Feb 2005

jorge wrote: I actually have the smoothing component half done.

At the moment, because there is no other way of smoothing a float transition, stefan's way is the best one. The disadvantage of stefan's way, because it is implemented with poly code is that it becomes part of the compiled code that runs a sampling rate, should be very fast but nevertheless it adds a little bit of processing to the sound code.

The way which I think is the best and the way I'm implementing it is to have a new smoothing primitive with a green float input and a green float output. The green connectors work with triggers and dont add any processing at sampling rate. When a smoothing primitive receives a new float, it will start a timer which will be used to generate the intermediate values from the old float to the new one, when they're the same, the timer is killed. I think this is the most efficient implementation. There will probably be a second input connector to specify the rate of the timer.

cool 🙂 i think the second inlet is a must 🙂

cbit · 22 Feb 2005

for me a smoothing component seems the best solution in different ways, i'm glad its in the works 🙂

lalo · 22 Feb 2005

cbit wrote: for me a smoothing component seems the best solution in different ways, i'm glad its in the works 🙂

agree m8 🙂

bManic · 2 Mar 2005

Yes! I've been waiting for such a module. Thanks Jorge!

posh · 12 Apr 2005

right. so im a bit idiotic here and still not quite sure about this whole thing, BUT.. jorge, this float smooth component, does this mean that you can use it to trig smooth when input goes over N value, but not to smooth when it stays below N? if so, that can be used for some pretty interesting effects, imo.

- posh.

lalo · 13 Apr 2005

i think it's gone a little lower in the to-do list 😉

some fixing for stefan's synth is goin' on..i've been told 🙂

lalo

Tom7777 · 13 Apr 2005

Is there going to be a coding module that can have floatin and floatout inputs? could the poly code be changed to floats if there was a module like this? Its good to know theres a smoothing module being made 🙂