DIY2 - Effects, Sample players, Synths and Sound Synthesis.
@unstable said:
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:
[pd att-rel-filtering]
|
[-~ 1]
|
[*~ -1]
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?
have fun!
Better sounding guitar distortion ... beyond \[clip~\] and \[tanh~\]
Also quite glad to see this! This has become one of my favorite threads of the forum. It covers a lot of ground, and it's great to see your hard work and perseverance payoff here. Cheers too you, nau!
@nau said:
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. In the article, it shows the frequency response of the BJT stage as having about a 36 dB boost in the pass band. That amounts to multiplying the signal by about 63. And, if you want to get really technical, the waveshaper in the article clips at +/- .6, so you'd have to add about another 4.5 dB to make up for that. You're using much lower values. This is what I was talking about earlier when I said you should really crank the input to [tanh~] to get some serious distortion, and the DS-1 isn't a baby's distortion pedal.
Now, the article also says that the second BJT stage is really to boost the signal back up for the subsequent load. Since we're not sending this into other circuits here, I think the dB boost of the second BJT should be ignored. 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.
So basically what I'm saying is, there should be a boost of about 40 dB ([*~ 100]) as part of the first BJT stage, and no boost for the last one. Then you can really break some teeth with this distortion.
- when switching between upsampled or not upsampled processing, the difference is barely noticeable (maybe the upsampled one has more highs, but that is the exact contrary of what I would expect). Does someone see what I am doing wrong, if this is the cause of this perceptual draw ?
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.)
- the transfer curves can be seen in the patches, but are always slightly different than the one showed in the article. But I have been very careful when calculating coefficients and I don't really think they are wrong. Would there persist a difference between [filterplot.mmb] and traditional Matlab-like graphs ?
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.
- The DS1-tone_stage helpfile has been written by Maelstorm, and the response curve shows no gain value above 0db. Nevertheless the tone knob, when pushed, can lead to signal amplitude beyond [-1 1]... I can't figure out how a signal can have all its discretised frequencies pulled down and still exhibit peaking. Should I read more about the subject (is there a name for this symptom ?), or is there an error in my patch ?
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.
- is my 'signal policy' perfectible ? I want the output signal never to clip, so I multiply the output by 0.4 in such a way that when Tone and Dist are full right but Level is medium the signal never clips.
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. So it should look more like this:
[*~ 100]
|
[DS1-bjt_stage~ 1]
|
[DS1-opamp_gain~]
|
[*~ 8]
|
[pd upsample]
|
[DS1-tone_stage~]
|
[DS1-bjt_stage~ 1]
|
[*~ .891] <-- 1 dB cut
And [pd upsample] should look like this:
[inlet~]
|
[lp10_cheb~ 18000] [block~ 64 1 8]
|
[tanh~]
|
[lp10_cheb~ 18000]
|
[outlet~]
Okay, that turned out to be more words than I expected. But we're getting into DETAILS here! Again, nice work, nau.
Pitch changes using \[vd~\]
...but don't forget, there is a "point" (or frequency or refresh-rate) at which calculations via (audio)-signals are faster than the data-wise calculations...
I wonder when this exactly is the case. I have no Mac so I can't directly measure the CPU-load... but using audio often helped to reduce dropouts.
...ANd why or how?! Well, I don't know since I'm not into C-programming or whatever.. But I guess there must be any kind of pre- or post-message sticking to the data-signal (apart from all those "bang", "float" or "list" ) which roughly is left out at audio-signals.
If there is nothing like "audio" for audio-signals (like "bang" for "data-bang"), then the usual premessages like "float", "list"... would suffice.
So in general (looking at just one action like one value of the audio-signal-vector or one "banged data-action") there is more going on at data-signals then at audio-signals.
So they are calculated faster if the data-refresh-rate exceeds a certain frequency. Any other theories?!
Flipp
Variable delay patch - need help
Hi,
The attached patch dsdelay is supposed to be a variable delay line with a moving write point. vd~ uses a moving read point which is acceptable for most applications but not what I am working on. I have implemented my moving write point delay line in MATLAB and it works reasonably well. However I am experiencing issues with PD implementation.
The patch uses a table to store the delay line values and is supposed to use a circular delay line method (i.e. the read/write points shift with time instead of the actual elements of the delay line). The intention is that the read point shifts along the delay line by one sample per sample, and the write point does the same whilst the delay is not being altered. The write point uses a simple two point extrapolation to allow writing at fractional table indices.
I'm having two problems:
1. I can't find a satisfactory method of wrapping signal values in an arbitrary range. I want to be able wrap a signal value between 0 and 44100 for example, but using
|
[/~ 44100]
|
[wrap~]
|
[*~ 44100]
|
gives rise to rounding errors which create artifacts in the output. This is why in the current state, the output is intermittent rather than continuous.
2. For some reason the 2 point extrapolation seems to be not working correctly. I'm getting a ring modulation type effect on the output. In MATLAB the addition of the two point extrapolation helped to minimise artifacts when the delay time was being altered. Altering the delay time gives rise to horrible artifacts at the moment though.
Any pointers on how to get this working properly would be greatly appreciated.
Thanks
Ben
Audio routing
Does anyone know of an audio routing or switching abstraction/external, such that one of two or more incoming signals can be selected to be passed on to the next object, ensuring that the other signals are completely cut off?
I am creating an 2-effect module where the effect order can be switched round.
For example, the audio either routes through a delay then into a panner then to the output, or when switched, routes through the panner then into the delay then to output.
Thought I had the switching all sussed out. There's a switch ahead of the two effects which directs the incoming signal to one or other. This same switch is also used to direct the output of the delay either to the panner or the main out, depending on whether it went through the delay first or not. The same is done for the output from the panner.
The whole system works until I connect the output of one effect into the input of the other, when the signal disappears. It's probably some sort of feedback problem, but it shouldn't be because only one of the input signals should be on at any one time.
I've heard of spigot~ but not sure what library it's in as it doesn't work for me.
Could mux~ possibly handle this problem?
Audio glitch with portaudio in PD
Hi everyone,
I'm having an issue with audio output in PD : when setting audio to output via portaudio, all the audio that gets out of PD has audio glitch in it, some kind of random-spaced crackles or clicks. It is completly useless as such. Increasing the delay in PD's audio settings doesn't change a thing.
However, using Jack as an audio outlet supresses all this problem, and the audio is clean that way.
Would anyone know the reason for this? I would be glad to know it as there may be a link with another issue about audio on my hardware : system audio of mac os X has the same kind of glitches that I got with PD on portaudio, only it's only occasional glitches so it's bearable. Solving this issue would be a big relief to me.
My hardware is a hackintosh (pc with osX installed on it), and mbox2 as audio interface (but I have tested with an m-audio transit and I have the same crackling issue). My soft is osX Snow Leopard 10.6.5.
Any help appreciated!
Wrong order of operation..
Thanks for the replies!
Okay lets take the "G05.execution.order" patch as an example.
Just duplicate the "pd pulse"- subpatch and connect it to the same outputs as the original, delete the original..
Now both versions should work correctly.
This is my explanation:
Since the "pd pulse" is placed at last, and is the first object in the "audio-line" (or "audio-path"), this line will be processed at first (this is what I mean with placed: ABC -> processed: CBA, where C is the "pd pulse"-object).
So the [delwrite~] will get a signal from the "pd pulse" and after that one inlet of the [+~] will get a signal (not so important, but this is the case if you first connect the [+~] and then the [delwrite~] (again ABC->CBA, but for audio-cables) ).
Here another effect comes up: The [+~] will only output its signal, after it has received all incomming audio-signals. As far as I tested, this goes for all audio-objects! (I think this makes sense in terms of processing parallel "realtime"-audio-streams)
So to cut it short: the one inlet of the [+~] is the end of the first audio-line (or audio-path)! After this the next path, containing the [vd~] is processed. So the [vd~] in all is processed after the [delread~] and you have the right order.
I hope I could clarify this...
Interaction Design Student Patches Available
Greetings all,
I have just posted a collection of student patches for an interaction design course I was teaching at Emily Carr University of Art and Design. I hope that the patches will be useful to people playing around with Pure Data in a learning environment, installation artwork and other uses.
The link is: http://bit.ly/8OtDAq
or: http://www.sfu.ca/~leonardp/VideoGameAudio/main.htm#patches
The patches include multi-area motion detection, colour tracking, live audio looping, live video looping, collision detection, real-time video effects, real-time audio effects, 3D object manipulation and more...
Cheers,
Leonard
Pure Data Interaction Design Patches
These are projects from the Emily Carr University of Art and Design DIVA 202 Interaction Design course for Spring 2010 term. All projects use Pure Data Extended and run on Mac OS X. They could likely be modified with small changes to run on other platforms as well. The focus was on education so the patches are sometimes "works in progress" technically but should be quite useful for others learning about PD and interaction design.
NOTE: This page may move, please link from: http://www.VideoGameAudio.com for correct location.
Instructor: Leonard J. Paul
Students: Ben, Christine, Collin, Euginia, Gabriel K, Gabriel P, Gokce, Huan, Jing, Katy, Nasrin, Quinton, Tony and Sandy
GabrielK-AsteroidTracker - An entire game based on motion tracking. This is a simple arcade-style game in which the user must navigate the spaceship through a field of oncoming asteroids. The user controls the spaceship by moving a specifically coloured object in front of the camera.
Features: Motion tracking, collision detection, texture mapping, real-time music synthesis, game logic
GabrielP-DogHead - Maps your face from the webcam onto different dog's bodies in real-time with an interactive audio loop jammer. Fun!
Features: Colour tracking, audio loop jammer, real-time webcam texture mapping
Euginia-DanceMix - Live audio loop playback of four separate channels. Loop selection is random for first two channels and sequenced for last two channels. Slow volume muting of channels allows for crossfading. Tempo-based video crossfading.
Features: Four channel live loop jammer (extended from Hardoff's ma4u patch), beat-based video cross-cutting
Huan-CarDance - Rotates 3D object based on the audio output level so that it looks like it's dancing to the music.
Features: 3D object display, 3d line synthesis, live audio looper
Ben-VideoGameWiiMix - Randomly remixes classic video game footage and music together. Uses the wiimote to trigger new video by DarwiinRemote and OSC messages.
Features: Wiimote control, OSC, tempo-based video crossmixing, music loop remixing and effects
Christine-eMotionAudio - Mixes together video with recorded sounds and music depending on the amount of motion in the webcam. Intensity level of music increases and speed of video playback increases with more motion.
Features: Adaptive music branching, motion blur, blob size motion detection, video mixing
Collin-LouderCars - Videos of cars respond to audio input level.
Features: Video switching, audio input level detection.
Gokce-AVmixer - Live remixing of video and audio loops.
Features: video remixing, live audio looper
Jing-LadyGaga-ing - Remixes video from Lady Gaga's videos with video effects and music effects.
Features: Video warping, video stuttering, live audio looper, audio effects
KatyC_Bunnies - Triggers video and audio using multi-area motion detection. There are three areas on each side to control the video and audio loop selections. Video and audio loops are loaded from directories.
Features: Multi-area motion detection, audio loop directory loader, video loop directory loader
Nasrin-AnimationMixer - Hand animation videos are superimposed over the webcam image and chosen by multi-area motion sensing. Audio loop playback is randomly chosen with each new video.
Features: Multi-area motion sensing, audio loop directory loader
Quintons-AmericaRedux - Videos are remixed in response to live audio loop playback. Some audio effects are mirrored with corresponding video effects.
Features: Real-time video effects, live audio looper
Tony-MusicGame - A music game where the player needs to find how to piece together the music segments triggered by multi-area motion detection on a webcam.
Features: Multi-area motion detection, audio loop directory loader
Sandy-Exerciser - An exercise game where you move to the motions of the video above the webcam video. Stutter effects on video and live audio looper.
Features: Video stutter effect, real-time webcam video effects
Different ways of Implementing Delay Loops
Ta Toxonic - I'll take a look at the patch tonight. Good of you to take the time. Apologies if I've misunderstood though, but I think what you're describing is not quite what I mean: The pitch shift is separated out from the delay time - you're running a pitch shift effect into a separate delay line, which is not going to give the same effect. The delay time will not shorten as the pitch rises. I'll take a look at your patch tonight though as I may have misunderstood what you're getting at.
Maelstorm - thanks also. I understand why the pitch changes on a delay pedal. The pitchshifter patch was a bit of a red herring - though of course it's the same principle. The difference between what you're (both, I think) talking about and what I'm talking about is the way that the pitch changes.
Assuming a stable C tone playing into the delay:
With the standard simple PD delay set up, if you move the read point of a vd~ then you get a glissando as it accellerates, a constant pitch change as it moves at constant speed. So if you turn the knob to change the delay time in the middle of a tone you start with a constant pitch (C), then get a rise of pitch, then it levels out at a new pitch (as you turn then stop turning the knob),
_
___/
If you feed back into the delay, the glissando is repeated as the read speed changed while the write speed was constant:
_ _ _ _
/ |/ |/ |/ |
The effect I'm looking to emulate on the other hand is more akin to changing the speed of a phasor~ reading an array - the pitch change is not a blip, but a stable interval's transposition - eg: you turn the knob, the pitch of the repeats rise by a given interval and stays at that pitch as it repeats (now more quickly):
______
___/
If you play a constant C tone, then speed up the delay until it is a major third higher, you get a major third diad (until the delay dies away), rather than a C tone with a repeating squiggle overlaid.
The effect is the same as you get by speeding up a tape loop delay (though the pedal I'm trying to imitate is a digital delay) which is why I think the rate of the write and read heads are being increased by the same amount.
[edit, just tried to make this clearer and removed a couple of errors]
Seq Sampler Loop
No sound out of this Oscar.
Here's a bit of the error message:
ch file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus13.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus16.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus16.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus14.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus14.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/zapa06.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav:
But, it looks awesome.
Keep well ~ Shankar