Re: [PD] more delay weirdness

[IOhannes zmölnig]

Am 25. September 2015 00:10:25 MESZ, schrieb Christof Ressi 
>To repeat myself, I personally think most of what you declare as a
>'bug' is just a matter of missing or misleading documentation.
>
>

I would say it is a bug - in the docs.


mfg.ugd.fhj
IOhannes

--
Sent from my pdp-11

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] more delay weirdness

[Christof Ressi]

> cause I'm expecting the object to behave as it should

 

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!

 

Regarding the behaviour of overlapping subpatches you just have to accept how Pd works. Changing its behaviour will break hundreds of patches.

To repeat myself, I personally think most of what you declare as a 'bug' is just a matter of missing or misleading documentation.

 

Cheers

 
PS: I'm not claiming the last word on this subject

 

 

Gesendet: Donnerstag, 24. September 2015 um 18:54 Uhr
Von: "Alexandre Torres Porres" <por...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: Pd-List <pd-list@lists.iem.at>
Betreff: Re: Re: [PD] more delay weirdness



2015-09-24 9:53 GMT-03:00 Christof Ressi <christof.re...@gmx.at>:




If my last post felt like a repression, I deeply regret that!




 

no worries ;) just had to bring it up.



 








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.).

(...) 

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.








 

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...

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.

 

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.

 

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.

 

cheers

 

 








___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] more delay weirdness

[Alexandre Torres Porres]

2015-09-24 9:53 GMT-03:00 Christof Ressi :

> If my last post felt like a repression, I deeply regret that!
>

no worries ;) just had to bring it up.

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.).
> (...)
> 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.
>

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...

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.

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.

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.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] more delay weirdness

[William Huston]

First I think it is of critically importance for people to remain
extra-polite on big, international listservs.

I would suggest to make conscious effort to tone down any hostility,
frustration, or anger you are feeling before posting. Take a deep breath.

Recall, we are all doing this to (mostly) to have fun :)

Next, I think this discussion could have great pedagogical value to
intermediate PD patchers like me to explain what this is all about.

I'm sorry but I do not understand "overlapping sub-patches" or the issue
with [vd~].

I would wager there are others here in my boat.

I very much would appreciate some more discussion here. Diagrams would help
me very much.

Thanks!

PS: I am personally loving [vd~] at the moment. I just made an abstraction
called "AutoPhase3".
That and my "AutoPan3" makes a really awesome Leslie (rotating speaker)
simulation.

Basically, it takes a mono source and writes it into a circular buffer.

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.


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.

OMG, the fatness! Just take a simple saw oscillator, or even a sinusoid--
anything! And you can get lush flanger, phasor, and chorus effects.

I guess it's like FM so it can really warp the spectrum. Create artifacts
not found in the original.

You can get it on GitHub.
TinyURL.com / BHPDToolkit

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.




On Thursday, September 24, 2015, Christof Ressi <christof.re...@gmx.at>
wrote:
>> cause I'm expecting the object to behave as it should
>
> 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!
>
> Regarding the behaviour of overlapping subpatches you just have to accept
how Pd works. Changing its behaviour will break hundreds of patches.
> To repeat myself, I personally think most of what you declare as a 'bug'
is just a matter of missing or misleading documentation.
>
> Cheers
>
> PS: I'm not claiming the last word on this subject
>
>
> Gesendet: Donnerstag, 24. September 2015 um 18:54 Uhr
> Von: "Alexandre Torres Porres" <por...@gmail.com>
> An: "Christof Ressi" <christof.re...@gmx.at>
> Cc: Pd-List <pd-list@lists.iem.at>
> Betreff: Re: Re: [PD] more delay weirdness
> 2015-09-24 9:53 GMT-03:00 Christof Ressi <christof.re...@gmx.at>:
>>
>> If my last post felt like a repression, I deeply regret that!
>
>
> no worries ;) just had to bring it up.
>
>>
>> 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.).
>> (...)
>> 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.
>
>
> 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...
>
> 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.
>
> 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 

