I'm using that as rarely as I can, so far only for bug fixes. I don't think a limit on numerical accuracy is exactly a bug. I think it's nicer to most users not to have them have to bother with specifying a compatibility version.
cheers Miller
On Wed, Aug 04, 2021 at 11:09:06PM +0200, Christof Ressi wrote:
Hi Miller,
isn't this the perfect use case for the compatibility flag? Or do you think the change would be too invasive? After all, you have also changed the frequency response of [hip~] (Pd 0.44) and the behavior of the [stop( method for [line] (Pd 0.48).
I'm still struggling to figure out how to best allow alternative tables (especially larger table sizes when needed) without badly complicating everything.
If someone needs a sine wave oscillator with higher quality, they can simply use [tabosc~]. I don't think it's necessary to add anything to [osc~].
Just my 2c.
Christof
On 04.08.2021 21:15, Miller Puckette via Pd-dev wrote:
Unfortunately they can't be fixed by default (compatibility...) I'm still struggling to figure out how to best allow alternative tables (especially larger table sizes when needed) without badly complicating everything.
cheers M
On Wed, Aug 04, 2021 at 03:09:26PM -0400, Matt Barber wrote:
Hi Andy, Thanks for the reply. sinesum is better but not perfect – the issue is that the cos() function is not the same on all four parts of the waveform, and those imperfections can cause fm to drift. You can build a symmetric table easily enough but since osc~ and cos~ are so important, they should be fixed. I'll submit a demo patch when I get home.
Matt
On Wed, Aug 4, 2021, 2:50 PM Andy Farnell padawan12@obiwannabe.co.uk wrote:
I always found that [tabosc4~] along with ability to fill arrays using like csound gen message functions [sinesum( gives me all the accuracy I needed for FM. Am I missing something in pull/106 about shorcomings of [osc~]
andy
On Wed, Aug 04, 2021 at 10:55:02AM -0400, Matt Barber wrote:
I'd love to get a symmetric cos table for stable FM:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_...
But I remember you were thinking about going another direction entirely with osc~?
Thanks,
Matt
On Tue, Jul 13, 2021 at 1:23 PM Miller Puckette via Pd-dev < pd-dev@lists.iem.at> wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next
month
or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go
through
small proxy objects; this will have to be done at load time I think)
and
to go back and try to figure out how to do tooltips without adding
cruft to
the inlet structure. (There's an ancient source-patch to provide
tooltips
by Chris McCormichadn Guenter Geiger that I plan to start with - https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_pure-... ).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to
move
a few functions from one file to another.
This might break some PRs, so... first of all would be to identify
whatever
PRs are ready to merge so I can do that before I make incompatible
changes.
Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or
lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...