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

> Does this make sense? :-D yeah, I kinda had the same idea > Can anyone explain why this kind doesn't in SC or Max? that what I'd really love to know here's my SC code that relates to my first example patch I posted here // 0Hz FM {SinOsc.ar(SinOsc.ar(100, 0, 100 * 2pi), pi/2)}.scope quite

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

On Sat, 2015-11-21 at 02:59 -0200, Alexandre Torres Porres wrote: > howdy, attached there's a patch where I was experimenting with FM > > > the waveform shouldn't change with time, but it does. Give it a while > though, 30 seconds is enough to hear a change in tone quality, then > resseting the

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

I've found the reason! Looking at the Pd source code (d_osc.c and m_pd.h) [osc~] seems to read from a 512 (1<<9) point wavetable (defined by LOGCOSTABSIZE and COSTABSIZE in m_pd.h), whereas SuperCollider's SinOsc uses 8192 points. (Both programs do their audio math with 32-bit floats.) So I

Re: [PD] Efficient FIFO in Pd: How?

On Sun, 2015-11-22 at 00:47 +0100, Christof Ressi wrote: > Just in case you don't know: There's the [fifop] object in zexy which works > with lists and also lets you set the priority. I'm sure it's also faster than > anything one can do with Pd objects. Thanks, somehow I forgot that zexy has

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

also tried in Max with [phasor~] + [cos~] all fine 2015-11-22 2:11 GMT-02:00 Alexandre Torres Porres : > well, I was trying [phasor~] + [cos~] instead of [osc~] and same thing > happens, so whatever is the deal with [osc~] seems to be also with that. > > I have to say I didn't

Re: [PD] Efficient FIFO in Pd: How?

Your [fifo-list] is very much like [list-fifo] from list-abs, which suffers from the poor [list] performance. The message-box one also suffers from having to use lists to dequeue. I've thought of a way to do it using [list fromsymbol], [list tosymbol], and an elaborate array storage scheme which

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

Try it with an 8-point table and [tabosc4~]. It's still far more stable than [osc~]. On Sat, Nov 21, 2015 at 1:50 PM, Christof Ressi wrote: > I've found the reason! Looking at the Pd source code (d_osc.c and m_pd.h) > [osc~] seems to read from a 512 (1<<9) point

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

Including the case of Pd Double @ PD_FLOAT_PRECISION == 32 On Saturday, November 21, 2015 2:40 PM, Jonathan Wilkes wrote: What's Pd Double do in this case? -Jonathan On Saturday, November 21, 2015 2:25 PM, Matt Barber wrote: Try it

Re: [PD] Efficient FIFO in Pd: How?

I was looking at the help patch for [pipe] the other day, and noticed that there has been a change. I think it was to allow symbols too. (Sorry, can't check on my phone now) On Sunday, November 22, 2015, Roman Haefeli wrote: > Hi all > > I'm looking for a way to implement

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

I've checked if there's a possible time drift between [osc~] and [tabosc4~] and there's clearly none (I had them both run in parallel for several minutes and compared the results). Then I did a testing patch (see attachment) where I take the difference between the output of [osc~] and three

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

What's Pd Double do in this case? -Jonathan On Saturday, November 21, 2015 2:25 PM, Matt Barber wrote: Try it with an 8-point table and [tabosc4~]. It's still far more stable than [osc~]. On Sat, Nov 21, 2015 at 1:50 PM, Christof Ressi

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

Even worse, for FM the 8-point table turns out to be more precise than a 512-point or 8192-point table (and no real difference between the latter two). What's going on?       Gesendet: Samstag, 21. November 2015 um 20:24 Uhr Von: "Matt Barber" An: "Christof Ressi"