Hello,

this is going to be a long one.
After years of using PD, I am still confused about its' timing and schedueling.

I have collected many snippets from here and there about this topic,
-wich all together are really confusing to me.

*I think it is very important to understand how timing works in detail for low-level programming … *

(For example the number of heavy jittering sequencers in hard and software make me wonder what sequencers are made actually for ? lol )

This is a collection of my findings regarding this topic, a bit messy and with confused questions.

I hope we can shed some light on this.

---

• a)
  The first time, I had issues with the PD-scheduler vs. how I thought my patch should work is described here:
  https://forum.pdpatchrepo.info/topic/11615/bang-bug-when-block-1-1-1-bang-on-every-sample

The answers where:

„
[...] it's just that messages actually only process every 64 samples at the least. You can get a bang every sample with [metro 1 1 samp] but it should be noted that most pd message objects only interact with each other at 64-sample boundaries, there are some that use the elapsed logical time to get times in between though (like vsnapshot~)
also this seems like a very inefficient way to do per-sample processing..
https://github.com/sebshader/shadylib http://www.openprocessing.org/user/29118
seb-harmonik.ar posted about a year ago , last edited by seb-harmonik.ar about a year ago 
• 1 
 whale-av 
@lacuna An excellent simple explanation from @seb-harmonik.ar.
Chapter 2.5 onwards for more info....... http://puredata.info/docs/manuals/pd/x2.htm
David.
“

There is written: http://puredata.info/docs/manuals/pd/x2.htm

„2.5. scheduling 
Pd uses 64-bit floating point numbers to represent time, providing sample accuracy and essentially never overflowing. Time appears to the user in milliseconds. 
2.5.1. audio and messages 
Audio and message processing are interleaved in Pd. Audio processing is scheduled every 64 samples at Pd's sample rate; at 44100 Hz. this gives a period of 1.45 milliseconds. You may turn DSP computation on and off by sending the "pd" object the messages "dsp 1" and "dsp 0." 
In the intervals between, delays might time out or external conditions might arise (incoming MIDI, mouse clicks, or whatnot). These may cause a cascade of depth-first message passing; each such message cascade is completely run out before the next message or DSP tick is computed. Messages are never passed to objects during a DSP tick; the ticks are atomic and parameter changes sent to different objects in any given message cascade take effect simultaneously. 
In the middle of a message cascade you may schedule another one at a delay of zero. This delayed cascade happens after the present cascade has finished, but at the same logical time. 
2.5.2. computation load 
The Pd scheduler maintains a (user-specified) lead on its computations; that is, it tries to keep ahead of real time by a small amount in order to be able to absorb unpredictable, momentary increases in computation time. This is specified using the "audiobuffer" or "frags" command line flags (see getting Pd to run ). 
If Pd gets late with respect to real time, gaps (either occasional or frequent) will appear in both the input and output audio streams. On the other hand, disk strewaming objects will work correctly, so that you may use Pd as a batch program with soundfile input and/or output. The "-nogui" and "-send" startup flags are provided to aid in doing this. 
Pd's "realtime" computations compete for CPU time with its own GUI, which runs as a separate process. A flow control mechanism will be provided someday to prevent this from causing trouble, but it is in any case wise to avoid having too much drawing going on while Pd is trying to make sound. If a subwindow is closed, Pd suspends sending the GUI update messages for it; but not so for miniaturized windows as of version 0.32. You should really close them when you aren't using them. 
2.5.3. determinism 
All message cascades that are scheduled (via "delay" and its relatives) to happen before a given audio tick will happen as scheduled regardless of whether Pd as a whole is running on time; in other words, calculation is never reordered for any real-time considerations. This is done in order to make Pd's operation deterministic. 
If a message cascade is started by an external event, a time tag is given it. These time tags are guaranteed to be consistent with the times at which timeouts are scheduled and DSP ticks are computed; i.e., time never decreases. (However, either Pd or a hardware driver may lie about the physical time an input arrives; this depends on the operating system.) "Timer" objects which meaure time intervals measure them in terms of the logical time stamps of the message cascades, so that timing a "delay" object always gives exactly the theoretical value. (There is, however, a "realtime" object that measures real time, with nondeterministic results.) 
If two message cascades are scheduled for the same logical time, they are carried out in the order they were scheduled. 
“ 

