Hell, 5:30 in the morning; can't sleep; nervous about "tomorrow", aka. later in the day, might as well get up and do some good.

The video below shows the latest incarnation of my guitar "pedals" concept:

It is an android mounted (temporarily (will be velcro, right now just duck tape) to the front face of my guitar;
on it is MobMuPlat;
the MobMuPlat app I added is an Open Sound Controller frontend connected to my laptop
on my laptop is a pretty bare -bones guitar rig: vcompander (mainly as a noisegate), in&out compressors, my recording abstraction + eq13 (eq with my presets abstraction);
and between the two compressors (which use and require the tb_peakcomp~ external) (the second one is there in case the main plugin gets out of control)
is
my four-tap/pitchshifter-per-line delay abstraction.

The goal (only took a maiden voyage so far) is to learn how to strum and adjust the sliders on the mobmuplat in the same rhythm/timing as I strum and pick.

So pick strings and change settings in the same style and rhythm as I play. So play "effects" in the same moment I am playing guitar.

I am using that 4tappshifter because it has the most radical effects with the least amount of adjustments, plus I just think it just sounds cool.

Test tracks of this rig will be coming out soon, when I can get the time/space etc etc to produce them.

I expect, from one test drive, it is gonna be a pretty steep curve to learn.

I'll zip the whole rig (tho bear in mind it is NOT perfect and has no help files) and put it below.

Ciao! And thanks for listening. Hope it gave you some ideas.

-svanya

p.s. I have and am holding onto the notion of pure data as an "organic" tool, which while it IS capable of being VERY conceptual (and I have even done some works like that) I want for my purposes at least it to stay Close to the Chest, and has been mentioned elsewhere in the forum, NOT be Pre-Music. I think it is fully capable of fulfilling both roles: conceptual/electronica And organic.

And for me, be music as I Feel it not think about it.

Hence, the front-mount and not a stomp box. Also, I Really do NOT want preset voices. I want the voices to change as I change my playing/style.

And while I have experimented with other control-types, mice, keyboard, hid, etc, none of them have come Anywhere close to the amount, variety, and subtlety of tones, styles, and rhythms I can get from my guitar.

So I am holding to the Idea that I will be able to "bend" strings" and "bend" effects in the same moment and on my chosen instrument.

p.s.s. I know no explanation is not needed, but I wanted to hear what it sounded like to see if it rang true for me. Yep. It does.

Oh, and I did not include the tb_peakcomp~ external, but it's pretty easy to get.

-peace

4tapPShift Controller.zip

Video showing the rig mounted on my guitar

Hey, mod... I post here a thread in pd-list, because I want to use your compressor... and I want your opinion.

For my live looping-system, I do beatbox, using a Shure58. The mic has very good quality, but I realized that the kicks and snares, are recorded very loud (max signal = 4). So, I want to use a compressor (I though using tanh(), but some people told me that it distorts a lot and extra harmonics).

I want to use your compressor (almost my FXs uses DIY2 effects). After several tests, I concluded that it is very difficult to compress the first peak of a kick, for example. Then, the audio is compressed... but the first peak is still there.

When trying to save the original sound to disk, Pd has to normalize from 4 to 1. And, compressed with your compressor, too: 4 to 1 (more or less).

So, I thought about using the compressor with attack and release at lowest and then, for those peaks, use something like [expr~ (tanh($v1/1.5))*1.5], not to cut to 1, but 1.5. So, It don't distort the sound so much.

What do you think?

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

@mod said:

But time and time again we see the same sort of posts. People who just want to turn an audio signal on and off use something like [spigot~], people use [counter] instead of basic pd objects. They post these patches and run into trouble that could easily be avoided by only using vanilla objects unless necessary.

What's wrong with [counter]? Objects like those remedy the trouble of trying to figure out how to make one using only vanilla objects. Not that it's particularly difficult to do, but it may just be more intuitive or time saving to someone to use [counter].

Of course most people are using extended, but it's such a vast ocean that no-one knows how EVERY object in extended works. The object in question here, [gate], i can only hazard a guess, but i'm thinking that a maximum of 50% of users know the cyclone library and in particular the [gate] object well enough to debug a patch.

Well, that's where the basic advice that you and others have posted comes in: Right click -> Help.

Besides, I don't really think that because less people know or use an object should deter one from trying it. It may just make more sense or fit with their particular programming preferences. I know I like to build from low-level objects and work up, but not everyone is so interested. For example, I've built my own compressor abstraction. But plenty of other people would rather just load a compressor object and be done with it. Nothing wrong with either approach.

Also, I've been using Pd long enough that I feel comfortable saying I'm in "expert" territory. I don't know what every extended object does, but I don't know what EVERY vanilla object does, either.

(I'm speaking from my own bad experiences here too, because my old patches had some extended objects in them, and i answered countless emails from people having trouble with those externals not loading. I could have saved myself a lot of time by just using the correct vanilla constructs in the first place)

Now, this is a different issue, and I'm more inclined to agree here. You can definitely ensure higher compatibility by sticking to vanilla objects, as some externals don't work correctly on all OS's and vanilla users may not have some of the more popular libraries installed, but it does come with the potential costs of flexibility or computational load. And, this is only an issue if you want to share your patches or use them on other OS's.

When I'm writing a patch that's for personal use only, and I don't expect to be sharing it, I tend to use whatever I want. But if I'm making an abstraction I might share, I usually follow an order of precedence:

1. Use vanilla objects where possible/practical for best compatibility.
2. Use extended objects if needed, since it's used widely and newbie-friendly.
3. If absolutely necessary, use a popular lib not included in Pd-extended, like GridFlow or RjLib (I've never had to do this, yet).

But that's entirely for compatibility reasons only.

@Shakasin said:

But is there something in vanilla that could replace my [gate] just curious ?

. [== 1] [== 2] [== 3]
| | |
[spigot] [spigot] [spigot] etc....

Connect the gate number to the left inlet of the [== ] objects, and the value you want to pass to the left inlet of the [spigot]s.

I was thinking more of the actual components of the compressor circuit, and how they won't behave as expected, certainly as they get hot they begin behaving differently.
If you are modeling a compressor with valves would be different to solid state, and I don't know how you'd go about modeling valves.
I suppose what I'm trying to say is your bog standard digital 1 pole filter response is a straight line, whereas the analogue equivalent would not be a perfect straight line, as the resistors and capacitors themselves don't behave linearly, and don't have a <perfect>linear relationship. And also, [tanh~] would create a saturation effect, but not one that sounds truly analogue, as the response of a real overdrive pedal would not be a perfect [tanh~] line.
I've never found any decent papers on Analogue Modeling, which is annoying, especially as it is such an important part of contemporary DSP.
I'm pretty interested in this topic myself now, it would be useful to be able to model electronic circuits in Pd

I don't think modeling an analog-style compressor in Pd would be as difficult as building something like a Moog filter. The problem with making the filter in Pd is that it would need one-sample feedback loops, which can be done with [block~ 1] but is also cpu intensive. I don't know exactly what it is about analog compressors that give them their distinctive sound, but I do know that compressors don't have a feedback portion to them. All compressors, analog or digital, are non-linear, so non-linearity in and of itself isn't an issue.

It will probably be a waste of time trying to faithfully model the compressor in Pd, it's easy to create a simple compressor, but what you need to do is physically model the circuitry. This will mean all the non-linearities present in the circuit will be recreated, and the compressor will sound like a real analogue compressor. I wanted to model analogue filters in Pd, but it can't be done, what people have done in the past is written them in C and compiled them into externals.

That's if you wanted to do a realistic imitation of it, which for a uni project I assume you would want to do. Analogue modeling is a difficult one, I just completed a uni project on physical modeling of a guitar using Pd and I wanted to model a Moog filter to pass the guitar signal through, but I can't write in C.

Actually, I remember reading a thesis where someone modeled the tone controls of a guitar in C, and to get a difference equation for a filter they built the circuit in SPICE, which is freeware for PC, but there is a Mac version. Once you build the circuit it plots graphs of the output, and you can swap around components. I don't know if that's any help, but it could be a start seeing as I assume you built it yourself so will have the circuit diagrams for it.

It is a topic worth discussing. In my experience most people programming in PD do not have a software engineering background and end up doing a lot of things that are frowned upon by software engineers, eg: unmaintainable copy-past code, always starting from scratch, monolithic code.

A the end of they day though we shouldn't just apply higher level SE principals just for the sake of it, it should be done to help us be more productive and efficient in writing our code. One thing that I've personally found useful is decoupling programing interface from implementation code. Basically I'll create an abstraction with an expected number of arguments and certain inlets and outlets for a doing a job and then several different abstractions for doing that job. As an example I'll create a compressor abstraction that is instantiated like this:

|
[compressor name ratio threshold attack release]
|

The guts of this object would look like this:

[inlet]
|
[$1Compressor $2 $3 $4 $5]
|
[outlet]

So in order to work there must exist in PD's path an patch called nameCompressor.pd. This patch would then hold the implementation details for a particular kind of compressor. The advantage of coding like this is that it allows your code to be modular. I can have a few different algorithms (linear, non-linear, with or without antialiasing, etc) but since the patches deal with them through the compressor abstraction it becomes very easy to plug them in and out of my existing projects without breaking anything. It also forces me to develop any future compression patch to work with this interface for the same reason, ease of using it with my existing projects.

The example I gave here is pretty trivial. When we start dealing with varied controllers (midi, keyboard/pointer, osc, netsend) the advantages become more obvious. You can create a new instrument (synthesizer, sampler, etc) and easily change the controlling device without having to directly change the code of the instrument itself precisely because the code that handles the input from the controller is decoupled from the patch that is using that input.

Arif, I collected info on analytic signals (also called complex signals) on my page

http://www.katjaas.nl/hilbert/hilbert.html

If you are interested in compressor design in the digital domain, you should probably treat my technique as a curiosity, because it is highly experimental. I just modeled [qompander~] according to my needs, which are: fast response, expander/compressor/limiter in one operation.

The zexy library in Pd extended has [limiter~] which also does compression so you could have a look at it's source code as well.

Katja

@domien said:

For the moment I'm using the freeware audiodamage roughrider (just the default preset) and jeroen breebaert's freeware brickwall limitter. I really love the sound of the compressor when I drive things real hard they will start fighting each other which can cause padz to only get partially through (probably on the frequencies which the rythmic stuff leaves open)...

ok, so you're actually using the compressor "musically". then i would DEFINITELY do it myself on stage, soft OR hardware.. most sound guys hate the superpumping "daftpunk"-compression anyway, as it's "wrong" as far as traditional compression goes...

if you're using the "pumping" effect a lot, be sure to pick up a model with ability to adjust attack- and release-times.

if i remember right, the rough rider is a one-band model, meaning so it compresses the whole sound spectrum as one. so the pads fade out 'cause there's something louder happening, not necessary on a different frequency. propably bassdrum or snare.

some kind of brickwall limiter is always nice to have at the end of your chain, but not 100% necessary in a live situation, if you already have some kind of compression involved. and some people actually like the sound of da-converter clipping. after all, that's just one kind of brick limiter..