2016-02-25 13:57 GMT-03:00 martin brinkmann mnb@martin-brinkmann.de:
if you want feedback in a complex patch, (like these virtual-virtual-modular-systems) the only thing you can do is to reblock everything to 1, which is not always possible (due to high cpu load, conflicting blocksizes, whatever).
This was addressed only to me, let me reply to the list.
I never needed to do it in a super complex patch, but anyway, what you're saying is not true. Here's how you can do it.
Have your crazy complex patch running around all over the place.
Now, for your feedback loop, you need to create a subpatch to "send it".
Make it [pd fb_send]
in it, create a short delay line, give it a cool name like $0-fb, use [block~ 1].
then, for your feedback receive, have another subpatch [pd fb_receive]. In it, use [delread~ $0-fb 0].
voilá...
check my self frequency modulating oscillator patch attached
cheers
Le 25/02/2016 18:09, Alexandre Torres Porres a écrit :
2016-02-25 13:57 GMT-03:00 martin brinkmann <mnb@martin-brinkmann.de mailto:mnb@martin-brinkmann.de>:
if you want feedback in a complex patch, (like these virtual-virtual-modular-systems) the only thing you can do is to reblock everything to 1, which is not always possible (due to high cpu load, conflicting blocksizes, whatever).This was addressed only to me, let me reply to the list.
I never needed to do it in a super complex patch, but anyway, what you're saying is not true. Here's how you can do it.
Have your crazy complex patch running around all over the place.
Now, for your feedback loop, you need to create a subpatch to "send it".
Make it [pd fb_send]
in it, create a short delay line, give it a cool name like $0-fb, use [block~ 1].
then, for your feedback receive, have another subpatch [pd fb_receive]. In it, use [delread~ $0-fb 0].
voilá...
check my self frequency modulating oscillator patch attached
your patch did not work with 1 sample delay. to test : remove the block~ 1 object, and the sound did not change.
put everything in a subpatch, add a block~ 1 object, and the sound change (and get better)
There are 2 problem in you patch : nothing force the writer to be computed before the reader. you can add a dummy audio connection between writer and reader to force execution order of the 2 subpatch. see miller exemple G05.
But the main problem is that the osc run with 64 block size. there is no way to have less than 64 sample delay between osc frequency in and osc output.
In order to have feedback in a very complex patch, you need to block~ everything to 1.
cheers c
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I had tested with count~ before and the result was clearly a one sample delay, subtracting the output of count to a feedback line gave me the result of 1.
I'll test it again later
2016-02-25 14:38 GMT-03:00 cyrille henry ch@chnry.net:
Le 25/02/2016 18:09, Alexandre Torres Porres a écrit :
2016-02-25 13:57 GMT-03:00 martin brinkmann <mnb@martin-brinkmann.de mailto:mnb@martin-brinkmann.de>:
if you want feedback in a complex patch, (like these virtual-virtual-modular-systems) the only thing you can do is to reblock everything to 1, which is not always possible (due to high cpu load, conflicting blocksizes, whatever).This was addressed only to me, let me reply to the list.
I never needed to do it in a super complex patch, but anyway, what you're saying is not true. Here's how you can do it.
Have your crazy complex patch running around all over the place.
Now, for your feedback loop, you need to create a subpatch to "send it".
Make it [pd fb_send]
in it, create a short delay line, give it a cool name like $0-fb, use [block~ 1].
then, for your feedback receive, have another subpatch [pd fb_receive]. In it, use [delread~ $0-fb 0].
voilá...
check my self frequency modulating oscillator patch attached
your patch did not work with 1 sample delay. to test : remove the block~ 1 object, and the sound did not change.
put everything in a subpatch, add a block~ 1 object, and the sound change (and get better)
There are 2 problem in you patch : nothing force the writer to be computed before the reader. you can add a dummy audio connection between writer and reader to force execution order of the 2 subpatch. see miller exemple G05.
But the main problem is that the osc run with 64 block size. there is no way to have less than 64 sample delay between osc frequency in and osc output.
In order to have feedback in a very complex patch, you need to block~ everything to 1. cheers c
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 25/02/16 18:09, Alexandre Torres Porres wrote:
2016-02-25 13:57 GMT-03:00 martin brinkmann mnb@martin-brinkmann.de:
if you want feedback in a complex patch, (like these virtual-virtual-modular-systems) the only thing you can do is to reblock everything to 1, which is not always possible (due to high cpu load, conflicting blocksizes, whatever).
This was addressed only to me, let me reply to the list.
sorry, i pressed the wrong reply button.
I never needed to do it in a super complex patch, but anyway, what you're saying is not true. Here's how you can do it.
Have your crazy complex patch running around all over the place.
Now, for your feedback loop, you need to create a subpatch to "send it".
Make it [pd fb_send]
in it, create a short delay line, give it a cool name like $0-fb, use [block~ 1].
then, for your feedback receive, have another subpatch [pd fb_receive]. In it, use [delread~ $0-fb 0].
would be great if it worked. (i've tried similar tricks...)
voilá...
check my self frequency modulating oscillator patch attached
the delayed signal is not a sine, when the blocksize in the receive is <64.
BTW, this is germane to some work that I have been doing and it just so happens that I have a figure handy.
In the figure are the spectra for two oscillators frequency modulating each other in a tight feedback loop. The first two were made with FM oscillators adapted from Pd's FM example patch. The first spectrum was recorded using block 64 and the second at block 1. The third was made using a dynamical model (which is, incidentally, the principle behind the [bob~] object) of two oscillators in an FM regime. This better approximates 0 time delay. It should be clear how much distortion even 1 sample of delay in the loop causes in this particular situation.
Unfortunately, the answer for how to do this in Pd is 'write an extern' -- hence [bob~]. So far there is no such thing as an unsampled, real-time patching environment.
On 02/25/2016 09:52 AM, martin brinkmann wrote:
On 25/02/16 18:09, Alexandre Torres Porres wrote:
2016-02-25 13:57 GMT-03:00 martin brinkmann mnb@martin-brinkmann.de:
if you want feedback in a complex patch, (like these virtual-virtual-modular-systems) the only thing you can do is to reblock everything to 1, which is not always possible (due to high cpu load, conflicting blocksizes, whatever).
This was addressed only to me, let me reply to the list.
sorry, i pressed the wrong reply button.
I never needed to do it in a super complex patch, but anyway, what you're saying is not true. Here's how you can do it.
Have your crazy complex patch running around all over the place.
Now, for your feedback loop, you need to create a subpatch to "send it".
Make it [pd fb_send]
in it, create a short delay line, give it a cool name like $0-fb, use [block~ 1].
then, for your feedback receive, have another subpatch [pd fb_receive]. In it, use [delread~ $0-fb 0].
would be great if it worked. (i've tried similar tricks...)
voilá...
check my self frequency modulating oscillator patch attached
the delayed signal is not a sine, when the blocksize in the receive is <64.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
would be great if it worked. (i've tried similar tricks...)
yeah, don't know what happened, when I tried with count~ it seemed to work, for my own surprise, I wasn;t expecting it to work either. Now I have no idea what happened.
I may have also just gone insane for good :)
2016-02-25 14:52 GMT-03:00 martin brinkmann mnb@martin-brinkmann.de:
On 25/02/16 18:09, Alexandre Torres Porres wrote:
2016-02-25 13:57 GMT-03:00 martin brinkmann mnb@martin-brinkmann.de:
if you want feedback in a complex patch, (like these virtual-virtual-modular-systems) the only thing you can do is to reblock everything to 1, which is not always possible (due to high cpu load, conflicting blocksizes, whatever).
This was addressed only to me, let me reply to the list.
sorry, i pressed the wrong reply button.
I never needed to do it in a super complex patch, but anyway, what you're saying is not true. Here's how you can do it.
Have your crazy complex patch running around all over the place.
Now, for your feedback loop, you need to create a subpatch to "send it".
Make it [pd fb_send]
in it, create a short delay line, give it a cool name like $0-fb, use [block~ 1].
then, for your feedback receive, have another subpatch [pd fb_receive].
In
it, use [delread~ $0-fb 0].
would be great if it worked. (i've tried similar tricks...)
voilá...
check my self frequency modulating oscillator patch attached
the delayed signal is not a sine, when the blocksize in the receive is <64.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
well, I was able to replicate my test with count...
not sure what's happening, but that's it, a one sample delay in feedback, for what it seems
I gotta go into my dentist now, whish me luck
2016-02-25 16:38 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
would be great if it worked. (i've tried similar tricks...)
yeah, don't know what happened, when I tried with count~ it seemed to work, for my own surprise, I wasn;t expecting it to work either. Now I have no idea what happened.
I may have also just gone insane for good :)
2016-02-25 14:52 GMT-03:00 martin brinkmann mnb@martin-brinkmann.de:
On 25/02/16 18:09, Alexandre Torres Porres wrote:
2016-02-25 13:57 GMT-03:00 martin brinkmann mnb@martin-brinkmann.de:
if you want feedback in a complex patch, (like these virtual-virtual-modular-systems) the only thing you can do is to reblock everything to 1, which is not always possible (due to high cpu load, conflicting blocksizes, whatever).
This was addressed only to me, let me reply to the list.
sorry, i pressed the wrong reply button.
I never needed to do it in a super complex patch, but anyway, what
you're
saying is not true. Here's how you can do it.
Have your crazy complex patch running around all over the place.
Now, for your feedback loop, you need to create a subpatch to "send it".
Make it [pd fb_send]
in it, create a short delay line, give it a cool name like $0-fb, use [block~ 1].
then, for your feedback receive, have another subpatch [pd fb_receive].
In
it, use [delread~ $0-fb 0].
would be great if it worked. (i've tried similar tricks...)
voilá...
check my self frequency modulating oscillator patch attached
the delayed signal is not a sine, when the blocksize in the receive is <64.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 25/02/16 20:45, Alexandre Torres Porres wrote:
well, I was able to replicate my test with count...
not sure what's happening, but that's it, a one sample delay in feedback, for what it seems
it looks as if cyclone/snapshot~ does not work like it should. when i turn on "magic glass" it shows "64", while the snapshot outputs "1".
I gotta go into my dentist now, whish me luck
good luck! maybe the sounds of the test-patches have been a good preparation for (at least the acoustic) things to come. ;-)
I see what's happening
the fb receive is sending the same number over and over for the whole 64 block
when subtracting from the count input, we get a block that goes from 1 to 64.
snapshot is giving me the first value (1), your magic glass is giving you the last (64).
And I just acted too soon when I saw this today and thought I had found gold
I haven't thought about it yet, but I wonder if something like I described could be done somehow, or if it is "physically impossible".
well, now I'm off the dentist and going to the yoga class, too much things on my day are ruining my pd quality time...
cheers
2016-02-25 17:21 GMT-03:00 martin brinkmann mnb@martin-brinkmann.de:
On 25/02/16 20:45, Alexandre Torres Porres wrote:
well, I was able to replicate my test with count...
not sure what's happening, but that's it, a one sample delay in feedback, for what it seems
it looks as if cyclone/snapshot~ does not work like it should. when i turn on "magic glass" it shows "64", while the snapshot outputs "1".
I gotta go into my dentist now, whish me luck
good luck! maybe the sounds of the test-patches have been a good preparation for (at least the acoustic) things to come. ;-)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
cyrille henry -
David Medine -
martin brinkmann