[block~ smaller then 64] doesn't change the interval of message-control-domain-calculation?,
Only the size of the audio-samples calculated at once is decreased?
Is this the reason [block~] should always be … 128 64 32 16 8 4 2 1, nothing inbetween, because else it would mess with the calculation every 64 samples?
How do I know which messages are handeled inbetween smaller blocksizes the 64 and which are not?

How does [vline~] execute?
Does it calculate between sample 64 and 65 a ramp of samples with a delay beforehand, calculated in samples, too - running like a "stupid array" in audio-rate?

While sample 1-64 are running, PD does audio only?

[metro 1 1 samp]  

How could I have known that? The helpfile doesn't mention this. EDIT: yes, it does.
(Offtopic: actually the whole forum is full of pd-vocabular-questions)
How is this calculation being done?
But you can „use“ the metro counts every 64 samples only, don't you?

Is the timing of [metro] exact? Will the milliseconds dialed in be on point or jittering with the 64 samples interval?
Even if it is exact the upcoming calculation will happen in that 64 sample frame!?

---

• b )
  
  There are [phasor~], [vphasor~] and [vphasor2~] … and [vsamphold~]
  https://forum.pdpatchrepo.info/topic/10192/vphasor-and-vphasor2-subsample-accurate-phasors

“Ive been getting back into Pd lately and have been messing around with some granular stuff. A few years ago I posted a [vphasor.mmb~] abstraction that made the phase reset of [phasor~] sample-accurate using vanilla objects. Unfortunately, I'm finding that with pitch-synchronous granular synthesis, sample accuracy isn't accurate enough. There's still a little jitter that causes a little bit of noise. So I went ahead and made an external to fix this issue, and I know a lot of people have wanted this so I thought I'd share. 
[vphasor~] acts just like [phasor~], except the phase resets with subsample accuracy at the moment the message is sent. I think it's about as accurate as Pd will allow, though I don't pretend to be an expert C programmer or know Pd's api that well. But it seems to be about as accurate as [vline~]. (Actually, I've found that [vline~] starts its ramp a sample early, which is some unexpected behavior.)
[…]
“

---

• c)
  
  Later I discovered that PD has jittery Midi because it doesn't handle Midi at a higher priority then everything else (GUI, OSC, message-domain ect.)

EDIT:
Tryed roundtrip-midi-messages with -nogui flag:
still some jitter.
Didn't try -nosleep flag yet (see below)

---

• d)
  
  So I looked into the sources of PD:

scheduler with m_mainloop()
https://github.com/pure-data/pure-data/blob/master/src/m_sched.c

And found this paper

Scheduler explained (in German): 

https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view

wich explains the interleaving of control and audio domain as in the text of @seb-harmonik.ar with some drawings
plus the distinction between the two (control vs audio / realtime vs logical time / xruns vs burst batch processing).
And the "timestamping objects" listed below.

And the mainloop:

Loop
- messages (var.duration)
- dsp (rel.const.duration)
- sleep

With
[block~ 1 1 1]
calculations in the control-domain are done between every sample? But there is still a 64 sample interval somehow?
Why is [block~ 1 1 1] more expensive? The amount of data is the same!? Is this the overhead which makes the difference? Calling up operations ect.?

---

Timing-relevant objects
from iemlib:

[...]
iem_blocksize~   blocksize of a window in samples
iem_samplerate~  samplerate of a window in Hertz 


------------------ t3~ - time-tagged-trigger --------------------
-- inputmessages allow a sample-accurate access to signalshape --
t3_sig~          time tagged trigger sig~
t3_line~         time tagged trigger line~


