@mod said:

>>another suggestion: why not make a lib sub-folder. where you can store such things like modulate. or a scale log which then could work with arguments. <<

that's how i originally did it, but i just wanted to make it so that the modules would just 'work' even if they were removed from the library. i guess i was kind of successful in that regard, because i have spotted some of my drums and stuff inside other people's projects. the only abstraction they need is the 808_state for state saving, but they will work fine without that anyway.

>>currently i guess it would be annoying to change all modulates.<<

i sometimes have a lot of free time the other day i went through the whole library and replaced all the [loadbang] objects with a subpatch to allow for loadbang on dynamic creation. this meant changing around 100 patches and resaving them.

i will do DIY3 soon then. it is not 'finished', and i have some worries that it is not at all backwards compatible with DIY2, but at the end of the day i am a musician more than a programmer, so the function is what matters.

diy3 'upgrades' include:

a built in sound editor, so you can record loops and sounds and edit them within pd and then export them to .wav files.

some more 'synth' like modules and effects units (tape echo, etc)

inbuilt diy-clock module that ties everything together for sequencing, and then of course some sequencer modules.

vanilla pd compatibility (this unfortunately meant removing some really useful things like the 7 and 13 band EQ's, but they could always be imported from DIY2)

Hello,

I happen to be researching ways to make a tape echo like the old roland type using pure data. Would it be possible for you to put up some of the effects from DIY3 such as the tape echo you mentioned?

they are all up, at the link given in the original post:

http://www.m-pi.com/DIY2.zip

I don't see tape echo in there and the 7 and 13 band EQ's are still there. Are you sure the link has been updated?

That's awesome you went for vanilla compatibility. Maybe I can get some DIY2 action on Android via libpd.

not sure, no.

really have to get around to sorting out all the bits and pieces i have and making a new version of this library anyway. i have the time, just not the motivation.

mod / hardoff... I'm using these effects for my proyect. Thank you very much.

I discover, using delayfb, that after applying the same effect two or more times, the resulting audio has a negative DC offset.

Use the attachment file and start doing loud sounds and noise. You'll see on different arrays the result.

Can it be fixed?

http://www.pdpatchrepo.info/hurleur/borrar.pd

DC offset can be tamed by using a highpass filter. Miller's examples usually go with [hip~ 5]

I'm using these FXs A LOT in my project. They are really useful to me. When I have more FXs working in my system, I'll post another WIP post (http://puredata.hurleur.com/viewtopic.php?pid=37430)

Now, I'm trying to emulate a KP3 FX, called "Talk Filter". As the KP3 has a X-Y pad, the manual says that X is for the 1st Formant and Y, the 2nd Formant. I don't think that it really works like that.

It has a feedback delay and, for me, X is a formant modifier, but Y controls the main gain.

Anyway, I'm using a DIY2 st-delayfb and st-material (in "china") to emulate this FX. It sounds very similar. But, when X is at 0, the material change and sounds more "throgh a tube".

Please, hear the mp3 with only that X-Y position and, if you know, tell me how can I modify st-material to get that sound, what are the formants frequencies. I tried by myself, but I couldn't get it.

Or maybe I have to use another filter?

ZIP contains: the mp3, a test version of the FX ("MAIN-fx-talk-filter") with st-material.pd and st-delayfb-modified.pd (only sounds the delay, not the input) and a linear-equation-converter abstract. It uses adc~ and dac~. Be carefull with materials glass1, glass2 and metal... because of the feedback!

Thank you!

http://www.pdpatchrepo.info/hurleur/talk-filter.zip

@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!

oops, i just answered a 4 year old question from the first page. oh well, it never got a proper answer at first, so there you go, that's how the compressor works.

MarioMey, hang on, will have a look at your patch. But i don't know too much about how to program formants. I'll give it a look though...

MarioMey, have a search on this forum for 'formant', there have definitely been some good ones posted here. I think maelstorm did some nice vowel filters perhaps.

looking at your patch, here's what i'd suggest:

instead of just using the formant and the delay feedback in series, i think you might be better off designing a new patch with a delay that goes back through the formant filter.
also, think about putting control for wet/dry. at the moment your dry signal is always 100%, but it might be cool to be able to have only the filtered signal as output sometimes.
and one more thing,
that delay feedback doesn't include any type of protection against signals greater than amplitude 1, so i'd suggest putting a [tanh~] object between the input signal and the [delwrite~]. That way, it will never go over amplitude of 1.

here dude, check this one:

http://puredata.hurleur.com/sujet-3520-speech-formant-synthesizer-bonus-turkish-vowels-pack

actually, i just checked with cycling the delay back through the formant, and it didn't work that well... sorry, i think you had it right in the first place. formant, then delay, seems best.

mod, listening for the real KP3, I thinkt that the way to emulate it, is in that way. Because the formant filter is not modifying the feedback, only the delay (the first).

I had seen the vowel vocoder link and learned about it with some videos. But, I would need the formants of more materials. Or, any other way to get that "sound". I don't know, by adding another filter... what filter?

Let me understand... material filter is just an equalizer, with particular parameters?

PD: looking for vocoders, I found one you made, but diytanh.pd is not in the ZIP. So, it's not working. Can you upload in that thread?

this should do it.

although [tanh~] is fine if you don't mind using externals.

sorry on the formant advice. as i said, it's not something i have looked into that much.

http://www.pdpatchrepo.info/hurleur/diytanh~.pd

Well... actually, it needs diytanh.pd, not diytanh~.pd (diytanh~ abstract is as a subpatch there).

tanh~ is an external... and what about [expr tanh($f1)]?

yeah, that would work.

will attach the diytanh anyway

http://www.pdpatchrepo.info/hurleur/diytanh.pd

aaahhh!!!

don't use that one, it doesn't work for negative numbers.

attaching fixed patch

http://www.pdpatchrepo.info/hurleur/diytanh.pd

Hey, MOD. I'll have a lot (someday, more than 50) FXs opened at the same time. All of them, except one (the one it is working), have [switch 0], to avoid processing signal. But the messages are being processed.

I need to know if any DIY2 FXs is consuming so much CPU using only its message connections.

Sorry, but I will keep asking about your FXs... because, as I told you, I'm using them a lot.

Thanks!

I think the amount of CPU used by messages should be rather minimal, BUT if you open 50 effects as they are, with the GUI attached, then the GUI redraws from all 50 modules is going to drain a lot of CPU power.

Most of these patches have a subpatch with the audio guts, so if you want to use so many at once, it might be an idea to separate out just the audio section, and then use a generic GUI that can be switched for all your effects. It's a lot of work, i know...but if saving CPU is your goal, then it would be the best way.

mod, I know that GUI consumes CPU... so, the main patch only shows the name of the FX. Look at the PNG.

And, the patch where all the FXs are, is the other capture... and it is a subpatch, inside an abstract (inside the patch that has the blue pad). Also, even each pad isn't modified, it is only a test pad, only with outputs, to use inside the FX.

I also attach a FX abstract example capture.

http://www.pdpatchrepo.info/hurleur/main-patch.png