Hi!

Is it possible to operate on all the instances of a [clone] object by multipling all of them (making a big AM/ring modulation of all the signals)?

Thanks!

@manuels Nice, you beat me to it. Yeah, I thought of the log/exp bit after I went to bed and felt compelled to get up to post it, but then even later in the night I woke up and realized my mistake! When I was working I used to joke that I should bill for the time I'm sleeping.

@inum Here is an example multiplyFactors.zip Please post sound output when you get it running to your satisfaction--I'm curious what you're trying to do.

an alternative would be to dynamically patch a linear chain using helper abstractions instead.
couple ideas: (open chain.pd) multimulti.zip

yet another option that may (or may not) pass efficiency police checks: send the result of each instance to previous (or next) instance ...

in this case, the signal is passed through starting from the last instance. since the last instance doesn't have a corresponding sender, the [s~ 3-instance] becomes necessary with a constant signal of 1 as a factor. it would work as well in the opposite direction, of course. the cloned instances are all muted except for instance 0, which is the result of all multiplications.

this is a quick hack - not sure if it does what it's supposed to do. if you want to check, here are the 2 patches: test-am-clone.zip

@ben.wes That's a great solution to the lateral-signal-pass-among-clones problem, but I would check to see if there is latency at each s~/r~ pair. When I looked into it a few years back I think I found that sending in the opposite direction (i.e. ascending clone index order) was preferable because it had no latency.

@jameslo that's a very good point and i didn't consider it at all. thanks!

without checking, i assume that it's exactly as you say since the instances are created in ascending order and i certainly introduced 1-block-delays that way as described in the help of s~/r~:

You have to get the [send~] sorted before the [receive~] or else you'll potentially get a one block delay.

(i'm actually not sure why it would only "potentially" happen)

... attaching an updated patch that's actually quite fun to play around with (in this case, the clone needs a second argument for the audible instance): test-am-clone.zip

EDIT: checked and confirmed now (that the sender should be in the previous instance).

adding one more detail ... with a little logic inside the cloned patch, it's not necessary to set the audible instance id with an additional parameter - the max id can also be derived like this for example:

@ben.wes In my (much less nice) version of the lateral signal pass clone, I didn't use [outlet~]. I just used the final [s~] to get the resulting signal.

@jameslo said:

[...] In my (much less nice) version [...] I just used the final [s~] to get the resulting signal.

after reading this, i mainly get the impression that your version might have been much less complicated!

... it seems so obvious now to just continue the chain from the last s~ instead of "sending" to nirvana and adding a logic to achieve the correct outlet~ result. damn. thanks!

Thanks a lot for all the answers, really amazing ideas!!

This Log Exp trick is really amazing!!!