--------------- t3 - time-tagged-trigger  ---------------------
----------- a time-tag is prepended to each message -----------
----- so these objects allow a sample-accurate access to ------
---------- the signal-objects t3_sig~ and t3_line~ ------------
t3_bpe           time tagged trigger break point envelope
t3_delay         time tagged trigger delay
t3_metro         time tagged trigger metronom
t3_timer         time tagged trigger timer

[...]

What are different use-cases of [line~] [vline~] and [t3_line~]?
And of [phasor~] [vphasor~] and [vphasor2~]?

When should I use [block~ 1 1 1] and when shouldn't I?

[line~] starts at block boundaries defined with [block~] and ends in exact timing?
[vline~] starts the line within the block?
and [t3_line~]???? Are they some kind of interrupt? Shortcutting within sheduling???

---

• c) again)
  

https://forum.pdpatchrepo.info/topic/1114/smooth-midi-clock-jitter/2

I read this in the html help for Pd: 
„
MIDI and sleepgrain
In Linux, if you ask for "pd -midioutdev 1" for instance, you get /dev/midi0 or /dev/midi00 (or even /dev/midi). "-midioutdev 45" would be /dev/midi44. In NT, device number 0 is the "MIDI mapper", which is the default MIDI device you selected from the control panel; counting from one, the device numbers are card numbers as listed by "pd -listdev."
The "sleepgrain" controls how long (in milliseconds) Pd sleeps between periods of computation. This is normally the audio buffer divided by 4, but no less than 0.1 and no more than 5. On most OSes, ingoing and outgoing MIDI is quantized to this value, so if you care about MIDI timing, reduce this to 1 or less.
„

Why is there the „sleep-time“ of PD? For energy-saving??????
This seems to slow down the whole process-chain?

Can I control this with a startup flag or from withing PD? Or only in the sources?

There is a startup-flag for loading a different scheduler, wich is not documented how to use.

---

• e)
  
  [pd~] helpfile says:

ATTENTION: DSP must be running in this process for the sub-process to run. This is because its clock is slaved to audio I/O it gets from us!

Doesn't [pd~] work within a Camomile plugin!?

How are things scheduled in Camomile? How is the communication with the DAW handled?

---

• f)
  
  and slightly off-topic:
  There is a batch mode:
  https://forum.pdpatchrepo.info/topic/11776/sigmund-fiddle-or-helmholtz-faster-than-realtime/9

---

EDIT:

• g)
  I didn't look into it, but there is:
  https://grrrr.org/research/software/

clk – Syncable clocking objects for Pure Data and Max
This library implements a number of objects for highly precise and persistently stable timing, e.g. for the control of long-lasting sound installations or other complex time-related processes.

---

Sorry for the mess!
Could you please help me to sort things a bit? Mabye some real-world examples would help, too.

@whale-av, here is a log running pd with -lib Gem -verbose.
tried both 32bit and 64bit pd 0.48-1...

tried ./Gem.m_i386 and failed
tried ./Gem.dll and failed
tried ./Gem/Gem.m_i386 and failed
tried ./Gem/Gem.dll and failed
tried ./Gem.pd and failed
tried ./Gem.pat and failed
tried ./Gem/Gem.pd and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.dll and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.dll and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.pd and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.pat and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.pd and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.dll and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.dll and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.pd and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.pat and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.pd and failed
tried C:/Program Files/Common Files/Pd/Gem.m_i386 and failed
tried C:/Program Files/Common Files/Pd/Gem.dll and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.m_i386 and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.dll and failed
tried C:/Program Files/Common Files/Pd/Gem.pd and failed
tried C:/Program Files/Common Files/Pd/Gem.pat and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.dll and succeeded
D:\\pd-0.48-1.windows.64bit\\extra\\Gem\\Gem.dll: couldn't load
tried D:/pd-0.48-1.windows.64bit/extra/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.pat and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.pat and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.pd and failed
Gem: can't load library```

@s.elliot.perez "comb filter" refers to 2 simple delays: 1 where you delay the incoming signal, multiply it, and add it to itself (no feedback) and 1 where you take the output, delay it, multiply it and then add it to the input to create the new output (this is the classic "echo" effect and what we generally think of when we think of the "delay" effect with feedback)

