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

Wed Nov 25 10:04:25 CET 2015

We can all create any external we like i guess, but this is a matter of
discussing the workings and the update/fix of internal/vanilla objects such
as cos~ osc~ and tabosc4~

most of us we're surprised with this behaviour and think they should be
updated/fixed. I personally strongly don't think it is reasonable to create
new alternates in vanilla for this.

I do emphatically believe they should just be fixed and updated in the
vanilla package of objects.

creating not known externals that are not part of any major package release
and no one really knows about may not have significant impact... let us
reason, Pd Extended is no more... this means that (more than ever) vanilla
issues should be treated as vanilla issues and not as an issue that could
have a workaround in an extended package or with an external...

Unless you're asking why miller isn't thinking about creating new objects.
In which case only he could answer, but it is my understanding that vanilla
is a very compact set of objects, and newer objects are not to pop up that
easily, so don't expect it.

cheers

2015-11-25 6:06 GMT-02:00 Simon Iten <itensimon at gmail.com>:

> why not just create a new object with correct symmetry and no dc? call it
> sin~ or cycle~ or whatever…
> i don’t think a compromise is a good way.
>
> On 25 Nov 2015, at 00:01, Robert Esler <robert at urbanstew.org> wrote:
>
>
> Okay, here is a compromise.  What may be a fix, or a new feature.  It
> changes the oscillator to double precision, but costs a few more CPU cycles
> in the process.  This seems to keep things more accurate. Attached is the
> source and a compiled version for OS 10.10+ and this is the git repository
> if anyone is interested.
>   But I still say let’s keep osc~ as is and just add the double precision
> as an alternative.
>
> https://bitbucket.org/resler/osc2/overview
>
> Best,
> Rob
> <osc2~.zip>
>
> On Nov 24, 2015, at 10:39 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>
> Does anyone have an example of a working patch that depends on the
> current behavior?
>
> -Jonathan
>
>
>
> On Tuesday, November 24, 2015 9:52 AM, Alexandre Torres Porres <
> porres at gmail.com> wrote:
>
>
> > It's not that hard to add microscopic DC
> > if that's what you want
>
> I almost raised that up :) and it's easier than trying to fix it every
> time.
>
> I've lived with osc~ for over a decade, but it's like I finally found its
> dirty secret bug. Had I not found it I'd still be ok with it, but had I
> found this it years ago I'd have brought it up and asked for a fix.
>
> I think it's pushing it to compare legacy analog hardware with their
> signature sounds (which would mostly come down to filters, not sine waves)
> to an imprecise and easily fix digital code - it's not like it's the secret
> formula for digitally emulating the moog filter or something - it's just
> bad.
>
> Don't be afraid of changes and fixes, not sure what children's book teach
> us that lesson, but there might or ought to be one.
>
> cheers
>
> 2015-11-24 3:18 GMT-02:00 Matt Barber <brbrofsvl at gmail.com>:
>
> Right, there are good reasons to want that behavior, but should it be the
> default in a program that aspires to be "deterministic"? It's not that
> hard to add microscopic DC if that's what you want, or add a tiny, tiny bit
> of low-pass-filtered noise to you oscillator to make it act more like
> acoustic gear.
>
> The other thing is, Pd isn't only an audio application. The quality of an
> oscillator is context dependent, and "how does it sound" isn't always the
> most important consideration. "Can I predict how this will behave?" is the
> more important question much of the time.
>
> On Mon, Nov 23, 2015 at 11:31 PM, Robert Esler <robert at urbanstew.org>
> wrote:
>
> I think you just found one of the nuances I’m referencing.  Think of
> analog gear, none of the sinusoids are anywhere near perfect, yet we still
> like how they sound.
> We’ve known about these issues of microscopic DC, phasing, etc of unit
> generators for a long time.   I recall an old pd thread explaining how
> [osc~] is working:
> http://music.columbia.edu/pipermail/music-dsp/2004-november/061991.html
> Moreover, we’ve all lived with [osc~] for what, about 15-20 years?  It’s
> legacy code.
>      I’m probably being so adamant because I’ve been reading the "Ugly
> Duckling" to my daughter, but aren’t children’s stories also lessons in
> computer synthesis too?
>
>
> On Nov 23, 2015, at 9:05 PM, Alexandre Torres Porres <porres at gmail.com>
> wrote:
>
> moreover, I really doubt there's any particular nuance that comes out of
> this... or that a fix would break it. All I know is that it's preventing FM
> patches from achieving stable waveforms as they should.
>
> 2015-11-24 0:31 GMT-02:00 Matt Barber <brbrofsvl at gmail.com>:
>
> I usually agree in cases like these, but a sinusoid oscillator with
> built-in DC is not the expected behavior in most any synthesis environment.
> Notice how everyone in this thread was genuinely surprised by this behavior.
>
> On Mon, Nov 23, 2015 at 9:20 PM, Robert Esler <robert at urbanstew.org>
> wrote:
>
> I would call this more of a feature than a bug that needs fixing.  I would
> hope that [osc~] and [cos~] don't change, simply because many of us like
> these little nuances.
>   If it is really bothersome then perhaps create a new version, but let’s
> not change a legacy object.  A simple “fix” might break someone else’s
> patch.
>
> Just my opinion,
> -Rob
>
> Did you make it work in a patch? if so, can you share it? :)
>
> Maybe someone could work on a "fix" on the source and send it to miller,
> perhaps this could be updated for the next version release (0.47).
>
> cheers
>
> 2015-11-22 19:32 GMT-02:00 Matt Barber <brbrofsvl at gmail.com>:
>
> Yeah, so all that really needs to be done is to force symmetry by copying
> the 0-pi phase inverted to the pi-2pi phase + guard points for [tabosc4~].
> I did that and it's been stable for 3.5 hours. It wouldn't be too hard to
> fix this in the Pd source; it would be a marked improvement to [osc~] even
> with the 512-pt table and linear interpolation.
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> 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
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151125/19a3aa0b/attachment.html>