Best order to put (these) effects in (for a generic (static) guitar setup/effects rack)?

Currently I have them lined up as (or see image below):

noisegate >
pitchshifter >
bodyresonance >
eq13 >
compressor >
waveshaper >
distortion >
filter >
delay+feedback >
reverb

Do you think I have these in the right order/best order (if they can not be swapped out on the fly but do have off|on(bypasses) per effect?

Suggestions for a better layout (using these effects) VERY much welcomed.

Also, as a second item: is there a standard/simple effect I left out that I should include?

Chorus comes to mind, but really given the concept of this being a bare-bones setup I have not included it. Feelings?

Thanks, in advance. Really appreciate your feedback.

Love only,
Scott

Maximo (Guitar Rack) - 6 slots with 1 of 60 effects per slot (using "abs_effects_router" + an OSC controller (MobMuPlat)

maximo.zip

The app is "maximo-help.pd".

maximo is an effects-chain giving the user 6 slots each one of which may be used to select from 1 of 60 effects (the first being "unchanged").

Check her for details about how to use the "abs_effects_router", http://forum.pdpatchrepo.info/topic/10693/abs_effects_router-60-effects-in-one-abstraction-router-from-diy2-stamp-album-my-abs/1 .

It also includes

1. a "maximo/admin.pd" abstraction to control:

dsp, bypass (all), reset (to set all effects to "unchanged"), and 9 presets (0 reserved for program usage) and both save-to-file and load-from-file preset buttons

2. an Open Sound Control (OSC) mapper ("maximo/osc_control.pd") for sending values (0 thru 1) to controls /cc/1 thru /cc/34 (see the patch for details).

and

3. an example OSC (MobMuPlat) controller at "./maximo-osc.mmp" and "./maximo-osc-mmp.pd"

MAXIMO EXAMPLE

MOBMUPLAT INTERFACE

PAGE 1

PAGE 2

PAGE 3

All of this was contingent on the foundation and resources laid out in the DIY2 and Stamp Album collections and actually this was largely an example of persistence not any real insight and the largest percentage of the success goes to their creators for being so diligent about standardizing their abstractions.

I DO however hope you find it useful.

My GOAL was to eliminate what is often the case with effect stacks (I have seen) of having to connect all the effects. This eliminates that and makes it much cleaner: only having to select from the (tof/pmenu POPUP_LIST button) or navigate to the desired effect with the standard "first, previous, next, last" controls.

I hope you find the work useful and capable of helping you to manifest all those wonderful sounds you have in your head.

Peace and only Love,
Scott

The List of Effects per slot is:

abs_effects_router

abs_effects_router_sv.zip

PURPOSE:

to as simply and cleanly as possble allow for the selection of an effect from a large-ish set of effects (currently it contains 60 effects (from the DIY2, Stamp Album, and my own collections (in that order on the lists))).

ARGUMENTS:

There are four creation arguments which identically align with the four messages you can send to the right inlet.

Left inlet is audio signal
Left outlet is audio signal
Middle outlet is effect-name
Right outlet is effect-index (0-indexed).

The four messages/arguments are
$1: index (0-59);
$2: bypass (0-no bypass, 1-bypassed);
$3: param (as a 2 float list, (0-7(int), 0-1 (float)) to set the value for the chosen parameter for the chosen effect;
$4: command either first, previous, next, or last (0, 1, 2, 3) which actually only trigger those identical buttons on the interface.

Optionally effects may be chosen from the POPUP_LIST button(as a pmenu) if you have the "tof" external library loaded which can be found in Deken.

TECHNIQUE:

All of the effects abs are actually loaded when it starts. However each has a [switch~] which is only activated if that index is selected.

They are all housed in "res/abs_PATCHES~_sv.pd" and what is visible is achieved by moving the namedwindow over (a Very carefully) aligned and standardized subwindow for each effect.

The main issue was really standardizing everything, aka. grunt work. Which at the time I desparately needed as my main patch had become sooo abstract it was starting to effect my contentment level ).

FOOTNOTE:

I am currently (and have been) buiding a more complex example of this abs in practice as a 4 stack with RaspPi+Arduino controller (along with HID-keyboard, MIDI, and OSC) to be used as a "Meta" guitar pedal.

However I currently am not yet ready to release that work.

Wanna give a special thanks, to @whale-av for putting me onto the idea about namedwindows which is actually the backbone of this work.

Peace. Let me know if you need anything or have questions and I will do the best I can to answer them.
PD Forever,
svanya

p.s. as I foresee it, what this abs should mean is users can readily drop in not only a single effect abs, but 60 abs all at once, which they can then choose and cross-relate/stack to their hearts content.

p.s.s. I am aware of yet could not resolve the r~/vector size errors which are carry overs from the sympathetic string patch. I have read they do not impact anything, but would like to resolve them if someone can see how. Thanks, in advance.

Thanks, again, everyone who added ideas and moral support.

As I just told my brother the other day: One of the reasons pure data users are so kind is they GET that all mathematics can be mapped on to audio.

-Joy

@reverbanime Ok.... I think I understand.
What you are missing is an identifier for each effect loader...... a number (0 - n) (or 1 - n) that keeps them unique, and that can be passed to the effect that is opened by each loader so that messages can be passed (using that unique identifier) to and from the effect and the loader (that contains the effect).

Because the effects are abstractions $0 will not work.
The effect can be given it's identifier here.......

It needs to be initiated at the creation of the loader, so it would be good if it were $1.

I have built you a system that will work, using an extra blank abstraction "[rack]" to hold the effects.
The effects inherit $1 from each [effectloader] so that the audio is kept separate.
You will need to check your parameter saving as I have stolen $1 for the new numbering system.
Please BACK UP your current folder before playing with this!
effect_loader_test_1.zip

Hmm..... I can never leave it alone......
The delete (old effect) is not working as I expected. I think the effects in the rack will need "place-holders" (sub-patches) so that a [clear( message can be sent instead of using [iemguts/canvasdelete]
Otherwise it is not possible to keep track of the order in which effects are created...........
I will post a new version of the test soon.
David.

UPDATE:

WOW!!! Things have really kicked into high gear, including but not limited to the following:

I built the container for the keyboard:

out of an old board-game box ("Guess Who" game);

made the pedals from (borrowing from Pierre at Guitar Extended) some old Lego Duplo blocks I had;

secured/made a ballast/elevated the backend for the box using wooden blocks I had from when my kids were younger;

secured the whole thing using wood-glue and duct tape.

The "pedals" include in the following arrangement (will include pics prob tomorrow after the final gluing dries):

across the top:

dsp(on|off) (2 small wooden blocks), (the following are from stacks of 3 2x4 legos) bender- (red), benderselect (yellow), bender+ (blue);

bottom section (each made from 6 (in a brick) 2x4 legos): typeselector (red), select- (yellow), select (green), select+ (blue), bypass (black).

Am working on the logic currently to include:

dsp (obvious) (is also going act as a fail-safe in case anything gets out of control);

the benders will: take a single parameter on an effect and incr- or decr-ment it, with the middle button to set the parameter;

the bottom section, will do the same as the bender except

the left-most (red) pedal will

if held (hid key_val=2) longer than x time, set the selectors to adjust the overall sound (i.e. which effects go into which of the 7 slots) by setting a value to between 1 and 10 then selecting that preset;

if held (hid key_val=2) longer than y time, set the selectors to
1 select which slot I want to adjust, meaning the effect in that slot;
2 select a preset (between 1 and 10) for the above slot.

the black-bypass will

depending on the current value of CurrType (Arrangment or Slot), bypass either the whole setup or the Current Slot.

Total Cost for the Whole setup: <10$ and lots of blood and sweat.

note:
Though no tears! (Well, except maybe that 45 minutes I spent in my bathtub with all the lights out, wondering what in the hell point there was to my "work" after I had seen MMB's "gui.eq7.mmb~" (which I very quickly dubbed "The God Filter"). (2 weeks later I had learned enough to implement it

afterward:

When I first (now coming up on nine months ago) saw Pierre's website, I knew, just KNEW, a guitar effects pedal/rack had been put in the reach of not only me, but ANYbody who had little-to-no money if they were just willing to put in the effort.

-peace.
svanya

@monkeyswarm, @0123456789_9876543210:

Thank you, both, for your suggestions.

It IS really good to know better harder eliminates its issues. So that is Great news!

On the down-side, dropping the rate did Not improve performance on my hardware, but trying the app on my son's (better android) the problem is solved.

So it appears power really is the issue.

And using superpowered wouldn't really work as it needs to stay "in-house" meaning as only a mobmuplat add-on with no additions, as that would scare users away.

And while I could use OSC to bypass the handheld entirely and reroute directly to the laptop (which I have done on other incarnations of this app (for personal use) and it worked great) it would undermine the primary requirement of the app:

Get a cool, effective, varied, and useful pedal app into the hands of those guitarists and/or instrumentalists who can not afford "traditional" pedals.

So, next steps:

I need to find out (and perhaps, The Community continuing to beta-test it for me will do the trick) the "Minimum System Requirements" and "Recommended System Requirements" levels.

Currently, I know it's above a Moto LTE (and i'll post back it's cpu speed later) and somewhere potentially below a Nexus 6. Which is really good information.

footnote: I am going to add a delay and a 4-tap to the chain (since it's needs a simple delay not just the hardoff spectral and Guitar Extended's spectral (come to think of it, it only needs one of those, so I'll drop the Guitar Extended one) and have decided with almost everyone probably adding the EQ5 and compressor to the stack, 4 is just not enough slots for additional effects, to add a 7th slider to the main page, bringing the total to 5+the (default-ish) 2.

This is probably going to throw (ah-huh!) Will throw our current knowledge off, so will post an update once I'm done.

Thanks, to both of you, and any and all who chime in on this, as I continue to remain convinced it IS a worthy cause and is a very effective solution to a challenging problem and one well worth pursuing.

2nd footnote:

I do not know how nor have the stamina/time/power/knowledge-base to pursue packaging it as an iphone or android .apk so I'd REALLY appreciate someone to volunteer to do that for us, so we can share in on the two stores/portals. I have NO desire to make ANY money on it and can't anyway given the licenses of the embedded effects. So this would be totally gratis. But VERY much appreciated.

Peace, love, and ever-changing joy,
svanya

To begin, I apologize in advance for this Not being a complete abstraction, so please forgive me for that.

As apology, I offer my humility: 10 hours-straight work later, I know some of what i thought of is beyond my knowledge limit and capacity to continue working on.

That all being said,...

My idea (which I thought would be Very simple, yet learned that PD, no matter how sweet She is, does not behave like the linux shell) was simple:

Make a rack of a set of vradios (i chose 8 due to the cpu limit on my laptop, but more could easily be added) which each denote a set of effects;

Send the results to a shell control along with the "slot" in the stack;

Have it copy that effect into an eff(ects)/tmp folder (mapping over the dummy files that were there),

so when the adc~ > eff1 > eff2, etc., chain runs they would be loaded as copies of the desired effects abstractions.

My intention was to empower the usage of multiple instances of the same effects abstractions as well as cut the wiring required in many/my pedal rack/s I have seen to almost nil.

That Was accomplished.

And I DO like the "idea".

On the other hand, I learned, to my chagrin, 2 VERY important lessons:

1. pd loads all subpatches on startup
   and
2. there is no (this is were I bow to higher minds than myself) way to "refresh" the patch, shy of closing and reopening it (because while you can do this sort of thing in linux, you can not in pd "underwrite" a subpatch and presume it will know the change has been made).

I Did pursue trying to load via "cat" the effect file-contents into a pd (sub)patch object, but could not figure out how to make that work, even with subtracting the file accouterments, i.e.#X, #N.

In closing I will say that the goal, though only partially achieved, IS one worth pursuing if it is a domain you are more knowledgeable about than myself.

I have attached a zip of my work.

It includes:

a shell script to start extended (it must be started this way, if the shell object is to know where the resource folder is located;

a folder, "res", which includes: /effs (where you put your effects abstractions), /effs_tmp (with 8 dummy files, where your effs get copied to), and /helper (where Mother is located)

and

a Mother_effsmap.txt file, where you list your effects, by filename (including the ".pd" extension", which it cross-references the vradio index to the line number on the file to know which file to copy.

Also,
I have found that it does copy correctly, but then you are left with the stack of controls to contend with. But I have yet to figure that out and think it better to go ahead and share it.

-peace, thanks for listening, and I hope it gives you some new ideas to work with.

svanya

Mother.zip

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

No time like the present to get started so I am going to go ahead and post the initial-ish sort of work I have done (see YouTube link below) using the guitar pedal patch I am now using.

It started out, that is to say, I initially envisioned it as a MobMuPlat guitar pedal app. But having spent 4 months attempting to make it work to no avail I opted out of that and just settled on using my laptop. The Android I had was too slow or my knowledge base was not large enough to make it happen.

The pedal rig uses mainly DIY2 pedals and some Guitar Extended stuff.

It's primary functional piece is a 4 tap delay with a pitchshifter per line. Makes some amazing sounds: guitar in 4 voices. And my hope is to post that patch as soon as I can.

Hope you enjoy the listen. May it find you in good cheer.

-s

p.s. some of the pieces do not use much of effects and they are all improv pieces which is the only thing I do.

oh, yea: i did some post work on Audacity: noise removal, remove clips, normalize, but that is about it. And my youtube channel is almost all live improv poetry and music.

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.