the fundamental frequency is equal to the inverse of the delay length (e.g. if your delay length is 1 ms your frequency will be 1000 hz). I don't think the bandpass filters should affect it too much.

in this situation, the delays are feeding back into each other so it's more complex than a simple comb filter. However, the frequencies should still depend on the delay times like that.

Interesting side note: all digital filters can be deconstructed into these 2 simple building blocks, except that they use 1 sample instead of milliseconds or seconds. The feed forward one is called a "zero" and the feedback one is a "pole". This is because the space between the peaks of the comb filter is the inverse of the delay time. So, if you set the delay time to 1 sample you get a "peak" width of the entire spectrum up to the sample rate.

I think you did it right, but you might need to lower your block size within a subpatch to get lower delay times than 64 samples (~1.45 ms @44.1k) also.. and/or do the stuff in the helpfiles G04.control.blocksize.pd and G05.execution.order.pd where you can

@weightless said:

@bocanegra https://forum.pdpatchrepo.info/topic/5349/patching-a-good-reverb/6
not from me, but reverbCH~ and reverb282~ from @acreil are by far the best Pd reverbs I've heard.

Thanks for replying. I'll check those out. I'm not big on having to install externals tho. Also, I've been trhotugh the algortithms mentioned in the thread.

I was kinda hoping we could have a discussion about reverberation that will provide techniques for newbs rather than go on about our fave this and that. But maybe I started off wrong by showing of my mutant...

Under all circumstances, here is my experience modelling reverb in short:

While freeverb sucks (sorry), Schoeder is your friend. The trick is to find a way of recycling you allpass series (or even better, nests!) that makes sense to your ears. Dattoro's work is pretty much that. If you look at his "tank" section of his first plate verb emulation, that's what it does, very cleverly so: it creates a simple feedback matrix of phased out echoes bouncing back and forth. My jVerb is in many ways an elaborate Dattoro tank.

Now, you can build reverb tanks in many ways. The jVerb is extremely heavy on CPU (but gaaawd I love the sound). A simple way is having two lines going through a series of N allpass nests and having the two lines feedback into each other like ping pong delay. If you tune the allpass filters right (primes!!!) and add some tiny modulation to delay times you are rid of eigentones or whatever they are called.

I'll make the effort to describe how a Schroeder allpass nest is constructed (no math):

You put three allpass filters in series and give them Z coefficients (that is delay in samples) of dimishing magnitude, following some log rule or another. Schroeder liked to approximate 1/3 for each allpass. MAKING SURE THEY ARE ALL PRIMES!!!

Then you put that chain inside the loop of another allpass filter, and tune it's Z to fit the series in such a way that the outer loop has the highest Z.

A single allpass nest can pass for primitive reverberation with the right tweaking. A handful in series will create a lot of diffusion and sound better (less echo-y). BUT: Make sure every nest has it's unique series of Z values.

Then add low frequency modulators to the Z value (delay time) on each and every allpass loop. Random values are preferable over sinusoids or any other periodical thing. The APN abstractions I used in jVerb have all this built in already.

What's left is to add some pre-delay if you like that, and some bandlimiting somewhere in the feedback loop.

I have a CPU friendly verb following this scheme somewhere. I'll upload it ASAP

Here is an updated version
arguscore-update.zip
and a few Purr Data compatibility replacement objects: purr-data-compatible-replacements.zip

A creation argument only object driven system for instant music making;
Objects so far;
Required;
globaltimer  - outputs a 10ms bang to drive all objects;
globalsync   - resets all objects to zero or start;
audio~  - dac~ catcher~ for all throws~, output level, mute;

Sound Objects

By default sound objects start playing at the bpm of the first argument

basspump - args - bpm note distortion duration
wood - args - bpm note duration
tremsaw  - args - bpm note vibrato distortion duration
tremsine - args - bpm note vibrato noise duration
noisy - args - bpm note vcfq duration
kauplus  - args - bpm note string-resonation duration

Effect Objects

