Hello all,
I am currently dealing with a fantastic array of eight circle-like arranged speakers. I would really like to improve my knowledge about it, in particular how it works in order to place a phantom sound source inside and - if possible - outside its perimeter. Can you suggest me some documentations that treat this topic, preferably something available on the web?
Thanks in advance.

@LandonPD, thanks for your reply. I already read this documentation but by your suggestion, I have read it once again; anyway, sincerely, I haven't found a solution to my issue. In the 2.4.4 paragraph the only element that I have taken into account is the reference to the line~ object that, of course, stops its ramping task to a target value if the DSP is turned off before the mentioned task is accomplished. I suppose that this is not my issue because with a sample rate of 44100Hz and a block size of 44100 samples, oversampled for instance with a 8x factor, theoretically the line~ object should be able to get the target number in one second, and to write the values to the table too.

Edit: Of course, if I am saying something that is not right, please correct my sentences.
Using the toggle in place of the button everything works correctly.

Hello all guys,
I'm working with PD (Vanilla 0.45.3) to create a Granular Synthesizer completely on my own. In order to generate the envelope line and the source material for each grain, I have created two different subpatches which, when they receive a bang, they respectively start sampling two different functions and saving them in two different arrays. To improve the result, I have set an higher sampling frequency in both these subpatches. The original main issue was that, using bangs and delayed bangs to define the start and the end points to write the function to the array, I always had to deal with imprecision in the amount of samples written to the table; I'm not sure but I think that this was due to the different rate with which control signal works respect to audio signal. Anyway, now I have discovered that the switch~ object allows in subpatches to process signals block-by-block sending just a bang: I think that this can resolve the issue above explained, but replacing the bang-delay-bang conception with the switch~ object, the DSP doesn't work. Sincerely, I don't know why because the syntax seems to be correct and this is because I'm writing here. I hope that someone can help me to find the reason of this issue and I thank you in advance. Here is the raw copy of the patch; the subpatch where I'm testing this is defined as "smoothed envelope": Grain_Synth_v2.Test.pd

Hi all,
I'm currently trying to build an All-Pass filter with PD Vanilla. Thanks to your advices regarding delay lines (I refer to my last topic), I've finally compiled this patch that I recall by abstraction (see attachments).
To test it, I've generated a 1-sample impulse with an amplitude of 0,66; then, I've recorded the result of this filtering with a 0,5 feedback and I've analyzed it on Audacity. As you can see from the attached screenshot, the filter doesn't work as I expected: I mean that the n. 3 sample should have an amplitude value equal to the original impulse amplitude - that is 0,66 - and all of the next samples should have a lower amplitude. So, my question is: why this All-Pass doesn't work properly? What is the cause of this result?
I wait for your reply.
Greetings.

http://www.pdpatchrepo.info/hurleur/ALL_PASS_1S.pd

Hi all,
my name is Rodolfo and I'm from Italy. I use PD (only Vanilla for now) since January and I'm still working to improve my knowledge about this fantastic programming language. Currently, I'm trying to recreate some electronic architectures based on the delay lines with feedback to obtain an audio effect (e.g. flanger, phaser, etc.). To recreate these circuits, I have used the delwrite~ and delread~/vd~ objects but they don't allow less than about 1,5 milliseconds of delay due to the feedback of the signal which is computed by blocks of 64 samples. To solve this, I have used the block~ object to force the computation of the signal by blocks of a single sample. It works good - the minimum delay is one sample - but it requires more effort by the processor. Then, I'd like to ask you: is there another way - a lighter way - to get the same result?
Waiting for your reply.
Regards.

Hi all,
I'm a newbie with PD; I come from Csound and I discovered PD thanks to Victor Lazzarini's Csound API (csoundapi~.dll) that allows the implementation of Csound in PD. Anyway, I'm writing here to ask for a issue solving: this issue consists in a PD's freeze when I create and save a project using csoundapi~. In these cases, I'm always forced to terminate the PD's process and, after this, Windows crashes and reboots. Is there a solution to solve this?

Damn, thanks a lot for this helpful video!
I see that in my previous post I didn't take the recursion of -g in account: I mean that the second sample should be 0,66 + (-0.33 * 0,5) = 0,495
Then, thanks again!

Maybe, I have found the issue: I have added a +~ object before the delwrite~ to "syncronize" both inputs of the delay line. Can you please test it with the print~ object? It seems a little bit weird but it only outputs zeros to my console - maybe because it is initialized before or after the pulse is generated.
Thank you in advance.

http://www.pdpatchrepo.info/hurleur/ALL_PASS_1S_v.2.pd

I'm still asking myself the same question!
Theoretically, when an All-Pass filter with a delay of one sample (~ 0,02... milliseconds) and a feedback index of 0,5 is "stimulated" with a one sample impulse whose amplitude value is 0,66, the resulting output should be a sequence of samples with the following amplitude values:
1. - 0,33
2. 0,66
3. 0,33
4. 0,165
5. 0,0825
etc.
If I'm wrong, please correct me.

Hi Henri,
you could create a sort of compressor with a medium/high compression ratio.
To get this, you could use [env~] to get the level of the signal and a conditional branch (e.g. the [expr] object) to scale its amplitude when it exceeds the threshold.

Ok, thanks again.

Thanks for your clear reply. I haven't told it precisely but I made the same thing that Maelstorm explained in the second thread: I mean I've used a block~ object in a subpatch. Anyway, I gather that there is no other solution to obtain a delay less than 1.45... msec, isn't it?

Ok, I know that all DSPs actually don't work in real time and always create a time delay due to the computation of the signal by blocks; but, e.g. in a flanger effect, how is it possible to make the difference between the orginal and the delayed signal less than a block (about 1,5 milliseconds)?

I run PD on Windows XP MCE SP3 and similar issues occur also to me.
For ex. PD Extended occasionally doesn't recognize some opcodes like csoundapi~ while PD Vanilla doesn't find any ASIO driver installed (I got ASIO4ALL) or doesn't support a higher sample rate; in these cases PD doesn't crash but it freezes and I'm forced to terminate manually the process. Often, this ending of process let Windows crash and reboot.
I also am waiting for more information about this issues and how to solve them but I have to tell you unfortunately no one has still helped me.

Ye, infact I reported the first issue also to Victor Lazzarini and it seems this one similarly occurs also on Mac OS X.
But the second issue is not related to Csound, I think, and that is because I ask this to all of the users that run PD on Windows.

Hello,
I see no one is able to help me about this issue; anyway, it seems this issue occurs only with PD Extended v. 0.43.4.
Using PD Vanilla v. 0.44, Csound API works but I can't set ASIO4ALL as audio driver.
In this case, how can I solve the matter?