Hi,

I want to set the recursivity of a phaser "alorithm" depending of a number

so for 0, do only one "iteration"
1 do two iterations
2 three ...

so I started to do it like this, but it's a mess and I got the feeling that pd has some neat function that would spare me the spagetthi plate

anyone now how to do this in a more effiscient way ?

thanks

You should use [send]/[receive] pairs and probably [until] to run a loop with a certain number of iterations. The loop could control the name of [send] in order to send data to a certain number of [receive]s.
Not sure what you want to do exactly, but that's what comes in mind as a first thought.

@alexandros indeed, I'll have a look
thanks

@phil123456 It's hard to tell with the picture.... but it looks as though sending the number to all of the [pd phaser-bank] objects and letting them decide how to "use" that number would be easiest.
If you make an abstraction of [pd phaser-bank] as maybe [phaser-bank] and then place that many times in the patch with a number argument........
[phaser-bank 1]
[phaser-bank 2]
[phaser-bank 3]
etc.
Then in [phaser-bank] you could use
[r number_being_sent]
|
[t b f]
| |
[$1<]
|
[do it $1 times]
to let the abstraction decide it's action...........

Does that make sense? it was posted in a hurry....
David.

@whale-av @alexandros

the issue here is that to have a loop, using [until], creates a series of bangs

but the phaser bank itself uses filters so it does not accept any bang to treat the signal
to my understanding, the signal is treated on audio block level

wish there was a [until~] object

@phil123456 Could you post that part (in the picture) or all of the patch....... it will be easier to understand!
David.

@whale-av here is what is inside the sub patch

I updated the main picture too

@whale-av

in the main patch
the frequency inlet goes from 0.0 to 1.0 and the strength is an integer that goes from 0 to 11

@whale-av oh yeah, the [mux] is a simple subpatch that just mixes the input signal to either left or right depending on the value of the right outlet (0.0 to 1.0)
I jould have called it [pan] instead

Well, [until] sends bangs only because it's the simplest possible loop. You can use these bangs to do something else (a counter for example that will output incrementing values.

If you make an abstraction you can use a [r something$1] where $1 will be replaced by the first argument of your abstraction, like @whale-av said. Take the following example:

[until]
|
[f ]x[+ 1]
|
[t f f]
| |
| [symbol somthing$1(
| |
[s ]

This would send a 0 to [r something0], a 1 to [r something1] etc. Very crude, but it might give some insight...

@alexandros

the filters are not triggered by bang and work on audio block level
one cannot interact with this process with bang/messages (as far as I know)

@phil123456 Here is what I was trying to explain........ you will have to finish it with the bits that I have not typed in from the picture you posted........... and probably correct the [$1 >=] to tailor to the incoming message........ and correct other things...... it is much easier for us if you upload your patch....
patch.zip
David.

@whale-av

I use vanilla, no spigot for signals, sorry I should have mentioned it in my post

replace [spigot~] witn [*~], it's the same thing.
What I said in my previous post is that you don't need to send bangs to your instances. You can use [until] to send numbers instead, by adding some sort of counter in your loop mechanism.

@alexandros

with spigot, messages are physicaly blocked

if I use [*~] then this is no iteration, more like a parametrized mixing, I would have 12 phaser filters running even if only a couple of them are used

honnestly the only reason I use vanilla is that I am afraid pd-extended gets discontinued one day
I also read that pd-extended code was a mess and loaded with bugs

Vanilla is capable of lots of things you can do with externals. I don't understand why you can't use [~ ] to block signals. I'm sure that you can create a [spigot~] with two [~ ] and a [== 0] to invert the control value.
You should probably post your patch, otherwise we're only speculating as to what you're trying to do..

@phil123456 Pd-extended development is discontinued......
All software from all publishers on all platforms (including Vanilla 046.7) is a mess and filled with bugs......
In fact you can more or less translate "up to date" as "filled with more un-fixed bugs"...... look at windows10 and mavericks......
My laptop would probably byte me if I translated that into hex......... damn.... I already have!!!!! Ouch.
David.

@whale-av wow, is there nobody maintaining this software ?

@alexandros check spigot help, it clearly states the audio messages are not passed
while operators will just modify the signal without blocking it

I don't have this object, so I can't check it's help patch. Anyway, by "audio messages are not passed" I guess it means that it outputs 0s. That's what happens when a signal is blocked in Pd. Even if a subpatch, or abstraction is turned off with [switch~], its [outlet~]s or [cathc~]s that listen to [throw~]s from that subpatch/abstraction will output 0s. There's no real blocking in Pd.

Pd-vanilla is maintained just fine BTW, it's extended that's now dead.