sqr - args - 16 required(0 or 1) bpm (starts playing by default)
                          overides sound objects autoplay
                          2 optional args for cursor offset and pitch if font different
                          has 16 outlets to send 0 or 1
echo-delay-bpm  - args - bpm feedback(0 to 100) level(0 to 100)
echo-delay-ms  - args - millisecs feedback(0 to 100) level(0 to 100)
pan-level - args - pan (-100 to 100) level (0 to 100)
autopan  - args - width (0 to 100) frequency (* 0.01) level (0 to 100)
fade - args - millisecs to fade-in pecentage of level to drop to (0 to 100) millisecs to fade-out
filter - args - highpass (midi note to frequency) lowpass (midi note to frequency)
                          (0 to 135 equates to approx 8Hz to 19912Hz)
start-delay-secs - args - seconds (delays the autostart of the connected object)
start-delay-bpm  - args - bpm (delays the autostart of the connected object)
stop-delay-secs  - args - seconds (outputs a one at the end of the delay which can connect to a globalsync)
stop-delay-bpm   - args - bpm (delays the autostart of the connected object)

isolator - sits between two sqr's and sends a signal to start/stop the receiving sqr
seqnotes - four pairs of note & velocity that receive sqr ones to fire a connected sound object

Notes
Can crash Pd when making lots of edits to arguments, particularly while playing, so save often
There is a [declare -path objects] hiding behind the audio~ object
Fixed missing note and velo message for tremsaw
Two more arguscore patches can be open at the same time providing only one patch contains the globaltimer and audio~ objects (see arguscore-2.pd and arguscore-2-b.pd)
new objects
kauplus, autopan, fade, filter, stop-delay-secs, stop-delay-bpm;

Hi,

I'm creating a loop station and I've got several questions about different issues.

1. Latency
2. Fading/Cutting recorded samples at start and end
3. Metronom settings

1) Latency
I'm using the latency tester from the repo.
http://www.pdpatchrepo.info/patches/patch/92

Latency might be calculated with different methods:
a ) Connecting the output of the soundcard directly to the input via cable. This way the lowest possible latency is received. (Around 440 samples in my case)
b ) Calculating via microphone and speakers. Latency will be higher compared to a ). Also the bigger the distance between mic and speakers, the higher the latency will be.

Which calculation should be used?
(To me it seemes to be logical, to use the latency calculated by b ), as that is the method which reflects the real circumstances. But I'm not shure and it's very hard to tell by what I hear.)

2) Fading/Cutting recorded samples at start and end

When the recorded sample contains a phrase which is completly finished before the next 1, doing a fade with [vline~] sounds OK. But when you record a continuous sound (like a string pad) you will always hear that fade of [vline~].
Compared to Reaper: Cutting a sound and looping it, will result in a continuous sound. To me it seemes like some kind of crossfade between the beginning and the end of the sample is done.

Does someone know more about this? How should it be done correctly?

Crossfading seemes to be a quite difficult task in my eyes, as a lot of calculation has to be done. (Recording has to start a bit earlier and to stop later, sync has to start earlier, and so on)

3) Metronom settings

This loop station depends on a metronom and works similar to Ableton Live. As pd uses blocks of 64 samples, the tempo is corrected to a tempo which corresponds to an array with a size multiple of 64. So playing can easily be kept in sync.

I'm not shure about this. Is it a good idea to do it like this?
But changing this to a manner, where the tempo might be chosen freely, will result in much more complicated calculations. Is it worth it?

Thanks for any comments in advance,
Xaver