Re: [PD] more delay weirdness

[Christof Ressi]

Alexandre, it's cool that you're out on 'bug hunt', however, on some things you could take a little more time to figure out if things are really a bug or just mistakes on our own.

You're wondering why the 'back' [print~] starts with 2111? The first 64 samples are from a previous block. Then from sample nr. 64, it starts from 1983, as expected.

Check my reply patch if you still have doubts.

 

Gesendet: Mittwoch, 23. September 2015 um 02:10 Uhr
Von: "Alexandre Torres Porres" <por...@gmail.com>
An: "pd-list@lists.iem.at" <pd-list@lists.iem.at>
Betreff: [PD] more delay weirdness


wow, I'm still finding some weird things going on with delay lines and fft subpatches.
 

Find my newest issue in the attached patch. Now I have only [z~] as the delay line (but same happens with [delay~]).

 

So I have two patches: on the parent patch, [z~ 64] will act as a "back" window, and you can check it prints a block that is behind 64 samples indeed.

 

When it comes to the subpatch with a block of 256 and overlap of 4, the "front" window is not in the "front" anymore, but behind by 128 samples!!!

 

what the hell?

___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


#N canvas 493 69 543 619 10;
#X obj 124 90 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 139 202 delwrite~ x 100;
#N canvas 1035 92 455 391 fft 1;
#X obj 89 130 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 175 119 vd~ x;
#X obj 89 40 inlet;
#X obj 140 197 z~ 64;
#X obj 139 81 block~ 256 4;
#X obj 140 239 tabwrite~ array2;
#X obj 202 270 tabwrite~ array1;
#X obj 195 296 print~ FRONT;
#X obj 92 294 print~ BEHIND;
#X floatatom 257 162 5 0 0 0 - - -, f 5;
#X connect 0 0 5 0;
#X connect 0 0 6 0;
#X connect 0 0 8 0;
#X connect 0 0 7 0;
#X connect 1 0 3 0;
#X connect 1 0 6 0;
#X connect 1 0 7 0;
#X connect 2 0 0 0;
#X connect 3 0 5 0;
#X connect 3 0 8 0;
#X connect 9 0 3 1;
#X restore 71 224 pd fft;
#X obj 71 188 del 50;
#N canvas 0 50 450 250 (subpatch) 0;
#X array array1 1024 float 3;
#A 0 -0.999757 -0.56 -0.56 -0.999757 -0.999359 -0.998752 -0.997932
-0.996913 -0.995696 -0.99428 -0.992667 -0.990851 -0.988819 -0.986589
-0.984164 -0.981542 -0.978725 -0.975713 -0.972484 -0.96906 -0.965444
-0.961636 -0.957636 -0.953445 -0.949047 -0.944454 -0.939674 -0.934706
-0.929552 -0.924213 -0.918678 -0.91295 -0.90704 -0.90095 -0.89468 -0.888233
-0.8816 -0.874779 -0.867783 -0.860614 -0.853275 -0.845765 -0.838084
-0.830218 -0.822188 -0.813994 -0.805637 -0.797121 -0.788445 -0.779595
-0.770588 -0.761428 -0.752116 -0.742655 -0.733045 -0.723278 -0.71336
-0.703302 -0.693103 -0.682766 -0.672293 -0.661678 -0.650923 -0.640039
-0.629027 -0.61789 -0.60663 -0.595245 -0.583732 -0.572102 -0.560358
-0.548503 -0.536538 -0.524465 -0.512277 -0.499986 -0.487596 -0.475109
-0.462527 -0.449853 -0.43708 -0.424219 -0.411273 -0.398246 -0.385139
-0.371955 -0.358692 -0.345354 -0.331947 -0.318474 -0.304938 -0.291341
-0.277683 -0.263966 -0.250196 -0.236377 -0.22251 -0.2086 -0.194646
-0.18065 -0.166618 -0.152553 -0.138458 -0.124335 -0.110187 -0.0960145
-0.0818231 -0.0676155 -0.0533944 -0.0391626 -0.0249228 -0.0106776 0.00356968
0.0178161 0.032059 0.0462955 0.060523 0.0747376 0.0889365 0.103118
0.117278 0.131415 0.145526 0.159607 0.173654 0.187666 0.201641 0.215575
0.229467 0.243312 0.257104 0.270844 0.284531 0.29816 0.311731 0.325239
0.338676 0.352044 0.365342 0.378568 0.391718 0.40479 0.417775 0.430674
0.443486 0.456211 0.468844 0.481385 0.493823 0.506158 0.518391 0.530522
0.542546 0.554463 0.566265 0.577945 0.58951 0.600958 0.612286 0.623492
0.634572 0.645512 0.656324 0.667005 0.677553 0.687967 0.698243 0.708365
0.718345 0.728181 0.737873 0.747417 0.756813 0.766045 0.775119 0.784039
0.792803 0.801409 0.809855 0.818131 0.826233 0.834171 0.841943 0.849548
0.856983 0.864242 0.871313 0.878211 0.884935 0.891482 0.897851 0.904041
0.91003 0.915838 0.921463 0.926905 0.932163 0.937235 0.942101 0.946776
0.951262 0.99 0.959666 0.963582 0.967291 0.970799 0.974114 0.977235
0.980161 0.982892 0.985417 0.987733 0.989851 0.991773 0.993497 0.995024
0.996347 0.997453 0.99836 0.999068 0.999578 0.999888 1 0.999888 0.999578
0.999068 0.998359 0.997452 0.996346 0.995023 0.993496 0.991772 0.98985
0.987731 0.985415 0.98289 0.980159 0.977232 0.974111 0.970797 0.967288
0.963579 0.959663 0.96 0.951259 0.946772 0.942097 0.937231 0.932159
0.926901 0.921459 0.915834 0.910026 0.904037 0.897847 0.891477 -0.629027
-0.61789 -0.60663 -0.595245 -0.583732 -0.572102 -0.560358 -0.548503
-0.536538 -0.524465 -0.512277 -0.499986 -0.487596 -0.475109 -0.462527
-0.449853 -0.43708 -0.424219 -0.411273 -0.398246 -0.385139 -0.371955
-0.358692 -0.345354 -0.331947 -0.318474 -0.304938 -0.291341 -0.277683
-0.263966 -0.250196 -0.236377 -0.22251 -0.2086 -0.194646 -0.18065 -0.166618
-0.152553 -0.138458 -0.124335 -0.110187 

