[PD] I'm stuck in a corner, please help! RE: [delta~] object

[marius schebella]

I have to say that the problem is not that the delread~ was created 
after the delwrite~, but that the delwrite~ was created after the 
line~... as soon as delwrite~ is created after line~ it already *writes* 
(!) with a delay of one sampleblock. it might be true that delread is 
working correctly in relation to delwrite (which means it is also one 
sampleblock delayed), but actually both of them are delayed.
the solution with subpatches only helps, if they are connected with a 
signal inlet~/outlet~. see attached patch. (see also the additional 
questions in the patch - what happens if you create a feedback with 
subpatches, are we then back to "order of creation"??)

delwrite~ and delread~ can produce a big mess. maybe there is a better 
way to "sort" delaylines?
I think it is a bug that delwrite~ can be one vector late. and I also 
think it is also a bug that delread~ can be one vector behind the 
correlating delwrite~. otoh, I have no solution what to do with signal 
feedback loops then. maybe delread~ should accept a sorting message? can 
Pd reorder the signal chain at all?? actually I see no way to bring the 
for humans obvious logic into the pd signal chain...

marius.

Roman Haefeli wrote:
> On Fri, 2008-03-21 at 18:38 -0400, marius schebella wrote:
>> hmm,
>> first, i think you need [swap 1000] instead of [swap 1], because you 
>> want to delay by 1000/44100 milliseconds and not 1/44100 milliseconds.
>> and then, there is this problem that delwrite~/delread~ is sensitive to 
>> the order of creation. I attached a small patch, you can see that a 
>> delwrite/read that is created before the line~ object works similar to 
>> z~, wheras the delwrite/delread that is created after the line~ is one 
>> vector behind.
>> I attach a patch for clarification...
>> marius.
>>
> 
>> Andy Farnell wrote:
>>> [rzero~] and [delwrite~] methods come out louder
>>> and with apparently less dynamics. Using [z~] and [fexpr~]
>>> I get much closer results to [delta~], more detail in
>>> the poured water sound.
> 
> 
> let me mention a clean way to solve the issue with a block delay without
> having to care about creation order. have a look at the doc:
> 
> 3.audio.examples/G05.execution.oder.pd
> 
> roman
> 
> 
> 
> 	
> 		
> ___________________________________________________________ 
> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
> 
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: delwrite-bug2.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080322/acab6582/attachment.txt>