Hi,
New pd user here,
I've used Max MSP for some time now.

I was wandering if one sample delay processing is possible in pd as in gen~ in MaxMSP ?

also, is there anything similar to the gen~ cycle object with 0 phase attribute?

creating something like this in pd is possible?
a feedback oscillator with input to the phase of the oscillator?

Creating a one-sample delay is achieved by placing your objects in a subpatch and putting a [block~ 1] object in there. Then you have to use [tabsend~] and [tabreceive~] instead of [delwrite~] and [delread~] to achieve the one-sample delay.
As for the oscillator, I don't understand what is the 0 phase attribute. In both [osc~] and [phasor~], the phase is set by control messages, but since you'll have a one-sample block size, that shouldn't be a problem, you can just set the phase to what ever you like and it will be reset at the next sample block (one sample later).

@KMETE
the Max patch looks like feedback-FM to me. For PM the + would be placed between phasor and circle, if I'm not mistaken.
And with 1000 ms delay, as I read the Max patch? there would be no need for 1 sample-blocks.

A thread on this topic:
https://forum.pdpatchrepo.info/topic/6185/feedback-fm-algorithm

DC-blocking you can do with [hip~ 20] for example (I'd put it in the feedback-loop).

cycle object

[cos~] ? Is a cosine-tabel, to get a sine you can drive it like this:

[phasor~]
|
[-~ 0.25]
|
[cos~]

Offtopic: Pd's cosine has a slight DC-offset.
https://forum.pdpatchrepo.info/topic/13709/bug-osc-cos-circle-asymmetry-drifting-out-of-phase

@alexandros said:

Creating a one-sample delay is achieved by placing your objects in a subpatch and putting a [block~ 1] object in there. Then you have to use [tabsend~] and [tabreceive~] instead of [delwrite~] and [delread~] to achieve the one-sample delay.

Yes. And be aware of the importance of creating [tabsend~] beforehand of [tabreceive~] . You can read about in the Pd documentation 3.audio.example > G05.execution.order.pd

For feedback, I usually build subpatches with such a dummy-connection, save the patch, and delete the dummy cable lastly and save again, for perceving the execution order and avoiding a dsp-loop.

[delwrite~] and [delread~] can become as short as 1 sample, too.

In both [osc~] and [phasor~], the phase is set by control messages, but since you'll have a one-sample block size, that shouldn't be a problem, you can just set the phase to what ever you like and it will be reset at the next sample block (one sample later).

This is one of the biggest myths in Pd (at least for me), but unfortunately not true. (Vanilla 52.2)
See vphasor~-help : https://github.com/dotmmb/mmb
Still the same, if you put it in a subpatch with [block~ 1].

Documentation is lacking here. There are very few timing- sample- or phase-critical control-objects that are able to update (sub-)sample-accurately in-between block-boundaries of 64 samples minimum:

I only know of [bang~], [metro], [delay], [pipe], [vline~]

Hi,
I try to connect the output if the cos~ to the input of the delay without success.
How can I do so?

and here is the patch I am trying to imitate in pd

First of all, you're using a control delay and not a signal one. You're missing the tilde. Use [delwrite~] instead of [delay]. You'll need a [delread~] to read the signal
Also not that you can't make a feedback connection in the signal domain because it creates a DSP loop. Max probably works under the hood to make this function properly. But if you think, the execution order goes like this: the object that sends audio to its outlet does its computations before the object that receives the audio signal. If you make a feedback connection, which object is supposed to make its computations first?
To achieve this you have to send the output of [cos~] to a [tabsend~] (don't disconnect it from [*~ 0.4]), and connect a [tabreceive~] to [delwrite~]. Also, if you want feedback in your delay, you'll need to do this in the same way, so use another pair of [tabsend~]/[tabreceive~] to connect the output of [delwrite~] back to its input.

@alexandros said:

But if you think, the execution order goes like this: the object that sends audio to its outlet does its computations before the object that receives the audio signal. If you make a feedback connection, which object is supposed to make its computations first?
To achieve this you have to send the output of [cos~] to a [tabsend~] (don't disconnect it from [*~ 0.4]), and connect a [tabreceive~] to [delwrite~]. Also, if you want feedback in your delay, you'll need to do this in the same way, so use another pair of [tabsend~]/[tabreceive~] to connect the output of [delwrite~] back to its input.

By using a [delwrite~] [delread~] or [delread4~] pair, the DSP loop is already detached, - you won't need [tabsend~] [tabreceive~] additionaly. You can use either or to break the loop.

Make sure that the whole chain feeding (and including) [delwrite~] is written in the .pd file before [delread4~],
(Check .pd file in a text editor. In Pd you can select > cut > paste parts of the patch, to change the order) -
then you will be able to go as low as min 1 sample delay.

You can measure latency with this latency-tester2.pd
https://forum.pdpatchrepo.info/topic/13814/catch-would-like-to-set-the-name-programmatically/20

A thread on this topic:
https://forum.pdpatchrepo.info/topic/6185/feedback-fm-algorithm

@lacuna is correct about [delwrite~]/[delread~] and the DSP loop being dettached, didn't occur to me while writing the post.

delread~ is not a sample delay it is a tapping buffer.

a tapping delay does not delay "the samples", it delays their content.

plus its minimum delay time is the vectorsize.

i think in pd you would replace [delay~ 1] with [fexpr~]... something like x = x1, no idea about the correct synthax.

You can perfectly use the delwrite~ delread~ , write~for 1 sample feedback
Test case :operator feedback phase modulating itself will turn a sine into a sawish waveform and then ultimately noise .
-Create subpatcher , route phasor~ into +~ into cos~
Inser block~1
Insert delwrite~ , insert delread~
Route cos~ to delwrite~
Route output of delread~ into miltiply *~( this is our feedback control)
Route this back to the adder before the cos~ .

Voila , phase modulation feedback , Sine will turn into saw into noise , the shawish like shape would not have been possible with longer delay times.
So delread~,write~ are perfectly capable of doing 1 unit sample feedback.

Here's a PD patch ( plugdata version ) which uses the tab~send , tab~receive~ and ofcourse ' block~1'
I have noticed that it doesn' t make any difference when using tabread~ or tabreceive ~.
I do have noticed that while the delread~ and delwrite~ are capable of 1 unit sample feedback , the part where the foldover-collapse starts sounds better when using tabsend~ method instead of delread~-write~
This patch is euivalent to a two operator feedback loop , modulator going into carrie and carrier back into mod .

feedbacker2.pd

And here using the two techniques , one operator feedback
Left channel using del~ method , righ channel tab~method

You need the Else sine object or just replace with phasor~ +cos~
comparisons.pd

@alexandros

What am I doing wrong ?

@KMETE you have to put all objects you want to run at a 1-sample block size into a subpatch. [dac~], [s~ ], [r~ ] and the likes can't handle block sizes other than the default 64. Only [inlet~] and [outlet~] can up/downsample signals.
Also, you don't need [delwrite~]/[delread~] there, but a [array define fed 1]. Get rid of the objects on the right and the top part of your image (with the [delread~] and [delwrite~], along with their connected [tabsend~ fed1] and tabreceive~ fed]), and change the argument to the [tabreceive~ fed1] to "fed".