My patch is still in development and can be found here:
https://github.com/XRoemer/puredata/tree/master/loop-machine
(downloading from github: go up one folder and use the download/clone button
https://github.com/XRoemer/puredata/tree/master)

loop-machine2.zip

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

16-band-zoomable-_vu_meter_sv

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~

maximo-guitar-rack-6-slots-with-1-of-60-effects-per-slot-using-abs_effects_router-an-osc-controller-mobmuplat

searchable_pd-help-pd-search-your-local-pd-files-according-to-a-string-and-output-the-results-to-the-console

extra

pd-2-thoughtmap-a-patch-and-its-children-as-a-plantuml-usecase-linux-shell-script-package-v0-1-1-update-below

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

right-click-to-view-pd-files-online-via-mozilla-s-web-developer-extension-pd-fileutils-and-a-shell-script

As I mentioned in a previous post: "idea: "riding the wave"delay length triggered by env~ size (link http://forum.pdpatchrepo.info/topic/10557/idea-riding-the-wave-delay-length-triggered-by-env-size)", I had been wondering about controlling a delay line via the env~.

pushdelay~_sv-help.pd
pushdelay~_sv.pd

My idea had been to mimic the "power" of a wave (akin to what I have been suspecting we will do once we figure out how to harness the power of gravity waves): the larger the amplitude > the further the auditory "ripple" and the longer it lasts.

The abstraction below, pushdelay~, is my incarnation of that idea.

Ciao!

Much merriment thru you and yours.
Scott

-help (from the -help comments):

In this pushdelay~ abstraction the length of time on the delay line, as well as feedback, are driven by the amount of the env~, the larger the env~ the longer the delay time and more feedback there is.;
In "inter" (interval) mode, the abstraction takes the current delay time and sets a metro to that time;
opens a spigot and captures the maximum value for the env~ during that period then sets the next delay and metro times to that value.;
In "cont" mode, it sets the delay and feedback times continuously based on the envelope value.;
The relationship between the delay(x) and feedback(y) values can be set using the curve ctrl, either linear, convex (sinusoidal) or concave (also sinusoidal but inverted).;
Turning the abs either off|on starts the inital metro.;
If in "off" mode, the delay ctrl may be moved independently. However the feedback will still change the same way, mentioned above.

-enjoy;
svanya

p.s. the original delay~ abs is from the DIY2 collection.

Needed an effect to fill a slot, so set out to make one.

abs_beatlooper~_sv.pd
abs_beatlooper~_sv_help.pd

Synopsis:

The abstraction repeatedly (via [metro]s) records a loop for a set amount of beats, pauses for another number of beats and plays it for yet another number of beats.

FYI: I think it's timing might be a little out-of-whack. So if some/any-one can diagnose and/or remedy the issue (:-) if there actually is one) that would be great! Thanks in advance.

Note:all times are in beats.

Via its controls, the abs_:

off|on: turns a [switch~] on in the subpatch and starts a [timer];
bpm: sets the beats-per-minute rate of the looper;
rec_time : how many beats the looper should record;
pause_time: how many beats the looper should wait until playing the recorded loop;
play_time: how many beats the looper should play the loop for;
feedback: for the side-chained delay line the loop is being written to;
saturation: the gain-mix for the dry and wet lines

Notes: if play_time is less than rec_time it will only play the first x beats, if greater it will repeat the loop as many times as it can up to mod beats of the rec_time. The looper is actually on a side-chained delay line (with 0 delay time, but allowable feedback). The bpm calc is from the DIY2-4tap-delay abs_, the delay line is from DIY-mono-delay-feedback, and I can't remember where I got the looper.

If someone recognizes the looper subpatch by all means Please share who did it below.

I am very very curious if anyone finds this useful and/or intriguing.

Esp. since that feedback may/probably will impact whether i include it in my rack-app.

So if you do check it out, please, provide feedback below. Thanks.

Peace. And merry music making thru us all.
-svanya

p.s. currently, this only plays the segments forward. I will update it when able so the user can toggle whether the loops are played forward or backward.

...here's the complete list of the recordings which actually include PureData:

http://www.marcobaumgartner.com/#daily_recordings/01-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/02-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/03-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/04-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/05-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/06-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/07-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/08-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/09-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/10-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/11-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/12-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/13-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/14-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/15-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/16-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/22-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/23-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/24-Nov-2015
http://www.marcobaumgartner.com/#daily_recordings/30-Nov-2015

Patches are downloadable here but they're REALLY very messy and not documented neither... Sorry for that. I had fun working just by trying things out. Now, when I look at the patches, I have a hard time understand it myself...

Marco