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 <rob...@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 > <https://bitbucket.org/resler/osc2/overview> > > Best, > Rob > <osc2~.zip> > >> On Nov 24, 2015, at 10:39 AM, Jonathan Wilkes <jancs...@yahoo.com >> <mailto:jancs...@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 >> <por...@gmail.com <mailto:por...@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 <brbrof...@gmail.com >> <mailto:brbrof...@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 <rob...@urbanstew.org >> <mailto:rob...@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 >> <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 <por...@gmail.com >>> <mailto:por...@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 <brbrof...@gmail.com >>> <mailto:brbrof...@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 <rob...@urbanstew.org >>> <mailto:rob...@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 <brbrof...@gmail.com >>>> <mailto:brbrof...@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@lists.iem.at <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@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@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
