@deframmentazione-geometrica also see D04.envelope.quartic.

And F09.declickit in the helpfiles for phase-consistency in trade for jitter in the sequence.

clickless-onoff~.pd

@Knallberto workaround to find lost posts of the old forum:
do an online search of
' topic's name ' pure data
to find it's new address
https://forum.pdpatchrepo.info/topic/4866/dj-vj-scratching-system

more than pros and cons:

• Seems like a new generation is starting with PD now. A wiki could be another democratic resource.
• There are already many different resources to learn PD, easy to find, online and offline.
• PD has nothing to do with consumerism, imho. This is neither Eurorack nor VST. It is more about ideas than downloading existing tools. PD is a development environment, something like a blank paper. Very individual. Apart from learning the language, there is no right or wrong.
• You can do much more apart from DSP with it. Many users are artists, not musicians. An encyclopedia would never be complete and feels like a strange perspective because science, in the sense of writing down what others did, can not be the very base of art.
  Yes, PD is ideal for designing a kick-drum and although it's purpose is free, PD and many power users are more in the tradition of IRCAM and similar.
• As the PD community is small and methods and techniques aren't PD specific, a wiki on DSP in general with sub-forums and sub-sections or tags in each article for code examples in C, Python, Matlab, PD, Max, SC, VCV ect. could connect many more people and would make more sense imho.
• There is already the big Wikipedia with DSP and software programming, too. Rewriting everything would be pointless. But links to examples in different coding-languages are rare.
• It might make more sense to use a wiki as some kind of meta resource of weblinks.
• For example, your list of reverb techniques is lacking a lot and the introduction is misinformation, as it describes vaguely only one specific way of many in creating a reverb.
  If this would be a wiki page, it would require many more contributions for becoming more useful than an online search. And as others said before, I doubt this is going to happen if PD only.
• Much more important to me would be making a backup of this forum.
  It is an important resource and it would be pity if it would be gone. This happened to many forums for different reasons before and all their information will be gone forever.
  Even a frozen mirror of the current state, saved on some free and independent server would be better than nothing. Even plain .txt and .pd files could help, if it's not trivial to run the forum as a backup.
  It would be much harder to learn PD without this forum. For example, I guess almost everyone trips over the [$0-in_a_message_is_not_working( and such things.

@ddw_music

• Is [fexpr~] the best way to check for the phasor reset?

I did it in the same way, or with Cyclone.
@jameslo said:

I think you and I were posting on another topic when @alexandros suggested using [rzero_rev~ 0] to get the previous sample.

cool

• The [rpole~ 1] is essentially a phasor with a signal-rate reset (as opposed to [phasor~], which can be reset, but only with control messages). Is there a better way?

There are [vphasor~], [vphasor2~] and [vsamphold~] from @Maelstorm . I did not try them yet.
https://forum.pdpatchrepo.info/topic/10192/vphasor-and-vphasor2-subsample-accurate-phasors/

Patched my own [vphasor~] with [fexpr~], too and another one with a [pd subpatched] [block~ 1] and [tabwrite~] and another [pd sub] [block~ 1] [tabreceive~] and a feedback-loop, that is basicly forming a ramp by adding itself up.
Both might be expensive? I did not compare their CPU load yet.
Your [rpole~ 1] is neat.

Why not in vanilla?

I am wondering about this, too. Am working on sampleaccurate "audio-control" and slowly making progress.

In your patch [rpole~ 1] is working with a signal-inlet, isn't it?
Or what is it that you tried to say?
Of course you can deform the ramp with [*~] [+~] [samplerate~] ect.

Which is that other forum you mentioned? I am keen to learn more about DSP techniques.

(Tbh I'm a little bit proud of this one )

yeay!

It depends on the method and complexity of synthesis - if you use filters, feedback and anti-aliasing filters ect.
The sampler might basicly be arrays as look-up tables < read interpolated with tabread4~ with a phasor~ < modulated with ramps and some AM.
With similar ingredients you can already patch a very basic synth but more complexity will require some more cpu.
If you want time-stretching and independent pitch-modulation, the sampler will become more complex with FFT.
(You see, in reality either one becomes a hybrid quickly: for example [cos~] is a table-lookup, too.)
Reading a complex pre-made sample will use the same CPU as a very basic sound.
A sampler will require more RAM, as the arrays are stored in memory. You can easily calculate the reqired space for this if you know samplelength, bits and samplerate.
Given the synth- or sampler-apps available for phones, I guess you can patch quite complex instruments in either way. Of course this depends on other expensive tasks running along with it.
The CPU-load depends on blocksize and latency, too.
Often in PD-Vanilla the bottleneck are the GUI elements, wich you might not use anyway.

@jameslo The bug is the delaylines~ not having 1 sample delay.
I am not entirely sure why, but you read them at 0ms, - arguments are in ms not samples and there is the importance of the execution order with delays~, and s~ r~, you can read about in audio.examples/G05.execution.order.pd
But this would lead to a DSP-loop here.

However, I use tabsend~ tabreceive~ and 1 sample arrays, as this is how to do feedback-loops with 1 sample delay.
I created the sending subpatches first, the receiving ones afterwards, - not sure if this is important for the execution order in this case, too?
biquad-resonator-debug_2c.pd

@pharaoh-sean
help > find externals
And please read how to deal with externals in the manual: help > manual > chapter 4 externals
To be sure, delete the zexy folder in /extra before reinstalling it with Deken

(Also, I'd recommend to download the latest version of PD Vanilla from here https://puredata.info/downloads
or there http://msp.ucsd.edu/software.html
instead of using possibly outdated repositories (i.e. Synaptics). But this is unrelated to your question. )

@RetroMaximus mapping might help
map.pd
map-help.pd

@pharaoh-sean After installing Zexy via Deken,

try adding zexy to File > Preferences > Libraries

or add
[declare -lib zexy]
beforehand
[demux]
in your patch.

In File > Preferences > Searchpaths should be PD's /extra folder, and the library should be inside of that folder, of course.

similiar thread here:
https://forum.pdpatchrepo.info/topic/12786/iemlib-in-vanilla-deken-compiling/11