<div dir="ltr">I'd be really surprised if it'd "break" - that's a strong term.<div><div><br></div><div>Alter the sound a bit, maybe, sure, to a not desirable effect, maybe yes or maybe just not at all...</div><div><br></div><div>Now, conversely... any Frequency Modulation patch is really broken because it doesn't really work as it should!<br></div><div><br></div><div><div>Well, in the case of really wanting an imperfect oscillator, as has been said by Matt, it'd not be that hard to add microscopic DC to achieve such or whatever effect (maybe even more DC to add more noise/chaos). It's actually a common thing, I use that technique all the time... I add randomness/noise, offsets, whatever... if I wanna make it less perfect.</div></div><div><br></div><div>I really don't see the point of keeping a flawed code for a deterministic oscillator/generator that is meant to be more accurate than that in computer music systems, such as it is the case with Max and SuperCollider, to mention a couple of those - I could go on and test/mention others (Csound/Chuck) and also digital systems (Reaktor/whatever). </div><div><br></div><div>I fail to see the reason why Pd would have to be the odd one out - that one which don't really have a nice and accurate oscillator if you need it. The one you can't really build a nice and stable FM patch, because, well, it just won't sit still.</div><div><br></div><div>If dirtiness and imperfect is your secret spice in building beautiful and lively patches, you can still make it so, and there are several ways to do this... but preventing an oscillator from being accurate and in a completely arbitrary way at the expense of preventing a simple and common/regular FM patch to be built seems a bit too nonsensical IMO...</div><div><br></div><div>I guess the best way to answer this question from <span style="color:rgb(80,0,80);font-size:12.8px">Jonathan</span> is just saying and showing you have a patch that really depends on it.</div></div><div><br></div><div>On the other hand, and on the other corner of the ring, there are FM patches which would actually rely on an improvement/fix of [osc~]. So, even if some such patches pop up, well, c'mon... nice FM patches seems a priority... because, again, you can just add, if you want, any dirtiness at your own taste in DC Offset, noisiness, whatever, and you can still restore or find out a new dimension to explore in your patches.</div><div><br></div><div>cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-25 7:37 GMT-02:00 martin brinkmann <span dir="ltr"><<a href="mailto:mnb@martin-brinkmann.de" target="_blank">mnb@martin-brinkmann.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24/11/15 18:39, Jonathan Wilkes via Pd-list wrote:<br>
> Does anyone have an example of a working patch that depends on the current behavior?<br>
<br>
</span>i would not be surprised if changing osc~ would break (or at least alter<br>
the sound of) many patches which rely on fm and feedback etc.<br>
<br>
bis denn!<br>
<span class="HOEnZb"><font color="#888888">        martin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div>