<br><br><div><span class="gmail_quote">On 8/31/07, <b class="gmail_sendername">Martin Ahnelöv</b> <<a href="mailto:operagasten@gmail.com">operagasten@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
ons 2007-08-29 klockan 23:11 +0200 skrev Kassen:<br><br>> dur => blackhole would be exactly like SinOsc => blackhole,<br>> but with<br>> time. When you, for example, chuck second into blackhole, the
<br>> shred will<br>> forward 1 second in it's own timeline (A bit like the -s<br>> otion, if I<br>> recall).<br>><br>> I'm still not sure exactly how this would be different. What would
<br>> happen to playing Ugens that would be in the shred? Would those keep<br>> computing?<br><br>The thing is... Hm, if we have something like this:<br><br>SinOsc 1 => dac;<br><br>while (true) {<br> 100::ms => now;
<br> 3::samp => blackhole;<br>}<br><br>The shred would jump 3 samples forward every 100 ms. If you change the<br>duration to 10::ms, you might get some glitching going on every 100::ms.</blockquote><div><br><br>
Ok, I get it now, you'd like to jump into the future... That should be possible but I think it will often lead to a big strain on the cpu. For simple oscilators or a envelope it could be quite easy but if the shred involves -say- three oscilators in a fm feedback loop there would be no way around calculating all the samples inbetween to know what value the final one is at after the time we skip..
<br><br>It's a interesting idea but I'm not sure the benefits outweigh the dangers and problems.<br><br>At least you could record your sounds like that, for example recording them to a LiSa and turning record off at a certain point, advancing time, then resuming recording at the spot where you left off.
<br></div><br><br>Kas.</div>