First I think it is of critically importance for people to remain extra-polite on big, international listservs. <br><br>I would suggest to make conscious effort to tone down any hostility, frustration, or anger you are feeling before posting. Take a deep breath.  <br><br>Recall, we are all doing this to (mostly) to have fun :)<br><br>Next, I think this discussion could have great pedagogical value to intermediate PD patchers like me to explain what this is all about.<br><br>I'm sorry but I do not understand "overlapping sub-patches" or the issue with [vd~]. <br><br>I would wager there are others here in my boat.<br><br>I very much would appreciate some more discussion here. Diagrams would help me very much. <br><br>Thanks! <br><br>PS: I am personally loving [vd~] at the moment. I just made an abstraction called "AutoPhase3".<br>That and my "AutoPan3" makes a really awesome Leslie (rotating speaker) simulation. <br><br>Basically, it takes a mono source and writes it into a circular buffer. <br><br>Then, I have 3x [vd~]'s reading, with an LFO on the delay time. I can change the speed and depth of the LFO, as well as the phase-distance between them. <br><br><br>It's so freaking awesome! I then take these 3 signals and send them to discrete AutoPan modules. Again, speed and depth of LFO variable. <br><br>OMG, the fatness! Just take a simple saw oscillator, or even a sinusoid-- anything! And you can get lush flanger, phasor, and chorus effects. <br><br>I guess it's like FM so it can really warp the spectrum. Create artifacts not found in the original. <br><br>You can get it on GitHub. <br>TinyURL.com / BHPDToolkit <br><br>FYI: There are several demo-patches with bugs in abstraction names. Everything is there in the repository, but some abstraction names changed. I will fix when I can. <br><br><br><br><br>On Thursday, September 24, 2015, Christof Ressi <<a href="mailto:christof.ressi@gmx.at">christof.ressi@gmx.at</a>> wrote:<br>>> cause I'm expecting the object to behave as it should<br>>  <br>> more precisely, you're expecting the object to behave as YOU THINK it should ;-). But you're right that this discussion can go on forever. I just want to point out a last time that there's a difference between a bug and improper documentation. For example there's a technical reason why for computing audio in blocks, the reading onset for [vd~] would be less than the buffer size of [delwrite~] (especially when deliberately increasing the block size). This is totally logical and problems only arise because of vague terms like 'maximum delay time'. So it's not that the behaviour of [vd~] is wrong, but the helpfile - and that's an important difference!<br>>  <br>> Regarding the behaviour of overlapping subpatches you just have to accept how Pd works. Changing its behaviour will break hundreds of patches.<br>> To repeat myself, I personally think most of what you declare as a 'bug' is just a matter of missing or misleading documentation.<br>>  <br>> Cheers<br>>  <br>> PS: I'm not claiming the last word on this subject<br>>  <br>>  <br>> Gesendet: Donnerstag, 24. September 2015 um 18:54 Uhr<br>> Von: "Alexandre Torres Porres" <<a href="mailto:porres@gmail.com">porres@gmail.com</a>><br>> An: "Christof Ressi" <<a href="mailto:christof.ressi@gmx.at">christof.ressi@gmx.at</a>><br>> Cc: Pd-List <<a href="mailto:pd-list@lists.iem.at">pd-list@lists.iem.at</a>><br>> Betreff: Re: Re: [PD] more delay weirdness<br>> 2015-09-24 9:53 GMT-03:00 Christof Ressi <<a href="mailto:christof.ressi@gmx.at">christof.ressi@gmx.at</a>>:<br>>><br>>> If my last post felt like a repression, I deeply regret that!<br>><br>>  <br>> no worries ;) just had to bring it up.<br>>  <br>>><br>>> but you were calling other things a bug, that were no bugs in a technical sense (how ms are calculated in overlapping subpatches, how the maximum index for [vd~] is actual less than the buffer size, etc.).<br>>> (...) <br>>> I'm personally rather careful with calling something a bug because chances are high that there's simply a technical reason I didn't consider or couldn't understand.<br>><br>>  <br>> Yeah, I see the way you think but I think quite differently and I still consider these things a "bug". I know there might be technical issues that explain why things happen. But when nothing tells me that when using an overlapped block that I have to adjust time and frequency for objects, I see that as a bug, cause I'm expecting the object to behave as it should, and it just doesn't, and then my patches don't work and it sucks. I have to ask the list why the heck something is not happening and why do I need workarounds... someone had to look deeply in the code and sort it out...<br>><br>> Well, and instead of building workarounds in the patch, I know there's a way to "fix" this in the object (just divide by the overlap number automatically in the code, seems easier than explaining it somewhere in the help file of a block~) - it wouldn't be impossible to fix it.<br>>  <br>> Regarding the maximum delay time. Well, help file says it can go up to the total length and it doesn't... so... bug detected. I'm sure there's a reason why it's happening, but I don't think its impossible to fix it and make it happen as well.<br>>  <br>> but anyway, I get your view, but I'll just disagree :) not sure if we should discuss and try to change each other's minds.<br>>  <br>> cheers<br>>  <br>>  <br><br>-- <br><div dir="ltr"><div><div dir="ltr">--<br>
May you, and all beings<br>
be happy and free from suffering :)<br>
-- ancient Buddhist Prayer (Metta)<br></div></div></div><br>