This repeated buffer only applies to signals sent inside that subpatch, and signals sent out with the [s~ ] object. (i didn't test throw~, but i would guess it's the same)<br><br>if you just use an [outlet~] object, the buffer is not repeated. <br>
<br>see attached test patch if you don't believe me.<br><br><br><br><br><div class="gmail_quote">On Fri, Dec 2, 2011 at 12:17 AM, Jaime Oliver <span dir="ltr"><<a href="mailto:jaime.oliver2@gmail.com">jaime.oliver2@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">> [inlet~] [inlet]<br>
> | |<br>
> | [switch~ ]<br>
> |<br>
> [outlet~]<br>
<br>
Besides clicking problems which you might not care about, If you send a zero to switch~ while there is still audio in the buffer you'll get the buffer repeated over and over. This is why I use both a *~ AND a switch~.<br>
<br>
Best,<br>
<br>
J<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
> Let's call this abstraction [gate~ ]. It turned out to work as supposed.<br>
> But is [gate~] really cheaper than [*~ ]? I made a test by connecting<br>
> lots of [gate~]s to a chain and measure the CPU usage. For simplicity<br>
> reason, let's just use an invented arbitrary unit for expressing the CPU<br>
> time (ct) consumed by an object. It turned out that [gate~] uses 0.52ct<br>
> when it is on and 0.4ct when it is off. But how much does [*~ ] use? No<br>
> matter whether turned on or off, [*~ ] uses a stable 0.39ct.<br>
><br>
> The relatively complex multiplication is _not_ more expensive than the<br>
> on/off implementation with [switch~ ]. Even when turned off, the<br>
> [switch~] approach is still more expensive.<br>
><br>
> But the really interesting finding comes now. [*~ 0] has only 0.2ct!<br>
> Almost the the ct value of a plain [*~ ] halved! It also doesn't matter<br>
> what value the argument has. The plain fact of specifying an argument<br>
> makes [*~ ] a lot cheaper. I also tested [/~ ], [+~ ] and [-~ ] and the<br>
> same applies for those. They all have 0.39ct without argument and only<br>
> 0.2ct with an argument specified. Depending on the kind of patch, this<br>
> allows for quite a significant performance improvement.<br>
><br>
> I also measured the ct of a [*~ ] when a signal wire is connected to the<br>
> right inlet. It costs exactly as much (0.39ct) as when sending messages<br>
> to the right inlet of a [*~ ] without argument.<br>
><br>
> My interpretation is that [*~ 0] and [*~ ] are two different objects.<br>
> The latter always performs a calculation with two signals and implicitly<br>
> converts a message on the right inlet to a signal, where the former<br>
> really only deals with messages on the right inlet (and thus is<br>
> cheaper).<br>
><br>
><br>
><br>
><br>
> On a completely different note, I wanted to know if it costs anything to<br>
> have signals entering and leaving subpatches and abstractions a lot,<br>
> respectively if [inlet~] and [outlet~] add some overhead in CPU time. I<br>
> chained tens of thousands subpatches together and it seems that does not<br>
> consume any additional CPU time at all. The values for [inlet~ ] and<br>
> [outlet~] are much below 0.01ct. I haven't tested the cost, when more<br>
> than one signal wire are going to an [inlet~], though.<br>
><br>
> Roman<br>
><br>
><br>
> _______________________________________________<br>
> <a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br>