Hi all, hope everyone's well.
We're trying to implement a 4-op FM matrix with feedback, copying a patch my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback)
Has anyone ever succeeded doing something like this in pd? I know about the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others.
I'm really looking for a solution that doesn't involve using blocksize of 1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway?
I don't mind adding a bit of latency to the whole system if there's maybe a hack to do this with tables or something,,,but am really stuck here wondering what to do.
any ideas?
cheers, Matt
s~ and r~ only work with 64 sample block, so you can't use them in this situation. but you can replace them using delwrite~ and delread~ with no delay, and force order to write before you read.
cheers c
Le 08/01/2016 10:42, i go bananas a écrit :
Hi all, hope everyone's well.
We're trying to implement a 4-op FM matrix with feedback, copying a patch my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback)
Has anyone ever succeeded doing something like this in pd? I know about the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others.
I'm really looking for a solution that doesn't involve using blocksize of 1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway?
I don't mind adding a bit of latency to the whole system if there's maybe a hack to do this with tables or something,,,but am really stuck here wondering what to do.
any ideas?
cheers, Matt
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
oh, I forget to say that you can also upsample the subpatch in order to reduce the feedback latency.
Le 08/01/2016 10:54, cyrille henry a écrit :
s~ and r~ only work with 64 sample block, so you can't use them in this situation. but you can replace them using delwrite~ and delread~ with no delay, and force order to write before you read.
cheers c
Le 08/01/2016 10:42, i go bananas a écrit :
Hi all, hope everyone's well.
We're trying to implement a 4-op FM matrix with feedback, copying a patch my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback)
Has anyone ever succeeded doing something like this in pd? I know about the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others.
I'm really looking for a solution that doesn't involve using blocksize of 1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway?
I don't mind adding a bit of latency to the whole system if there's maybe a hack to do this with tables or something,,,but am really stuck here wondering what to do.
any ideas?
cheers, Matt
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
i just tried upsampling, but it seems to hit the cpu harder than lowering blocksize, even.
and yeah, my friend just got a patch going using delwrite~ and vd~, which we can use at blocksize of 1, and it works... but the hit on the cpu is harsh.
really looking for some way to do this at normal 64 sample blocksize at normal samplerate
On Fri, Jan 8, 2016 at 7:03 PM, cyrille henry ch@chnry.net wrote:
oh, I forget to say that you can also upsample the subpatch in order to reduce the feedback latency.
Le 08/01/2016 10:54, cyrille henry a écrit :
s~ and r~ only work with 64 sample block, so you can't use them in this situation. but you can replace them using delwrite~ and delread~ with no delay, and force order to write before you read.
cheers c
Le 08/01/2016 10:42, i go bananas a écrit :
Hi all, hope everyone's well.
We're trying to implement a 4-op FM matrix with feedback, copying a patch my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback)
Has anyone ever succeeded doing something like this in pd? I know about the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others.
I'm really looking for a solution that doesn't involve using blocksize of 1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway?
I don't mind adding a bit of latency to the whole system if there's maybe a hack to do this with tables or something,,,but am really stuck here wondering what to do.
any ideas?
cheers, Matt
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 08/01/2016 11:16, i go bananas a écrit :
i just tried upsampling, but it seems to hit the cpu harder than lowering blocksize, even.
my thought was : blocksize 1 AND upsampling (to improve audio quality)
upsampling a 64 block size is not interesting (in therm of cpu and quality)
and yeah, my friend just got a patch going using delwrite~ and vd~, which we can use at blocksize of 1, and it works... but the hit on the cpu is harsh.
really looking for some way to do this at normal 64 sample blocksize at normal samplerate
if cpu is a limit, i guess the only solution is to create an external. cheers c
On Fri, Jan 8, 2016 at 7:03 PM, cyrille henry <ch@chnry.net mailto:ch@chnry.net> wrote:
oh, I forget to say that you can also upsample the subpatch in order to reduce the feedback latency. Le 08/01/2016 10:54, cyrille henry a écrit : s~ and r~ only work with 64 sample block, so you can't use them in this situation. but you can replace them using delwrite~ and delread~ with no delay, and force order to write before you read. cheers c Le 08/01/2016 10:42, i go bananas a écrit : Hi all, hope everyone's well. We're trying to implement a 4-op FM matrix with feedback, copying a patch my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback) Has anyone ever succeeded doing something like this in pd? I know about the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others. I'm really looking for a solution that doesn't involve using blocksize of 1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway? I don't mind adding a bit of latency to the whole system if there's maybe a hack to do this with tables or something,,,but am really stuck here wondering what to do. any ideas? cheers, Matt _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto: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
You may want to look at Martin Brinkmann's patch Chaosmonster1.
http://www.martin-brinkmann.de/pd-patches.html
I studied it about a year ago, and gave up trying to understand how it works. But it makes fantastic noises.
Martin says it "generates noise- and 'chaos'-sounds with six oscillators with mutual frequency, filter and ringmodulation. Some similarities to the famous 'heishere' reaktor ensemble by lazyfish."
On Friday, January 8, 2016, i go bananas hard.off@gmail.com wrote:
Hi all, hope everyone's well.
We're trying to implement a 4-op FM matrix with feedback, copying a patch
my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback)
Has anyone ever succeeded doing something like this in pd? I know about
the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others.
I'm really looking for a solution that doesn't involve using blocksize of
1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway?
I don't mind adding a bit of latency to the whole system if there's maybe
a hack to do this with tables or something,,,but am really stuck here wondering what to do.
any ideas? cheers, Matt
If you want shorter feedbacks than 64 samples within a patch, there is no way around reducing block size. You may be able to optimize by putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch.
Then there are some classes that do internal sample-size feedbacks, like [rpole~] or [fexpr~]. While [fexpr~] is quite flexible, it may be even more expensive than a subpatch with blocksize=1 (at least that's what I remember when I compared two implementations, but this observation might have been specific to that kind of problem).
Roman
On Fri, 2016-01-08 at 18:42 +0900, i go bananas wrote:
Hi all, hope everyone's well.
We're trying to implement a 4-op FM matrix with feedback, copying a patch my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback)
Has anyone ever succeeded doing something like this in pd? I know about the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others.
I'm really looking for a solution that doesn't involve using blocksize of 1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway?
I don't mind adding a bit of latency to the whole system if there's maybe a hack to do this with tables or something,,,but am really stuck here wondering what to do.
any ideas?
cheers, Matt _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you want shorter feedbacks than 64 samples within a patch, there is
no way around reducing block size
i still have this itching doubt in that. i think what we're looking for is some real leap of imagination here. we are fine with having a block or 2 latency,,,so i'm imagining maybe there's some far out hack involving synchronised tabread~'s and delayed osc~'s, or something like that, which would somehow do it.
You may be able to optimize by
putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch.
yeah that seems the most likely approach now.
if cpu is a limit, i guess the only solution is to create an external.
this is probably the 2nd most likely solution.
thanks guys for your ideas and help.
On Fri, Jan 8, 2016 at 7:34 PM, Roman Haefeli reduzent@gmail.com wrote:
If you want shorter feedbacks than 64 samples within a patch, there is no way around reducing block size. You may be able to optimize by putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch.
Then there are some classes that do internal sample-size feedbacks, like [rpole~] or [fexpr~]. While [fexpr~] is quite flexible, it may be even more expensive than a subpatch with blocksize=1 (at least that's what I remember when I compared two implementations, but this observation might have been specific to that kind of problem).
Roman
On Fri, 2016-01-08 at 18:42 +0900, i go bananas wrote:
Hi all, hope everyone's well.
We're trying to implement a 4-op FM matrix with feedback, copying a patch my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback)
Has anyone ever succeeded doing something like this in pd? I know about the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others.
I'm really looking for a solution that doesn't involve using blocksize of 1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway?
I don't mind adding a bit of latency to the whole system if there's maybe a hack to do this with tables or something,,,but am really stuck here wondering what to do.
any ideas?
cheers, Matt _______________________________________________ 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
This is not for the faint of heart (it is poorly organized and not documented at all), and there is no build environment set up for OSX or Windows, but I wrote a C language API that I rolled into a Pd extern which takes compiled C files that describe feedback networks with approximately 0 time delay. This is done by modeling the network with dynamical systems and solving numerically. I gave a talk about this at ICMC this year.
Using these tools I made a program that runs in Pd that has two oscillators that can frequency modulate and sync one another and themselves. It maintains the 64 sample block size and the CPU load is minimal. It can easily be extended to N oscillators.
I can send a copy of the paper to you directly if you are interested (I don't want to hit the whole list with a pdf). Here is the project on github -- please forgive my many sins, this is not yet ready for release and it shows. https://github.com/dmedine/timelab -David
On 01/08/2016 03:00 AM, i go bananas wrote:
If you want shorter feedbacks than 64 samples within a patch, there is
no way around reducing block size
i still have this itching doubt in that. i think what we're looking for is some real leap of imagination here. we are fine with having a block or 2 latency,,,so i'm imagining maybe there's some far out hack involving synchronised tabread~'s and delayed osc~'s, or something like that, which would somehow do it.
You may be able to optimize by
putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch.
yeah that seems the most likely approach now.
if cpu is a limit, i guess the only solution is to create an external.
this is probably the 2nd most likely solution.
thanks guys for your ideas and help.
On Fri, Jan 8, 2016 at 7:34 PM, Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com> wrote:
If you want shorter feedbacks than 64 samples within a patch, there is no way around reducing block size. You may be able to optimize by putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch. Then there are some classes that do internal sample-size feedbacks, like [rpole~] or [fexpr~]. While [fexpr~] is quite flexible, it may be even more expensive than a subpatch with blocksize=1 (at least that's what I remember when I compared two implementations, but this observation might have been specific to that kind of problem). Roman On Fri, 2016-01-08 at 18:42 +0900, i go bananas wrote: > Hi all, hope everyone's well. > > We're trying to implement a 4-op FM matrix with feedback, copying a > patch my friend made in reaktor using a block size of 1 (sorry, don't > know the full details of that, but he says he can get 1 sample delay > for the feedback) > > Has anyone ever succeeded doing something like this in pd? I know > about the order forcing using subpatches like in G.05.execution.order > help patch, but that doesn't seem like it will work here, as we still > get DSP loop errors when trying to connect the output of one osc~ back > into the frequency input of the others. > > I'm really looking for a solution that doesn't involve using blocksize > of 1, and anyway, even doing that, still seems the only way to do > feedback without getting DSP loop errors is with s~ / r~ pairs, which > seem to only work at blocksize of 64 anyway? > > > I don't mind adding a bit of latency to the whole system if there's > maybe a hack to do this with tables or something,,,but am really stuck > here wondering what to do. > > any ideas? > > > cheers, Matt > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto: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
[rpole~] can be a good option depending on the kind of flexibility you need. Why the distaste for [block~] size of 1 if it works?
Do you have some pseudocode or a block diagram? That would make it easier to give advice.
On Fri, Jan 8, 2016 at 11:53 AM, David Medine dmedine@ucsd.edu wrote:
This is not for the faint of heart (it is poorly organized and not documented at all), and there is no build environment set up for OSX or Windows, but I wrote a C language API that I rolled into a Pd extern which takes compiled C files that describe feedback networks with approximately 0 time delay. This is done by modeling the network with dynamical systems and solving numerically. I gave a talk about this at ICMC this year.
Using these tools I made a program that runs in Pd that has two oscillators that can frequency modulate and sync one another and themselves. It maintains the 64 sample block size and the CPU load is minimal. It can easily be extended to N oscillators.
I can send a copy of the paper to you directly if you are interested (I don't want to hit the whole list with a pdf). Here is the project on github -- please forgive my many sins, this is not yet ready for release and it shows. https://github.com/dmedine/timelab -David
On 01/08/2016 03:00 AM, i go bananas wrote:
If you want shorter feedbacks than 64 samples within a patch, there is
no way around reducing block size
i still have this itching doubt in that. i think what we're looking for is some real leap of imagination here. we are fine with having a block or 2 latency,,,so i'm imagining maybe there's some far out hack involving synchronised tabread~'s and delayed osc~'s, or something like that, which would somehow do it.
You may be able to optimize by
putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch.
yeah that seems the most likely approach now.
if cpu is a limit, i guess the only solution is to create an external.
this is probably the 2nd most likely solution.
thanks guys for your ideas and help.
On Fri, Jan 8, 2016 at 7:34 PM, Roman Haefeli reduzent@gmail.com wrote:
If you want shorter feedbacks than 64 samples within a patch, there is no way around reducing block size. You may be able to optimize by putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch.
Then there are some classes that do internal sample-size feedbacks, like [rpole~] or [fexpr~]. While [fexpr~] is quite flexible, it may be even more expensive than a subpatch with blocksize=1 (at least that's what I remember when I compared two implementations, but this observation might have been specific to that kind of problem).
Roman
On Fri, 2016-01-08 at 18:42 +0900, i go bananas wrote:
Hi all, hope everyone's well.
We're trying to implement a 4-op FM matrix with feedback, copying a patch my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback)
Has anyone ever succeeded doing something like this in pd? I know about the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others.
I'm really looking for a solution that doesn't involve using blocksize of 1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway?
I don't mind adding a bit of latency to the whole system if there's maybe a hack to do this with tables or something,,,but am really stuck here wondering what to do.
any ideas?
cheers, Matt _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list 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 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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
First, is the FM matrix actually FM or PM? Most FM are actually PM (phase modulation).
it's quite easy to do that, just have a [block~ 1] in the subpatch. There are different options for the feedback, but I prefer delwrite~ and delread~ as cyrille said. Don't use vd~ as it introduces another sample delay!
I'm attaching a folder from my computer music tutorial in portuguese. This folder contains updates that weren't released yet.
You can find the not updated and complete deal in here https://sites.google.com/site/porres/pd
direct download link is: https://sites.google.com/site/porres/Live%20Electronics%20%28EL%20Locus%20So...
the complete way to this folder is:
Parte II - Síntese Basica/15.Modulacao.de.Fase-Frequencia/6.Feedback.Cross.Modulation
If you get all of if you can check also the DX7.pd example, which comes next.
In the updated version I'm sending, I include a mean filter in the PM feedback loop, because that's how it seems it is done in FM8 for example. It reduces the chaos in the feedback.
cheers
2016-01-08 16:31 GMT-02:00 Matt Barber brbrofsvl@gmail.com:
[rpole~] can be a good option depending on the kind of flexibility you need. Why the distaste for [block~] size of 1 if it works?
Do you have some pseudocode or a block diagram? That would make it easier to give advice.
On Fri, Jan 8, 2016 at 11:53 AM, David Medine dmedine@ucsd.edu wrote:
This is not for the faint of heart (it is poorly organized and not documented at all), and there is no build environment set up for OSX or Windows, but I wrote a C language API that I rolled into a Pd extern which takes compiled C files that describe feedback networks with approximately 0 time delay. This is done by modeling the network with dynamical systems and solving numerically. I gave a talk about this at ICMC this year.
Using these tools I made a program that runs in Pd that has two oscillators that can frequency modulate and sync one another and themselves. It maintains the 64 sample block size and the CPU load is minimal. It can easily be extended to N oscillators.
I can send a copy of the paper to you directly if you are interested (I don't want to hit the whole list with a pdf). Here is the project on github -- please forgive my many sins, this is not yet ready for release and it shows. https://github.com/dmedine/timelab -David
On 01/08/2016 03:00 AM, i go bananas wrote:
If you want shorter feedbacks than 64 samples within a patch, there is
no way around reducing block size
i still have this itching doubt in that. i think what we're looking for is some real leap of imagination here. we are fine with having a block or 2 latency,,,so i'm imagining maybe there's some far out hack involving synchronised tabread~'s and delayed osc~'s, or something like that, which would somehow do it.
You may be able to optimize by
putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch.
yeah that seems the most likely approach now.
if cpu is a limit, i guess the only solution is to create an external.
this is probably the 2nd most likely solution.
thanks guys for your ideas and help.
On Fri, Jan 8, 2016 at 7:34 PM, Roman Haefeli reduzent@gmail.com wrote:
If you want shorter feedbacks than 64 samples within a patch, there is no way around reducing block size. You may be able to optimize by putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch.
Then there are some classes that do internal sample-size feedbacks, like [rpole~] or [fexpr~]. While [fexpr~] is quite flexible, it may be even more expensive than a subpatch with blocksize=1 (at least that's what I remember when I compared two implementations, but this observation might have been specific to that kind of problem).
Roman
On Fri, 2016-01-08 at 18:42 +0900, i go bananas wrote:
Hi all, hope everyone's well.
We're trying to implement a 4-op FM matrix with feedback, copying a patch my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback)
Has anyone ever succeeded doing something like this in pd? I know about the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others.
I'm really looking for a solution that doesn't involve using blocksize of 1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway?
I don't mind adding a bit of latency to the whole system if there's maybe a hack to do this with tables or something,,,but am really stuck here wondering what to do.
any ideas?
cheers, Matt _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list 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 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
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
-
Alexandre Torres Porres -
cyrille henry -
David Medine -
i go bananas -
Matt Barber -
Roman Haefeli -
William Huston