Can you run a [line~] on 2 [switch~]s so it transitions gradually?
Thanks, for getting back with me @whale-av (in usual punctual fashion ).
I thought that might be the case.
However in my desparation I came up with a solution to the specific problem that actually works even better:
My effects-router uses a hradio to choose the effect;
each effect had a switch~;
All of the effects outputs are sent to throw~s.
What I wanted (and the pic below shows what I did) was a cross-fade effect. So as one effect goes out and the other one comes in they blend.
By just dropping in (where my switches were) the abs_fadeswitch~ and adding two global sends, GlobalInitLevel and GlobalFade (up to 1000ms), I was able to get really nice smooth transitions as I made the changes without too much cpu loss.
Thanks, again, for your timely input. Glad I plowed ahead as well.
Peace and love to and thru you (and the rest of us),
S
Andúril (MobMuPlat app): fwd/bwd looper + 14 effects + elven cloak (control parameters via env~ and pitch as you play)
Andúril (MobMuPlat app): fwd/bwd looper + 14 effects + elven cloak (control parameters via env~ and pitch as you play)
UPDATED VERSION (corrected MobMuPlat system crash problem):
anduril.zip
This has been long in coming and I am very glad to finally release it (even tho my handheld hardware is not up to the job of running the elven cloak feature).
First a demo video and some screenshots, , and then the instructions.
DEMO VIDEO
SCREENSHOTS
Intention(s):
The app is designed to give (specifically a guitarist) tho really any input (even prerecorded as is the case in the demo (from: "Laura DeNardis Performing Pachabels Canon" from https://archive.org/details/LauraDenardisPerformingPachabelsCanon, specifically the wave file at: https://archive.org/download/LauraDenardisPerformingPachabelsCanon/PachabelsCanon.wav, Attribution-Noncommercial-Share Alike 3.0) FULL Control over the "voice" of their output-sound.
It includes:
a 5-band EQ (on page 2 of the app) (upfront that is applied to all incoming sounds);
a looper: with record, forward, backward, speed, and bypass controls (that runs via a throw along with the effects channel)
14 effects each with 3 controllable parameters (via the xy-slider+centered knob) including: chorus, distortion, delay, reverb, flanger, tremolo, vibrato, vcf, pitchshifter, pitchdelay, 12string, stepvibrato, pushdelay (delayfb driven by magnitude of the env~), and stagdelay (2 out-of-sync delay lines which can be driven in and out of phase by the sum of their delwrite+vd's so what goes in first may come out last)
elven_cloak: which drives the 3 parameter controls via the peak bands amplitude and proximity to a set pitch (midi note) and whose window can be broadened or shrunk and shifted within that window, i.e. the three effect parameters are changed automatically according to what and how you play
and
a tester synth: that randomly sends midi pitches between 20-108, velocities between 20-127, and durations between 250-500ms.
CONTROLS (from top-left to bottom-right):
PAGE 1:
Effect: effects menu where the you choose an effect;
>>>,<<<: page navigation buttons;
IN,OUT: gains (IN is the preamp on the EQ5, and OUT is applied to total output);
REC,FWD,BWD,speed,normspd: the looper toggles and on speed, higher is faster and mid normal and normspd resets to mid;
xy-slider+centered knob: the 3 parameter controls + their labels (the bottom is x, top y and above the knob for the third one), the name of the selected effect and its parameters load each time you choose from the Effects menu, bottom left is lowest, top-right highest;
ByLp,ByEff: bypasses for the looper and effects "channel" (the outputs are summed);
EC-on: elven cloak toggle (default=off);
PAGE 2:
the EQ5 controls;
synthtest: off|on, default is off;
PAGE 3: elven cloak controls
reset: sets shift, metro, mid, and radius to 0, 500(ms),64,100% respectively (i.e. the entire midispectrum, 0-127) respectively;
mini-xyz, test: if test is on, you see a miniature representation of the xyz controls on the first page, so you can calibrate the cloak to your desired values;
shift: throws the center of the range to either the left or right(+/-1);
metro: how frequently in milliseconds to take env~ readings;
mid: the center in midipitch, i.e. 0-127, of the "watched" bands
radius(%): the width of the total bands to watch as a percentage of whichever is lower 1-mid or mid
END CONTROLS
Basic Logic:
There are 4 modes according to the bypass state of the looper and effects.
A throw catch and gain/sum/divide is applied accordingly.
End:
As I mentioned at the first, my handheld(s) are not good enough to let me use this but it runs great on my laptop.
So...
I would love to hear if this Does or Does Not work for others and even better any output others might make using it. I am enormously curious to hear what is "possible" with it.
Presets have not (yet been included as I see it, esp. with the cloak as a tool to be used for improv and less set work. Tho I think it will work nicely for that too if you just turn the cloak off.
hmmm, hmmm,...
I think that's about it.
Let me know if you need any help, suggestions, ideas, explanations, etc. etc. etc. regarding the tool. I would be more than happy to share what I learned.
Peace, Love, and Ever-Lasting Music.
Sincerely,
Scott
p.s. please let me know if I did not handle the "attribution" part of "Laura DeNardis Performing Pachabels Canon" License correctly and I will correct it immediately.
Ciao, for now. Happy PD-ing!
Audio Ideas (AI) Collection (placeholder, currently only links)-effects, controllers, mmp, etc.
Audio Ideas (AI) Collection (placeholder) currently only links
per @LiamG 's kind suggestion I have begun the process of consolidating my abs and patches, etc. into a single location/zip file or for possible upload to github.
Just to get the ball/me rolling and scope the work I got the links for my shares into a single location to later be consolidated into the single AI Collection.
For now at least, please, bare with me (and the links below) as ideas I am more passionate about currently are demanding my attention. (Which funnily enough will probably also be included in the set, where ever they are shared.)
Thanks, for your patience and all you do for the Pure Data Family.
Sincerely,
Scott
abstract~
pushdelay-envelope-env-driven-delay-line-with-both-delay-time-and-feedback-dependent
numpad-abstraction-for-entry-of-large-numbers-via-click-instead-of-sliders-includes-basic-calculator
abs_delay_fbw-feedbackwards-lifo-last-in-first-out-delay
abs_sequences_by_formula-sequences-by-formula-abstraction-ex-collatz
abs_effects_router-60-effects-in-one-abstraction-router-from-diy2-stamp-album-my-abs
visualcontrolsurface-vsl-values-set-by-their-location-on-the-screen-req-ggee-shell
abs_4-8-14_way_toggle-pair-2-toggles-resulting-in-4-8-or-14-states
audioflow-delay-to-forward-backward-looper-using-speed-control
5-band-equalizer-with-bezier-controller-eq5_mey_w_bezier_sv-pd-updated-to-8-band-below
forward-backward-looper-orig-abs-from-residuum-whale-av
abs_rgb2hex-rgb-0-255-colors-to-hexadecimal-values
pseudo-12-string-effect-6-string-guitar-to-sound-like-a-12-string
jack_midi2pd_2sys_connector_sv-jack-midi_out-to-pd-sys_playback-switcher
abs_4to16pads_bin_conv_sv-convert-4-midi-pads-from-a-binary-value-to-a-decimal-for-rerouting
abs_automatedslider_sv-automated-control-changer-pd-and-mobmuplat-editor-versions
idea-for-effects-stack-ing-technique-control-mother
micin-_abs-abstraction-convert-signal-to-notein-ex-using-a-midi-synth-as-a-guitar-pedal
curve_abs-tri-way-curve-switch-to-change-control-values-in-either-linearly-convex-or-concave-manner
a-preset-control-abstraction-for-saving-parameters-presets-to-text-files
4-tap-delay-with-pitch-shifter-per-delay-line-adaptation-of-diy2-patches
patch~
extra
the-15-owl-faust-patches-compiled-as-32bit-linux-externals-attached
libpd
mmponboardeditortemplate-mmp-for-creation-of-mobmuplat-files-directly-on-the-handheld-android-only
3d-synth-webpd-tree-js-webgl_camera_cinematic-html-example
Off topic
Best order to put (these) effects in (for a generic (static) guitar setup/effects rack)?
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 (Guitar Rack) - 6 slots with 1 of 60 effects per slot (using "abs_effects_router" + an OSC controller (MobMuPlat)
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
- 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
- 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
- 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 (60 effects in one abstraction router) (from DIY2, Stamp Album, my abs)
abs_effects_router
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
Opening a PD patch as a subpatch using [openpanel]
@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.
Idea for Effects Stack(ing) Technique/Control ("Mother")
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:
- pd loads all subpatches on startup
and - 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
Loading patches on the fly
Short:
How does one change an object on the fly? E.g. I have effect1_patch~ as an object, but I want to change it to effect2_patch~ , effect99_patch~, or any arbitrary patch in order to switch between my library of effects during performance (without hard coding each effect into the main program).
Long:
So I am making a live performance setup.
The pipeline I have set up now within my main PD program is: read mic/midi --> effects --> looper --> mixer --> out
The problem is I have a lot of different effects patches already and plan to have many more. The ideal would be that my effects program takes a midi input and dynamically loads a corresponding patch. I know how to handle the midi input, but is there an easy way to do dynamic loading of patches i.e. changing the patch a PD object refers to on the fly?
Thanks for your help!!
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.