Re: [PD] more delay weirdness

[Alexandre Torres Porres]

2015-09-23 8:08 GMT-03:00 Christof Ressi :

> Alexandre, it's cool that you're out on 'bug hunt', however, on some
> things you could take a little more time to figure out if things are really
> a bug or just mistakes on our own.
>

well, never said this particular thing was a "bug", I just have a real hard
time figuring out the way things work with this overlaping subpatches, it's
very counter intuitive and weird for me, so I don't see this as a matter of
"mistake" either - I just pointed this as a doubt on why the heck this is
going on...

I think the list is a proper channel for this kind of issues. I hit a
brickwall and asked for help... I don't really understand your attitude.
Are you saying I should be trying harder to figure out stuff for myself and
not bother people with my hard time figuring out how pd works? I appreciate
your help, but please don't repress people from asking stuff like that, if
that's the deal, is not a nice thing.

anyway, thanks for your patch, I'll check and see if I can get it later on.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] more delay weirdness

[Alexandre Torres Porres]

wow, I'm still finding some weird things going on with delay lines and fft
subpatches.

Find my newest issue in the attached patch. Now I have only [z~] as the
delay line (but same happens with [delay~]).

So I have two patches: on the parent patch, [z~ 64] will act as a "back"
window, and you can check it prints a block that is behind 64 samples
indeed.

When it comes to the subpatch with a block of 256 and overlap of 4, the
"front" window is not in the "front" anymore, but behind by 128 samples!!!

what the hell?


delay-test-again.pd
Description: Binary data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list