[PD] oscillators (osc~ / cycle~) not working well in FM?

[Christof Ressi]

Totally agree in every point! [osc~] should definitely be fixed, for me there's no doubt about it. If this would, however, really break some patches (examples?), why not include a legacy version of [osc~] and make it possible to set the global behaviour via a Pd message - just like it's the case with [hip~]. 
 
 

Gesendet: Mittwoch, 25. November 2015 um 11:27 Uhr
Von: "Alexandre Torres Porres" <porres at gmail.com>
An: "martin brinkmann" <mnb at martin-brinkmann.de>
Cc: "pd-list at lists.iem.at" <pd-list at lists.iem.at>
Betreff: Re: [PD] oscillators (osc~ / cycle~) not working well in FM?

I'd be really surprised if it'd "break" - that's a strong term.

 
Alter the sound a bit, maybe, sure, to a not desirable effect, maybe yes or maybe just not at all...
 
Now, conversely... any Frequency Modulation patch is really broken because it doesn't really work as it should!
 

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.
 
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). 
 
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.
 
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...
 
I guess the best way to answer this question from Jonathan is just saying and showing you have a patch that really depends on it.
 
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.
 
cheers
 
2015-11-25 7:37 GMT-02:00 martin brinkmann <mnb at martin-brinkmann.de>:On 24/11/15 18:39, Jonathan Wilkes via Pd-list wrote:
> Does anyone have an example of a working patch that depends on the current behavior?

i would not be surprised if changing osc~ would break (or at least alter
the sound of) many patches which rely on fm and feedback etc.

bis denn!
        martin

_______________________________________________
Pd-list at lists.iem.at[Pd-list at lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]_______________________________________________ Pd-list at lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]