I did not look at your patch but as far as I can remember, I had success extending the lower tracking range by up or downsampling the fiddle~ sigmund~ or helmholz~ object. This might work for the upper range, too. Keep filtering aliasing in mind, while up /down sampling.
The instrument's bell-like tones might confuse the tracking. Low pass filtering harmonic content might help.
@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
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.
- Is [fexpr~] the best way to check for the phasor reset?
I did it in the same way, or with Cyclone.
I think you and I were posting on another topic when @alexandros suggested using [rzero_rev~ 0] to get the previous sample.
- 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.
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 )
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?
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. )
@pharaoh-sean After installing Zexy via Deken,
try adding zexy to File > Preferences > Libraries
[declare -lib zexy]
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:
@adammccaffrey you can find the error message in the sources:
the patch is resizing the cloned arrays
here it uses >4Gb of ram
operating system? 32 / 64 bit?
PD-version? 32 /64 bit?
@cfry No, the quote posted by @ddw_music is related to PD's scheduler and the basic difference between update-rates of control versus signal~objects.
You can read about it in PD's manual chapter "scheduling" in the help-menu.
[noise~] has to calculate 44100 random numbers per second, whether you do anything with those numbers or not. [random] just runs when you ask it to.
... and you can poll it every 64 samples only.
That is why
There's one case where you might use [noise~] and [samphold~] -- if the random step function is needed in the signal domain and you expect the sample/hold unit to update in the middle of an audio processing block.
and why [noise~] with the output of [snapshot~] has no advantage over [random].
When I did a comparison test with just one of each (set to fast rate), the cpu load did not differ much
You will only feel the difference in huge patches with many [clone]s and or upsampling in the sum with many other things running.
I am modifying an polyphonic FM synth, which has cloned objects with [phasor~] inside.
Is the random generated inside of the [clone]?
If not, something else might cause high CPU-load.
The cheapest way to get random might not be calculating it in realtime, but reading preset random numbers from a text- or wavefile or an array with phasor~ or [f][+ 1]. But then the random set will loop.
How could i mesure the peak frequency of a moving nonresonant analog filter without a feedbackloop between its audio output back into its audio input?
I do have a calibration patch for resonating filters and oscillators.
What would be a good way to do
this? White noise into the filter > FFT > Findung the peak? And slowing the whole calibration procedure by the overall latency. Or better with a sine sweep instead of noise for being independend of randomness.
How can i find such a peak?