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@gmail.com mailto:brbrofsvl@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.
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@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@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 mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@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@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 mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 porres@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@gmail.com mailto:brbrofsvl@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@urbanstew.org mailto:robert@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@gmail.com mailto:brbrofsvl@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
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@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@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@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@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@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 mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@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@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@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@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@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 mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@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@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.htmlMoreo..., 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@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@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@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@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 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
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
On Nov 24, 2015, at 10:39 AM, Jonathan Wilkes jancsika@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@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@gmail.com mailto:brbrofsvl@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@urbanstew.org mailto:robert@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 <porres@gmail.com mailto:porres@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@gmail.com mailto:brbrofsvl@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@urbanstew.org mailto:robert@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@gmail.com mailto:brbrofsvl@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
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@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 <jancsika@yahoo.com mailto:jancsika@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@gmail.com mailto:porres@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@gmail.com mailto:brbrofsvl@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@urbanstew.org mailto:robert@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 <porres@gmail.com mailto:porres@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@gmail.com mailto:brbrofsvl@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@urbanstew.org mailto:robert@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@gmail.com mailto:brbrofsvl@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
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@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@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@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@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@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@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@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@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@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@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 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
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
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
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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2015-11-25 at 08:27 -0200, Alexandre Torres Porres wrote:
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 fully support your opinion in this debate. If I'd be in charge, I'd fix it right away.
This thread lead to an idea. I'm thinking of a Pdesafinado - a slightly out of tune Pd, that has all constants slightly wrong and some less significant bits flipped in the floating point format and other little imprecisions and deviations. It'll make totally new pieces out of all your existing patches.
I'd try it out for sure, if someone comes up with this ;-)
Roman
On 2015-11-25 12:37, Roman Haefeli wrote:
I fully support your opinion in this debate. If I'd be in charge, I'd fix it right away.
+1
if you are doing glitch - and relying on a bug in a software to get those nifty sounds *is* glitch -, then you shan't complain if bugs get fixed¹.
and of course: Pd is Open Source. if you cannot live without any given bug, fork the source and unfix the problem. or just use an old version of Pd that still inhibits the problem.
fgmasdr IOhannes
¹ hey, why doesn't Pd crash any more? my entire performance relied on that...
Sorry not to jump in before... I think in the case of this particular design flaw, the correct thing to do is to correct it but provide back compatibility (as I did earlier with hip~ and inlet~). It's quite possible nobody will ever care but it would be there in case someone did.
cheers Miller
On Wed, Nov 25, 2015 at 04:25:49PM +0100, IOhannes m zmoelnig wrote:
On 2015-11-25 12:37, Roman Haefeli wrote:
I fully support your opinion in this debate. If I'd be in charge, I'd fix it right away.
+1
if you are doing glitch - and relying on a bug in a software to get those nifty sounds *is* glitch -, then you shan't complain if bugs get fixed¹.
and of course: Pd is Open Source. if you cannot live without any given bug, fork the source and unfix the problem. or just use an old version of Pd that still inhibits the problem.
fgmasdr IOhannes
¹ hey, why doesn't Pd crash any more? my entire performance relied on that...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think (...) the correct thing to do is to correct it but provide back compatibility
Everybody happy!
2015-11-25 14:31 GMT-02:00 Miller Puckette msp@ucsd.edu:
Sorry not to jump in before... I think in the case of this particular design flaw, the correct thing to do is to correct it but provide back compatibility (as I did earlier with hip~ and inlet~). It's quite possible nobody will ever care but it would be there in case someone did.
cheers Miller
On Wed, Nov 25, 2015 at 04:25:49PM +0100, IOhannes m zmoelnig wrote:
On 2015-11-25 12:37, Roman Haefeli wrote:
I fully support your opinion in this debate. If I'd be in charge, I'd fix it right away.
+1
if you are doing glitch - and relying on a bug in a software to get those nifty sounds *is* glitch -, then you shan't complain if bugs get fixed¹.
and of course: Pd is Open Source. if you cannot live without any given bug, fork the source and unfix the problem. or just use an old version of Pd that still inhibits the problem.
fgmasdr IOhannes
¹ hey, why doesn't Pd crash any more? my entire performance relied on that...
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
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@gmail.com An: "martin brinkmann" mnb@martin-brinkmann.de Cc: "pd-list@lists.iem.at" pd-list@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@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@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis... Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]
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.
Actual patches (like the one that started this discussion) are incredibly helpful. -Jonathan
On Wednesday, November 25, 2015 4:54 AM, martin brinkmann <mnb@martin-brinkmann.de> wrote:
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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Christof Ressi -
IOhannes m zmoelnig -
Jonathan Wilkes -
martin brinkmann -
Matt Barber -
Miller Puckette -
Robert Esler -
Roman Haefeli -
Simon Iten