Simple noise gate
there's one in the DIY2 library
check out mono-gate or st-gate
DIY2 - Effects, Sample players, Synths and Sound Synthesis.
Hey I got a question. in the compression patches I can kind of get my head around the amp factor section. But I don't get any of the att/rel section. Can anyone explain what that sgn~ (signum) is/does ? Secondly I can see the table is effected by the release but not really on the attack. I can hear the attack. The block size is 2. I'm guessing if the default block size is 64 samples then 2 means 128?? Or is it actually 2 ? This outputs a frequency between 0.019 and 57 into a VCF along withe the original amp factor. Any advice ?
ok, so the [amp-factor] stage is giving the amplitude of the signal, scaled according to our threshold and ratio settings. This will either be positive if the amplitude is rising, or negative if it's falling.
next we go into the [att-rel-filtering] section, where we separate the attacks (positive) from the releases (negative)
[block 2] really does mean that the blocksize is only 2 samples. This is so that the [tabsend~] and [tabreceive~] objects deal with packets of two samples at a time,
giving us a sample delay between the input signal and the signal received by [tabreceive~]. If the blocksize were the default of 64, then we would have a 64 sample delay, and our compressor would not work at all well.
sgn~ just gives the sign of the signal, so -1 for negative numbers and 1 for positive ones. note that we are dealing now with just the AMPLITUDE of the signal, which has been scaled in the [amp-factor] section so that rising amplitude (ie, attack) is positive and falling amplitude (release) is negative.
that is then split apart using [max~ 0] with attack sent to the left outlet and release sent to the right outlet. The attack and release stages are both scaled separately (attack scaled by 0.019 to 57, and release by, i think, 0.00019 to 5.7) (and i don't know exactly WHY 57 was chosen, i'm sure the patch would work just as well with 50 or 60)
then we go through the [vcf~]. Although vcf~ is normally used to shape the frequency content of a wavform, in this case, it has a different use. It is smoothing the amplitude signal. So, if we set a fast attack, then the vcf~ will have a cutoff of 57hz, and our compressor will attack within 20ms. if we set a slow attack, then the vcf~ will have a frequency of 0.019hz, and the compressor will take a few seconds to fully attack.
finally, the original signal is multiplied by the compression factor, and sent along its way.
There are some quick mods you can do to this patch, too. A sidechain compressor, essential for any sort of 'french' electro sound, can be made by adding another inlet~ for a second audio signal, and taking the inverse of the compression factor, like this:
and then multiply your second signal by that.
also, it is fun to take the compression factor output to its own [outlet~] and use it as a modulation source for filter cutoffs for synth sounds, etc.
anyway, hope that clears things up a bit?
FFT freeze help
Acreil - I'll admit that some of that was a little over my head, but some aspects of it sound a little like what Zynaddsubfx (a softsynth) does in its 'padsynth' algorithm? Basically it takes a simple waveform and spreads/"smears" it, in a gaussian distribution, over a range of frequencies, with some slightly complex-looking frequency domain mathematics. As you suggest, it's quite similar to a chorus effect, really...
I'll have to admit it's partly over my head too. I don't really know that much about frequency domain stuff. I just read some papers, made some connections between them, and dicked around with example I09. But I guess I hit on something a little more unique than I expected. I'll upload the patch if I get it cleaned up a little more. It should be more efficient too...
I think as far as Padsynth goes, you can imagine playing a sound into a reverberator with an infinite decay time, then sampling and looping the output. Only it leaves out the reverberator (and the coloration, etc. that it can add) and produces the result (randomized phase) directly. The output is inherently periodic, so it loops perfectly with no additional effort. I think Image Line's Ogun uses the Padsynth algorithm, and that NOTAM Mammut program can do much the same thing (I think it actually illustrates the effect really nicely). Padsynth does smear out the frequency components a little (I guess windowing sorta does that for STFT...), but the phase randomization is the important part if you're processing arbitrary audio input.
Here are some samples of my patch (I probably should have posted them before):
http://www.mediafire.com/?6nf525vnv1xew58 (wet and dry mix)
original material: (this actually makes for surprisingly good test material since it's mono, pretty dry, and includes vocals, guitar and transient sounds)
http://www.mediafire.com/?c62tr5ox07r4tdc (wet only, you may be able to guess the original)
Both use time variant decorrelation, feedback (reverb), pitch shift, nonlinear filtering, and also random filtering. But these don't demonstrate some of the more extreme effects since it favors very, very slow and sparse source material. I didn't use any other effects, just the one patch.
You can pitch shift the FFT data with [vd~], just like in time domain, only it works the opposite way, i.e. stretching the spectrum shifts the pitch up and compressing it shifts it down. [rifft~] ignores the second (redundant) half of the frame, but if you're doing extreme pitch shifting you have to take care not to spill over into the next frame. Or you can just write the IFFT's output to a table and transpose it like you would any sampled data (as Padsynth does). I'm no expert in this department either; I just messed around until it worked. And I'm not entirely sure what you're going for, either.
FFT freeze help
Brace for wall of text:
My patch is still a little messy, and I think I'm still pretty naive about this frequency domain stuff. I'd like to get it cleaned up more (i.e. less incompetent and embarrassing) before sharing. I'm not actually doing the time stretch/freeze here since I was going for a real time effect (albeit with latency), but I think what I did includes everything from Paulstretch that differs from the previously described phase vocoder stuff.
I actually got there from a slightly different angle: I was looking at decorrelation and reverberation after reading some stuff by Gary S. Kendall and David Griesinger. Basically, you can improve the spatial impression and apparent source width of a signal if you spread it over a ~50 ms window (the integration time of the ear). You can convolve it with some sort of FIR filter that has allpass frequency response and random phase response, something like a short burst of white noise. With several of these, you can get multiple decorrelated channels from a single source; it's sort of an ideal mono-to-surround effect. There are some finer points here, too. You'd typically want low frequencies to stay more correlated since the wavelengths are longer. This also gives a very natural sounding bass boost when multiple channels are mixed.
Of course you can do this in the frequency domain if you just add some offset signal to the phase. The resulting output signal is smeared in time over the duration of the FFT frame, and enveloped by the window function. Conveniently, 50 ms corresponds to a frame size of 2048 at 44.1 kHz. The advantage of the frequency domain approach here is that the phase offset can be arbitrarily varied over time. You can get a time variant phase offset signal with a delay/wrap and some small amount of added noise: not "running phase" as in the phase vocoder but "running phase offset". It's also sensible here to scale the amount of added noise with frequency.
Say that you add a maximum amount of noise to the running phase offset- now the delay/wrap part is irrelevant and the phase is completely randomized for each frame. This is what Paulstretch does (though it just throws out the original phase data and replaces it with noise). This completely destroys the sub-bin frequency resolution, so small FFT sizes will sound "whispery". You need a quite large FFT of 2^16 or 2^17 for adequate "brute force" frequency resolution.
You can add some feedback here for a reverberation effect. You'll want to fully randomize everything here, and apply some filtering to the feedback path. The frequency resolution corresponds to the reverb's modal density, so again it's advantageous to use quite large FFTs. Nonlinearities and pitch shift can be nice here as well, for non-linear decays and other interesting effects, but this is going into a different topic entirely.
With such large FFTs you will notice a quite long Hann window shaped "attack" (again 2^16 or 2^17 represents a "sweet spot" since the time domain smearing is way too long above that). I find the Hann window is best here since it's both constant voltage and constant power for an overlap factor of 4. So the output signal level shouldn't fluctuate, regardless of how much successive frames are correlated or decorrelated (I'm not really 100% confident of my assessment here...). But the long attack isn't exactly natural sounding. I've been looking for an asymmetric window shape that has a shorter attack and more natural sounding "envelope", while maintaining the constant power/voltage constraint (with overlap factors of 8 or more). I've tried various types of flattened windows (these do have a shorter attack), but I'd prefer to use something with at least a loose resemblance to an exponential decay. But I may be going off into the Twilight Zone here...
Anyway I have a theory that much of what people do to make a sound "larger", i.e. an ensemble of instruments in a concert hall, multitracking, chorus, reverb, etc. can be generalized as a time variant decorrelation effect. And if an idealized sort of effect can be made that's based on the way sound is actually perceived, maybe it's possible to make an algorithm that does this (or some variant) optimally.
Patching a good reverb
i looked at the freeverb~ source code, and even though at that time i didn't understand anything about text based code, i was able to figure out pretty much how it worked.
the reverb i put in my diy-2 library was originally based off that freeverb code, but is somehow a lot thinner and breathier, where the freeverb sound is more thick and metallic. Andy Farnell suggested that freeverb~ may use some overlap on the process. I did try that it mine, and got closer to the freeverb sound, but it also ate up so much CPU, so i dropped the overlap bit.
anyway, that reverb is here:
there's also an FFT based one that i just took from the pd documentation.
all my stuff is licensed under the same BSD license as PD, so if you're using pd, you're welcome to use or modify anything of mine too. there may be some expr objects or something in there that you'll need to change though? not sure about the deal on android, but i know on iphone you can't use expr cos it's under the GPL license.
Better sounding guitar distortion ... beyond \[clip~\] and \[tanh~\]
thank you for your feedback !
wow, nice to finally see this!
why are highs contrary to what you'd expect? at a low sample rate, the highs are folded back into low frequencies, but when you upsample, the highs are preserved as true highs. i think it works just how it should. The upsampled version is certainly much clearer and brighter to my ears. Particularly with a high distortion level.
That makes sense. The upsampling workaround officially wins (I'll try x16)! I think I focus too much on highs, as I tend to find this disto patch rather 'acid'; the original sample sounds much darker than the distorted sound. I don't owe the actual pedal so I only rely on my 'feeling', which is far from reliable Of course it's logical to add highs with such a nonlinearity, and lows are filtered several times.
Anyway I still find the heavily distorted sounds have a strong 'schh schh schh component' in the highs, and I can't remember having heard that as strong in actual analogic effects. Would you agree with that? Of course I know this is a rather basic 'physically-informed' design, and that analog will always sound better
actually, this patch really demonstrates the effect of aliasing. if you turn the tone knob down as far as it will go, and also turn the distortion down to zero, and turn aliasing off, you can clearly hear the rustling noise caused caused by those wrapping frequencies.
turn aliasing back on again, and the noise is gone.
Very strange, when I do what you say, the upsampled version sounds like the 'not upsampled one', with a 'sch sch' noise added !
The BJT gains are bound to my 'signal amplitude policy' : input file or audio source and output should never clip. These gains can be seen as follows : the first one (before the clipper) adjust 'how early' distortion occurs, and the second one gives the distorted signal a boost in order to give similar subjective level than dry signal.
The values were found empirically.
This might be where I have the biggest issue, though the article doesn't make it so clear, either. [...] the DS-1 isn't a baby's distortion pedal.
[...] Also, you don't need to calculate the boost into the filter coefficients. That's only useful for plotting. You can just use [*~] before or after the filter do accomplish it.
I understand all these arguments. I'll modify the patch. At the beginning I was using this kind of reasoning, but as the 'nominal input level' is -20dbu (http://www.bossus.com/gear/productdetails.php?ProductId=127&ParentId=254#), and the dbu definition I found seemed difficult to bind to 'our' db, I just dared to make the basic (36db-20db=16db~6.3 times in amplitude) operation... not far from the 6 in my patch Not very scientific, though.
Anyway I understood another reason why my 'subjective hearing' failed: feedind my patch with a 0db normalised sample maximizes input level, and the result will always be 'over the top' compared to non-active guitar pickups with a volume knob not always pushed to max. In other words, if I look at demos on youtube the result heard will be less distorted than my patch's. Anyway this can always be seen as an additional parameter for a 'parametric DS1 deluxe edition patch'
As mod said, it's not so much more highs as less lows, and those lows are a result of aliasing. To my ears, the upsampled version sounds less muddy. (By the way, in your upsampled portion, you have a different argument for the second [DS1-bjt_stage~]. Making them equal makes the difference even less noticeable, and draws more attention to the mud than the highs.)
Ok, upsampling wins !
Yes, there is a difference, but it's not a Matlab thing. It's the choice of the logarithmic scaling in the x-axis. The article uses powers-of-ten as equal distances. Mine uses [mtof] for the scaling, so that a semitone, octave, or whatever musical interval is the same distance. Also, I made an adjustment so that everything between 0 and about 20 Hz (at 44.1k) gets squashed in the leftmost 10% of the graph. If I didn't to that, then about half the plot would be taken up with frequencies below the audible range.
Ok, perfect ! Everything's cool now.
(commenting peaking after ToneStage)
This has nothing to do with your tone stage. It's because of the passband ripple in the Chebychev filters. The IEM Chebychev filters have a 1 dB ripple, though I don't actually know if that means +/- 1 dB or +/- .5 dB. Either way, it's creating a boost at some frequencies, and pushing the output down by 1 dB should keep it below [-1, 1]. This could also be contributing to the highs, as the ripple is typically more pronounced near the cutoff frequency.
Mmh, I thought the same, but then I decided to check the plots taken out of the 'not upsampling' part, and the peaking is still there ! The Chebyshev filters can be the source, then ...
The output from [tanh~] will never clip, so as long as you make up for the ripple and don't boost the second BJT stage, you should be fine.
Just one more thing to add for now, and that is you're doing too much in the upsampled portion. The only thing that needs to be in there is the non-linear function ([tanh~]) and the anti-aliasing filters. Everything else is linear and doesn't benefit from upsampling, so it's just creating more computational load.
Of course I precisely want to get rid of this peaking to be able to fully rely on [tanh~] to 'master' my output gain. I'll try the FIR instead of cheby (as proposed by acreil) some day. (I don't even know yet how they work and how I'll have to implement it).
I left the 'full upsampled chain' in this patch only to see if someone would have commented it, and we totally agree. But this 'playing the noob' attitude of mine is a rather raw 'fishing method' for getting stimulating information ... sorry this lead you to lay down the whole picture BUT nothing wasted, as your final 'delicate' -1db cut surprises me and I'll use it (when I'll get rid of peaking) and moreover, as you are reminding me that you use a 18000 cutoff freq, I'll give a look again at it, just trying to find a good criterion to pick one
Thank you everybody,
P.S. : sorry for those very long sentences ... not very clear
Swept sine deconvolution
I was referred to this thread by Serafino Di Rosario, and I will test this PD patch for performing ESS measurements. Everything is very interesting for me, and it seems that Katja did a very good job!
Regarding the problems encountered, I give you these infos:
sine-phase-matched sweep. This method is very useful when performing distortion measurements, or computing multiple-order IRS to be used in not-linear convolution processor (for emulating the nonlinearities of a device). For the method to work, it is mandatory that the sine sweep is sine-phased not only at the beginning, but also at the end of each octave. This way, each harmonic-order IR will be phase matched with the linear IR. The provided formulation solves this problem, and it is very good to see it explained here so simply.
The importance of using a phase-synced exponential sweep was first discovered by Antonin Novak, a Ph.D. student of the universities of Prague and Le Mans.
The ripple at low frequencies can be controlled by proper fade-in. The choice of the "optimal" fade law is still a big subject under scientific discussion. Hann windowing is just a very initial, suboptimal approach. I plan to investigate further the choice of the optimal fade law, and publish something on this topic, soon.
The concept of cutting away everything before the arrival of the direct sound is wrong, in my opinion. The "silence" before the arrival of the direct sound has a very important physical meaning, it is the "time-of-flight" of the sound, and provides an accurate measurement of the distance between the source and the receiver. Furthermore, it contains "background noise", which is a very important quantity to know, for example when deriving STI from the IR measurement.
So PLEASE, do not cut away this initial silence! If the IR has to be used as a filter for a convolution-based reverb plugin, the plugin must be intelligent enough for analyzing the IR, and giving the user the possibility to keep this initial silence or cut it away. For example, IR-1 from Waves gives these possibilities. In any case, a measured IR of a room should always contain the time-of-flight... Publishing "pre-cutted" IRs is wrong, and in the long run will cause a lot of troubles...
The "Fractional delay", for the same reasons, should NOT be corrected! If the time-of-flight is fractional, good, let's stay with this fact. As pointed out, cutting (time-shifting) improperly the measured IR can alter its spectrum. So, please, keep every measured IR as it comes out from the convolution with the inverse sweep... If the higher-order distortion products are not needed, it make sense to only keep the linear part only, but always starting from the true "zero time". Let's make an example: I generate a 20s-long IR at 48 kHz, that is 960,000 samples.
The inverse sweep will also be 960,000 samples long.
I play the sweep, and record the room response for, say, 1,200,000 samples, for being sure of capturing the complete reverberant tail even at the higher frequencies.
Now I convolve the recorded signal (1,200,000 samples) with the inverse sweep (960,000 samples), and I get a convolved signal which is long 2,159,999 samples.
If I want to keep a 4s long IR, containing only the linear response, you should throw away the first 959,999 samples, and keep the following 192,000 samples.
As this signal starts from the true "zero time", the main peak will not be at the very beginning, but delayed of an amount corresponding to the source-receiver distance. If it was 10m, it will be 10/340=0.0294 seconds...
For performing efficiently convolution of very long filters (in the example above, the Inverse Sweep was nearly 1 million points) it is advisable to employ a partitioned convolution scheme. That is, the filter is splitted in a number of blocks, so that instead of performing a single, very long FFT , a number of shorter FFTs is performed instead. On my web site you find a couple of papers explaining the partitioned convolution algorithm. This is the same algorithm employed in the well-known BruteFIR open-source program by Anders Torger.
Phasor~ as index to tabread~ with del and line~ envelope glitch
I'm using phasor for an index to a tabread~ to play a sample.
I'm also using line~ as an envelope to control audio output.
The timing for the envelope is set by the size of the sample size and samplerate~ as well as the frequency for the phasor~.
The magnitude of the phasor is adjusted to the sample size.
The sample player can be re-triggered and when this happens a line~ is set to go to 0 in 5ms,
a delay is set for 5ms,
then bangs another line~ to go to velocity in 0,
as well as setting phasor~ frequency to 1/t and phase to zero.
At which time another delay is setup at samplelength in ms.
After the sample is played the phasor~ frequency is set to 0 then
another line~ to 0 in 5ms is sent to the [*~] .
This causes a glitch when the sample is retriggered because the phasor~ is reset to zero and starts replaying the sample.
This glitch can not be heard when the sample is not re-triggered so maybe it's a control vs signal timing issue.
I did hear the glitch at the end of the sample re-triggered or not using vline~.
So my question is how do you do audio rate envelope triggering of envelopes ? I would post the patch but it is a mess. A good answer or pointer to some reference material would be greatly appreciated. I haven't quite wrapped my head around the sample and hold sampler examples yet.
Variable delay patch - need help
If you're interested, I'm working on a DSP system for wave field synthesis. WFS is an audio rendering technique where an array of loudspeakers is used to reproduce the sound field within a region.
You can simulate Doppler effects etc using a standard variable delay, but it is not an entirely accurate way to simulate sound emitted from a moving source. For example the effects of a change in delay will be heard instantly for a standard variable delay, whereas for a real moving source a change in position will only be heard after the transit time delay.
You are right of course about the skipping of samples. My MATLAB tests have shown me that this gives rise to a type of aliasing when the sound is slowed down by a lot. Thankfully, with the extrapolation for writing to fractional positions, the effect is rather subtle although by no means inaudible. This could be gotten around by looping through every sample between the position change, but I'm pretty sure that would be impossible in pd.
I am doing this because I want to compare various methods of realising moving sources.
BECAUSE you guys are MIDI experts, you could well help on this...
Dear Anyone who understands virtual MIDI circuitry
I'm a disabled wannabe composer who has to use a notation package and mouse, because I can't physically play a keyboard. I use Quick Score Elite Level 2 - it doesn't have its own forum - and I'm having one HUGE problem with it that's stopping me from mixing - literally! I can see it IS possible to do what I want with it, I just can't get my outputs and virtual circuitry right.
I've got 2 main multi-sound plug-ins I use with QSE. Sampletank 2.5 with Miroslav Orchestra and Proteus VX. Now if I choose a bunch of sounds from one of them, each sound comes up on its own little stave and slider, complete with places to insert plug-in effects (like EQ and stuff.) So far, so pretty.
So you've got - say - 5 sounds. Each one is on its own stave, so any notes you put on that stave get played by that sound. The staves have controllers so you can control the individual sound's velocity/volume/pan/aftertouch etc. They all work fine. There are also a bunch of spare controller numbers. The documentation with QSE doesn't really go into how you use those. It's a great program but its customer relations need sorting - no forum, Canadian guys who wrote it very rarely answer E-mails in a meaningful way, hence me having to ask this here.
Except the sliders don't DO anything! The only one that does anything is the one the main synth. is on. That's the only one that takes any notice of the effects you use. Which means you're putting the SAME effect on the WHOLE SYNTH, not just on one instrument sound you've chosen from it. Yet the slider the main synth is on looks exactly the same as all the other sliders. The other sliders just slide up and down without changing the output sounds in any way. Neither do any effects plugins you put on the individual sliders change any of the sounds in any way. The only time they work is if you put them on the main slider that the whole synth. is sitting on - and then, of course, the effect's applied to ALL the sounds coming out of that synth, not just the single sound you want to alter.
I DO understand that MIDI isn't sounds, it's instructions to make sounds, but if the slider the whole synth is on works, how do you route the instructions to the other sliders so they accept them, too?
Anyone got any idea WHY the sounds aren't obeying the sliders they're sitting on? Oddly enough, single-shot plug-ins DO obey the sliders perfectly. It's just the multi-sound VSTs who's sounds don't individually want to play ball.
Now when you select a VSTi, you get 2 choices - assign to a track or use All Channels. If you assign it to a track, of course only instructions routed to that track will be picked up by the VSTi. BUT - they only go to the one instrument on that VST channel. So you can then apply effects happily to the sound on Channel One. I can't work out how to route the effects for the instrument on Channel 2 to Channel 2 in the VSTi, and so on. Someone told me on another forum that because I've got everything on All Channels, the effects signals are cancelling eachother out, I can't find out anything about this at the moment.
I know, theoretically, if I had one instance of the whole synth and just used one instrument from each instance, that would work. It does. Thing is, with Sampletank I got Miroslav Orchestra and you can't load PART of Miroslav. It's all or nothing. So if I wanted 12 instruments that way, I'd have to have 12 copies of Miroslav in memory and you just don't get enough memory in a 32 bit PC for that.
To round up. What I'm trying to do is set things up so I can send separate effects - EQ etc - to separate virtual instruments from ONE instance of a multi-sound sampler (Proteus VX or Sampletank.) I know it must be possible because the main synth takes the effects OK, it's just routing them to the individual sounds that's thrown me. I know you get one-shot sound VSTi's, but - no offence to any creators here - the sounds usually aint that good from them. Besides, all my best sounds are in Miroslav/Proteus VX and I just wanted to be able to create/mix pieces using those.
I'm a REAL NOOOB with all this so if anyone answers - keep it simple. Please! If anyone needs more info to answer this, just ask me what info you need and I'll look it up on the program.