Re: [PD] opposite behaviour of [delay]

While we're talking about ways to limit output of message delays (etc.), check out also the [debounce] abstraction in extended. Alexandre's attached idiom is quite common in other areas, too, like protecting a [readsf~] from all input until it has finished playing, or halting all input to a synth

Re: [PD] Window menu

I also use it all the time for the same reason Roman does. Also the (on OSX) command-R to bring up the Pd window is essential. On Tue, Nov 10, 2015 at 4:57 AM, Roman Haefeli wrote: > On Tue, 2015-11-10 at 02:01 +, Jonathan Wilkes via Pd-list wrote: > > Hi list, > > Does

Re: [PD] need help with recursive patching for arithmetic patch

If it were me I would patch a parser that did several passes iteratively instead of recursively: 1) Check for unbalanced parens, and count nesting depth 2) Pass all parts of the list unchanged, except those constitute a max depth expression, which are evaluated and substituted 3) Repeat 2 until

Re: [PD] strange behaviour for look up table operation

Hi, My guess is that the problem is a difference in the exact floating point representation of each 0.8f which gets propagated through the multiplication, which will unfortunately give you index trouble with these very large indices. The closest binary representation of 0.8 is: 0.80012 =

Re: [PD] SineFill (sinesum, but for all phases) in Pd?

I'm including an abstraction for that in my array-abs library, but haven't implemented it yet. https://github.com/brbrofsvl/array-abs On Fri, Nov 13, 2015 at 9:47 AM, Alexandre Torres Porres wrote: > Hi, in SC they got this SineFill command, which can generate waveforms as >

Re: [PD] brown/grey noise in pd

You can get an approximate brown noise by running a noise source through [fexpr~ if(abs($x+$y)>1.0,$y-$x,$x+$y)] (an integrator with +/- 1 bounds. Scale your noise source by somewhere in the 0.05 to 0.001 range (I don't know the exact value). If you want a quasi-gaussian noise source, you can

Re: [PD] brown/grey noise in pd

Absolutely. Also don't forget about [swap] if you also eventually need to change the dividend, and/or the numbers arrive out of order. | / [swap 50] | / [/ ] On Sun, Nov 15, 2015 at 3:58 AM, Roman Haefeli wrote: > [expr 50/$f1] can also be expressed as > > [50

Re: [PD] ALSA loopback and Pd

And if aplay won't output to jack, you could try ecasound. On Nov 14, 2015 8:59 AM, "Simon Iten" wrote: > this would be easier with your name :-) > > use jack. > > On 14 Nov 2015, at 14:49, Jack wrote: > > > > Hello, > > > > I try to use ALSA loopback

Re: [PD] Array List View

Somehow I didn't know about this, but now I intend to use it all the time. Thanks for the "arrayviewlistnew" hint, too. On Thu, Nov 12, 2015 at 2:32 AM, katja wrote: > Array list view is useful for debugging. I rarely open it via properties > menu, but mostly via message

Re: [PD] Fwd: chord libraries?

ing. Sorry if that makes this slightly > unclear. --BH > > > > -- Forwarded message -- > From: Matt Barber <brbrof...@gmail.com> > Date: Monday, November 2, 2015 > Subject: chord libraries? > To: William Huston <williamahus...@gmail.com> > > >

Re: [PD] looking for other vanilla filters or abstractions for libPD

​There are some things also that can't be translated out of expr into vanilla Pd, so allowing users to swap in files is kind of abstract. The lack of a vanilla bitwise XOR [^] in vanilla has been killing me lately. It's in expr, but there's really no viable substitute for it using vanilla objects.

Re: [PD] chord libraries?

make inversions, and maybe throw in some > substitutions. > > I have a 4x4 drum pad controller, which I want to use to play a drone > chord, and move through a map, while I play a lead with my right hand. > > I really like what this guy has done (but there are many maps like t

Re: [PD] chord libraries?

Depends also what you mean by "common 3 and 4 note chords." If you don't count pitch inversions of a chord as the same type (e.g. if you want to be able to say that a major triad is different from a minor triad), there are 19 total 3-note chords in 12TET (to within respacing and transposition),

[PD] Reasonable rfft computation time

Hi list, As part of my array-abs library – https://github.com/brbrofsvl/array-abs – I'm including fft abstractions. I've just finished the rfft one (needs some polish, so it's not on github yet); my question is, I'm not sure what a reasonable computation time for rfft would be using vanilla Pd

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

I meant 32 points, sorry. You can usually assume I'm typing with a crying baby in my lap. :) On Fri, Oct 16, 2015 at 4:14 PM, IOhannes m zmölnig <zmoel...@iem.at> wrote: > On 10/16/2015 03:50 AM, Matt Barber wrote: > > Basically, for [block~] sizes less than 32 bits, [fft~]

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

It's actually twins. It's a complex situation; I don't yet know which is real and which imaginary. On Fri, Oct 16, 2015 at 5:29 PM, Jaime E Oliver <jaime.oliv...@gmail.com> wrote: > laptop baby > > On Oct 16, 2015, at 5:12 PM, Matt Barber <brbrof...@gmail.com> wrote: > &g

Re: [PD] prevent console error messages

​A simpler thing would be to just have any object that deals with file i/o to return something like an "exit status" on a read or after a write attempt. As long as we're wishing for stuff, I wish vanilla included the [error] object for proper error handling in abstractions. And a bitwise XOR. On

Re: [PD] prevent console error messages

It behaves like print but instead of just printing the message, it treats all input as an error. On Oct 14, 2015 5:15 PM, "Matt Barber" <brbrof...@gmail.com> wrote: > I think error is in the log library. > > Did the license issue with expr ever get sorted? > On Oct

Re: [PD] readsf~ and writesf~, locking, blocking and real-time priority

right, the designer has a choice as to how data is accessed and > should know the potential consequences. Education is still key. > > -Rob > > On Oct 6, 2015, at 11:15 PM, Matt Barber <brbrof...@gmail.com> wrote: > > ​Out of curiosity, can you give a test case where my id

Re: [PD] readsf~ and writesf~, locking, blocking and real-time priority

. > > > Perhaps this is useful in some cases but I don't think it would be > often - > > > and the downside is that it wouldn't be deterministic (a fundamental > design > > > principle of Pd). > > > > > > cheers > > > Mille

Re: [PD] Strange behaviour when sending sinesum commands to arrays

This may be an example of something we talked about recently in the forum with arrays. When you first open the patch, the arrays are not part of any dsp chain, and you can set them almost with impunity. Once you access them with [tabread4~], though, any change you make to any of the arrays that

Re: [PD] Strange behaviour when sending sinesum commands to arrays

In this case the array knows its size and sinesum always requests a size, so those could be compared before running an actual resize. On Oct 8, 2015 3:22 AM, "IOhannes m zmoelnig" <zmoel...@iem.at> wrote: > On 2015-10-08 02:01, Matt Barber wrote: > > I can't think of

Re: [PD] Strange behaviour when sending sinesum commands to arrays

​I haven't tried this in a while, but it might be worth ​trying to build a custom sinesum abstraction that fills the tables manually with an until loop and then normalizes them. This may take too long, though. There's probably another solution with [tabsend~] and [tabreceive~] where you write the

Re: [PD] Strange behaviour when sending sinesum commands to arrays

t; the web so right now I can hardly experiment with this. Where could I start? > > Benoît Fortier > > > > > Le jeudi 8 octobre 2015 13h16, Matt Barber <brbrof...@gmail.com> a écrit : > > > ​I haven't tried this in a while, but it might be worth ​trying to build a &

[PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

Hi list, There's either a major bug in the [fft~] objects in Pd-0.46.7 (64bit OSX) or I'm going crazy. I'd love to see if others can reproduce it. Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform -- it just passes the signal through unchanged. [ifft~] does the same. The

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

OK, looking at the OOURA code, the init routine has this: static int ooura_init( int n) { n = (1 << ilog2(n)); if (n < 64) return (0); then later in the fft/ifft routine: if (!ooura_init(2*n))

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

object if it seems like this is a big enough problem. > > > On Oct 16, 2015, at 4:09 PM, Matt Barber <brbrof...@gmail.com> wrote: > > OK, looking at the OOURA code, the init routine has this: > > > static int ooura_init( int n) > { > n = (

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

-- > Dan Wilcox > @danomatika <https://twitter.com/danomatika> > danomatika.com > robotcowboy.com > > On Oct 16, 2015, at 4:54 PM, pd-list-requ...@lists.iem.at wrote: > > *From: *Jonathan Wilkes <jancs...@yahoo.com> > *Date: *October 16, 2015 at 4:06:06 PM MDT >

[PD] CPU usage of block delay vs. delread~-delwrite~

Hi list. If I want to delay a signal by 448 samples, I can either use a delread~-delwrite~ pair in connected subpatches (in order to force correct scheduling), or I can [inlet~] it into a subpatch with [block~ 512] and [outlet~] it back out to the parent (whose block size is 64). I haven't done

Re: [PD] array-abs

Agreed, "drip" is awful. I had one included and then removed it because I hated the name, and it's not that much to hook an iterator to a table reader (and you have the indices to work with in whatever way you need as well). Speaking of which, on my machine [array get] is faster than plain

Re: [PD] readsf~ and writesf~, locking, blocking and real-time priority

> > 4) Has anyone ever “broken” these objects or experienced glitching? ​Once in 2005 we were having awful trouble streaming through Pd but we were never sure whether it was [readsf~] per se, a very slow disk, or xruns in ALSA/JACK, and we had only one performance laptop available. My best guess

Re: [PD] Pd internal font size inconsistency on Raspbian

Maybe we should design a Pd gridfont (see http://cogsci.indiana.edu/gridfonts.html ). Every letter is just line segments connecting dots on the same standard grid, so you wouldn't need to worry about metric translation at all -- just specify the dimensions of the grid in pixels. Of course then Pd

Re: [PD] Strange behaviour when sending sinesum commands to arrays

being naive, but what about dynamic patching? Could it be > possible to create (and delete) tables on the fly depending of my needs? I > find it very hard to find a good documentation about dynamic patching on > the web so right now I can hardly experiment with this. Where could I st

Re: [PD] brown/grey noise in pd

tika <https://twitter.com/danomatika> > danomatika.com > robotcowboy.com > > On Nov 14, 2015, at 2:38 PM, pd-list-requ...@lists.iem.at wrote: > > *From: *Alexandre Torres Porres <por...@gmail.com> > *Date: *November 14, 2015 at 2:09:54 PM MST > *To: *Matt Barber <brb

Re: [PD] brown/grey noise in pd

ounter = counter; ​​ RPUT } void GrayNoise_Ctor(GrayNoise* unit) { ​​ SETCALC(GrayNoise_next); ​​ unit->mCounter = 0; ​​ GrayNoise_next(unit, 1); } On Sat, Nov 14, 2015 at 6:15 PM, Matt Barber <brbrof...@gmail.com> wrote: > ​The nice thing about supercollider is that

Re: [PD] unexpected [array max] and [array min] behavior

iled version (other stuff to fix too :) > > M > > > On Fri, Sep 04, 2015 at 05:51:15PM -0400, Matt Barber wrote: > > Hi list, > > > > I've been playing around with the new(ish) [array] object suite in > vanilla > > 0.46.6. Forgive me if this is already a known is

[PD] unexpected [array max] and [array min] behavior

Hi list, I've been playing around with the new(ish) [array] object suite in vanilla 0.46.6. Forgive me if this is already a known issue, but it looks like the min and max arguments aren't working properly. The second inlet (setting the number of points to search) works as expected. The first

Re: [PD] unexpected [array max] and [array min] behavior

> more soon, off to a party to welcome the excellent Natacha Diels to our > department :) > > M > > On Fri, Sep 11, 2015 at 04:14:47PM -0400, Matt Barber wrote: > > Thanks for the fix in 0.46.7. There are a couple more subtle problems > > having to do with bounds checkin

Re: [PD] A patch to create a patch to create a patch to create a patch to close puredata...

net> wrote: > Masterpieces !! :-D > > Are those patchs the ones Benjamin was talking about few answers before ? > (He saw them at the PdConv in Montreal) > > I take this opportunity to post my last work : > > https://vimeo.com/139090261 > > Cheers > > °1 >

Re: [PD] unexpected [array max] and [array min] behavior

2015 at 8:11 PM, Miller Puckette <m...@ucsd.edu> wrote: > Yep :) > > M > > On Fri, Sep 04, 2015 at 07:46:30PM -0400, Matt Barber wrote: > > Thanks. > > > > I meant to say that there was the same problem in [array min], but you > > probably caught it

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

Alexandre, Looking at your original question, G05.execution.order says the following: "If you're writing to and reading from a delay line, you have to get the write sorted before the read or else you'll never get less than a block's delay." As the others have pointed out, there are basically

Re: [PD] How does vline~ work under the hood?

Very quickly: 1) vline~ stores a linked list of events with start times and target times (the end point of the linear movement) using the t_vseg struct; events are scheduled in the vline_tilde_float routine. 2) vline_tilde_new sets all of the relevant struct members. You'll want to see how the

Re: [PD] equality and void * pointers

As I understand it, you can compare void pointers because they just store addresses. In g_editor.c: static int glist_dofinderror(t_glist *gl, void *error_object) { t_gobj *g; for (g = gl->gl_list; g; g = g->g_next) { if ((void *)g == error_object) { /*

Re: [PD] Font size on Windows and Linux

There was a problem in extended some years ago when tcl/tk 8.5 broke a lot of font stuff by trying to do too much automatically, which caused some cross-platform trouble. I ended up having to make a wrapper for linux that momentarily changed the screen DPI, since 8.5 would use that to size fonts,

Re: [PD] array-abs

remember if I have access to anything officially Pd related). Matt On Sat, Oct 3, 2015 at 4:22 PM, IOhannes m zmölnig <zmoel...@iem.at> wrote: > hi, > > great! > > On 10/03/2015 07:36 PM, Matt Barber wrote: > > > > https://www.dropbox.com/s/45tk62dpz0z2mqo/array-abs.z

Re: [PD] equality and void * pointers

the top > 10 C > programming references available from Amazon with free shipping? > > -Jonathan > > > > On Thursday, October 1, 2015 7:32 PM, Matt Barber <brbrof...@gmail.com> > wrote: > > > As I understand it, you can compare void pointers because t

Re: [PD] equality and void * pointers

And just for the heck of it... > 3) is there a way to create something like [readpd~] which would take > indices > as input and output the corresponding bytes of the running Pd instance? :) > > -Jonathan > > > > > > On Thursday, October 1, 2015 11:22 PM, Matt Barber &l

Re: [PD] array-abs

Although, I can imagine a certain hipster cred for sharing software via floppy in 2015. On Sat, Oct 3, 2015 at 4:32 PM, Matt Barber <brbrof...@gmail.com> wrote: > Thanks. > > Yes. Right now I'm just looking to see if these would be useful, if > there's anything awfu

Re: [PD] array-abs

wrote: > On 10/03/2015 10:32 PM, Matt Barber wrote: > > When I get them polished a > > bit I'll do a regular release on the normal channels (I can't remember > if I > > have access to anything officially Pd related). > > hmm, it seems ew have very different concepts on what

Re: [PD] array-abs

0 7 0; > #X connect 6 0 9 0; > #X connect 7 0 6 1; > #X connect 8 0 6 1; > #X connect 9 0 3 0; > #X connect 9 1 2 1; > #X connect 11 0 10 0; > > cheers > Miller > > On Sun, Oct 04, 2015 at 02:27:37PM -0400, Matt Barber wrote: > > Your [pd drip] does a lot o

Re: [PD] array-abs

a. 340-400ms > > To me this result was a bit surprising... > > You can test yourself with the attached patch. > *Gesendet:* Sonntag, 04. Oktober 2015 um 17:32 Uhr > *Von:* "Christof Ressi" <christof.re...@gmx.at> > *An:* "Matt Barber" <brbrof...@gma

Re: [PD] array-abs

It takes almost a full second to output a list of n=1,000,000 with a 100-cycle until on my computer. On Sun, Oct 4, 2015 at 3:38 PM, Matt Barber <brbrof...@gmail.com> wrote: > This is still much slower than [list-drip], and it freezes Pd for me when > I get up to lists of n=100,

Re: [PD] array-abs

ursion in Pd. That the actual author of Pd's messaging > system refrains from using recursion to solve the same problem adds > weight to that point. > > -Jonathan > > > > > > On Sunday, October 4, 2015 3:45 PM, Matt Barber <brbrof...@gmail.com> > wrote: > > > I

Re: [PD] How does vline~ work under the hood?

Post some code. :) In both [line~] and [vline~] I believe the increment is calculated, set, and unset set once per event, since all the info you need for the ramp is given by the event definition. Unsetting it is the fun part -- it doesn't unset once it's reached its target, but rather once the

Re: [PD] How does vline~ work under the hood?

Pd does the increment and time stuff in double precision. You're likely losing precision by going with float for everything; if you divide 100/44100 and get a float, and then increment 0 with it 44100 times, you're not necessarily going to end up with exactly 100 at the end. See attached. M On

Re: [PD] How does vline~ work under the hood?

You'll get zipper noise with the samphold per block approach. Cost to dereference a struct member is probably a little more than just using or getting a value. It's possible it'll be cached, though. On Oct 2, 2015 5:26 PM, "Jonathan Wilkes via Pd-list" wrote: > There are

Re: [PD] How does vline~ work under the hood?

hearing zipper noise. (Also made a little Pd demo using [bang~] and a counter, but I don't know what I did with it.) -Jonathan On Friday, October 2, 2015 7:41 PM, Matt Barber <brbrof...@gmail.com> wrote: You'll get zipper noise with the samphold per block approach. Cost to dereference a

Re: [PD] How does vline~ work under the hood?

It depends on what you mean by "trigger". Triggered by the mouse, I think you're right. But see the attached patch. Since [del] (among other objects, but I used [del] here for clarity) can schedule bangs between boundaries, you can trigger [vline~] in the middle of blocks. Not so with [line~]: if

Re: [PD] How does vline~ work under the hood?

have to come clean and say I'm just > kidding.) > > -Jonathan > > > > On Saturday, September 26, 2015 7:46 PM, Matt Barber <brbrof...@gmail.com> > wrote: > > > Well, obviously it depends on what you want to use the lines for. If it's > just to fade someth

Re: [PD] How does vline~ work under the hood?

Well, obviously it depends on what you want to use the lines for. If it's just to fade something in or out over 10-50 ms to avoid a discontinuity, it's not that big a deal. Moreover sometimes it's great to have the ends and beginnings of ramps happen at block boundaries; e.g. when [switch~]ing off

Re: [PD] How does vline~ work under the hood?

As always, it's good to include a demo patch when you have a question like this. I wasn't sure what you meant by "jitter" initially, but now I understand it because [line~] isn't translating your [metro] faithfully. You can see that jitter in the patch I attached above. It's important to see how

Re: [PD] How does vline~ work under the hood?

The ramp segments themselves are pretty simple once they get going -- the entire thing is calculated at once, and then it's just a matter of adding the resulting constant increment until the target time has elapsed, or a new event supersedes the current ramp. This is less than the interpolation

Re: [PD] Understanding the mechanics of rebuilding Pd's DSP graph

;? Seems > like > it has an interface to add/remove parts of its dsp graph, and it can do so > in a > much more efficient manner. > > -Jonathan > > > > On Saturday, September 19, 2015 10:56 PM, Matt Barber <brbrof...@gmail.com> > wrote: > > > One more thi

Re: [PD] getting [inlet~] to accept data

I worked on this for a while in 2008. A big part of the problem is that the architecture for first/main inlets is quite different from generic inlets, which do not respond to both signals and messages. [inlet~] does (or at least is supposed to) promote floats to signals, but it won't pass other

Re: [PD] Understanding the mechanics of rebuilding Pd's DSP graph

One more thing to think about is how the DSP graph is handled using dynamic patching. For a long time there was a "bug" where the last audio object added didn't trigger a recalculation and would be left out of the DSP graph until the next edit. Is this still the case? The workaround, if I remember

Re: [PD] reading arrays from an external

I'm pretty sure that the [tab*] objects just point into existing arrays rather than copying them. Each time [tabread] receives a float, for instance, it checks to see if the array it has been set to read from exists, and if so, updates a pointer to the indicated index of the array, and grabs the

Re: [PD] A patch to create a patch to create a patch to create a patch to close puredata...

gt; > > > https://vimeo.com/139090261 > > > > Cheers > > > > °1 > > > > > > Le 12/09/2015 07:13, Matt Barber a écrit : > >> Jonathan Wilkes and I made these a few years ago. Run "orthodox" first > >> to get

Re: [PD] Understanding the mechanics of rebuilding Pd's DSP graph

There's nothing wrong per se with resizing an array -- but there are good reasons not to do it while a patch is running after a [tab*] object has referred to it. I have myself only noticed audio dropouts when I'm resizing a table with soundfiler; I thought it must have been a disk-access

Re: [PD] array-abs

elf isn't elucidating anything useful > about > the flow of data. For that you'd need some way to animate the flow through > the wires in greater than zero logical time. And even then you'd want to > show > the actual data associated with each cycle of animation. > > -Jonathan &g

Re: [PD] readsf~ and writesf~, locking, blocking and real-time priority

ess" won't just tell me when it has actually opened the file. Why > does thecomputer get to know when it's ready, but we students have to guess > bylistening for glitches? > > -Jonathan > > > > > > > > On Tuesday, October 6, 2015 1:02 AM, Matt Bar

Re: [PD] Moving Sum object?

mented as a recursive filter (like in both our patches), it is > still a FIR filter (and therefore it defeats the notion that recursive > filters are always IIR filters). The impulse response is just a rectangular > pulse and therefore finite. > > > > Gesendet: Diensta

Re: [PD] Moving Sum object?

sums a series > of samples. If you don't want the average but rather the true sum, either > multiply the output by the number of samples or take my abstraction and get > rid of the [/~] object. > > > Gesendet: Dienstag, 08. Dezember 2015 um 12:21 Uhr > Von: "Alexandre T

Re: [PD] filename from path

The newest vanilla versions have [list fromsymbol] and [list tosymbol]. If you write it the output of [list fromsymbol] into an array using [array set] you can find the last / character (ascii 47), [array get] the rest ([list length] will help you figure out how much to get), and turn it back into

Re: [PD] Windows: adc~: no method for 'set'

Same on OSX (0.46.7 Vanilla). On Fri, Dec 4, 2015 at 8:30 AM, Roman Haefeli wrote: > Hey > > The 'set' method for [dac~] and [adc~] does not work in Windows. I get: > > adc~: no method for 'set' > > Since recently, even the 'Test Audio and MIDI' patch uses this feature. >

Re: [PD] chord libraries?

ally fine with dealing with just the chords on the > Mugglin Chord Map. I understand that this is a very incomplete > solution. > > Many thanks for the link to Tonnetz! > > Again, I appreciate all of the guidance and suggestions! > BH > > > > On Tuesday, November 3,

Re: [PD] abstractions for [array] (was filename from path)

ust one outlet) ? > > > Le 01/12/2015 16:54, Jack a écrit : > > Yes, [array-split] is not a good name as mentioned iohannes, let's > > go for [array-list2symbol]. Do what you want with these abs to > > adapt them for your set if needed. ++ > > > > Jack > >

Re: [PD] Getting off the ground with OSC

Not OSC, but for persistence I've usually stored control values in an array and saved the contents of that array. You can also use textfiles or even qlists if you need to store more than numbers.​ ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and

Re: [PD] 0 length delay in delwrite~

> > BTW: having a [delread~] at a smaller block size than the [delwrite~] will > create junk output because [delread~] will read at a faster rate than > [delwrite~] can actually update the buffer, leading to weird looking > repetitions in the waveform. ​I think this is more a function of the way

Re: [PD] 0 length delay in delwrite~

The docs are right in one sense (at least for block = 64), but probably misleading: min delay possible is zero, but to get zero delay [delwrite~] needs to compute before [delread~]. Max delay is given in [delwrite~], but to attain the max delay, [delread~] needs to compute before [delwrite~].

Re: [PD] 0 length delay in delwrite~

There's one trick that works for zero delay and [delwrite~ 0], based on the code of [delread~]: provide a negative delay time (with abs(delay time) > 1 sample). Here's what's going on in Alexandre's patch. [delwrite~ 0] sets up a buffer that is 68 samples long, plus four extra for interpolation

Re: [PD] 0 length delay in delwrite~

And I think the same logic will apply to any [delread~] buffer explicitly set to <= 60 samples ([delread~] rounds up from the input to the nearest multiple of 4). On Sat, Dec 12, 2015 at 4:49 PM, Matt Barber <brbrof...@gmail.com> wrote: > There's one trick that works for zero delay a

Re: [PD] Array List View

want to try update an audio > array > > list view in real time! > > > > On Fri, Nov 13, 2015 at 1:32 AM, Jonathan Wilkes <jancs...@yahoo.com> > wrote: > > > > I don't know. Something like this with the guts hidden? > > > > I didn't do the hard stuff, like han

Re: [PD] FM matrix with feedback

[rpole~] can be a good option depending on the kind of flexibility you need. Why the distaste for [block~] size of 1 if it works? Do you have some pseudocode or a block diagram? That would make it easier to give advice. On Fri, Jan 8, 2016 at 11:53 AM, David Medine wrote: >

Re: [PD] Create own error message that's findable?

The log library has just such an [error]. On Fri, Jan 8, 2016 at 11:51 AM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote: > Well, I guess it's the function _prototype_ that's in m_pd.h, to be > precise... > > -Jonathan > > > On Friday, January 8, 2016 11:47 AM, Jonathan Wilkes via

Re: [PD] Window Functions

ons: the DC component preserves the original > signal, while the cosine component produces sum- and difference > frequencies which cancel each other in subsequent overlaps after IFFT. > Long story and illustrations here: > > http://www.katjaas.nl/FFTwindow/FFTwindow > > Katja

[PD] Window Functions

Hi list, quick DSP question. In I02.Hann.window.pd there is a Hann window computed by running an [osc~] for one cycle over 512 samples. Doing it this way is simple but it means that it doesn't taper all the way to 0 on the right (the next value of the oscillator after writing the table is 0). I

Re: [PD] A "Ramp" object?

​Check these out.​ I think what you're looking for is inside of noisei~. Sorry for no helpfile, but you can make it easily enough. Inlet controls frequency of new value generation (audio rate is possible). On Wed, Nov 25, 2015 at 2:44 PM, Alexandre Torres Porres wrote: >

Re: [PD] 64 bit audio?

​You probably don't want Pd dithering behind the scenes without you knowing it. There are a couple of things to consider, though: Dithering for 24-bit output isn't generally necessary, since most audio devices don't have true 24-bit ADC/DAC, and even with perfect equipment the noise floor is

Re: [PD] Fwd: filename from path

Yep. I'll happily include them with some modification, including names. [array-list2symbol] is good. I'd also probably change it to [array-basename] since that is the unix/linux command, but I'll be glad to be convinced otherwise. I'll look through them later today. I recently finished an

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

ould be updated for the next version release (0.47). > > cheers > > 2015-11-22 19:32 GMT-02:00 Matt Barber <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 poin

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?

e carrier but the problem is the > modulator. Once you use [tabosc4~] as the modulator, the drift is minimal > (but it's still there). Actually it doesn't matter if you use [osc~] or > [tabosc4~] as the carrier. (See my attached patch). > >>>>> > >>>>> I te

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

... with inlet~ and outlet~ obviously On Sun, Nov 22, 2015 at 9:59 AM, Matt Barber <brbrof...@gmail.com> wrote: > This means we should be able to subtract out the DC in PD itself, as a > workaround. If it works, you could make an abstraction for modulating > oscillator: > >

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

​You'd store the number of elements in the list at the first index of a fifo entry and the number of elements in the symbol or float just before the data for each atom -- on read you'd accumulate the atoms of the list and stop. The next index would be the number of elements in the next fifo list

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

OK, subtracting out the DC is more stable, but still deteriorates after a bit, since the exact value likely changes with frequency due to interpolation. So the solution is going to have to be in writing the table. We can do it in Pd but we're hampered by the six-digit limit on specifying 2pi

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

with the 512-pt table and linear interpolation. On Sun, Nov 22, 2015 at 12:43 PM, Matt Barber <brbrof...@gmail.com> wrote: > OK, subtracting out the DC is more stable, but still deteriorates after a > bit, since the exact value likely changes with frequency due to > interpolation.

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

@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

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

the next version release (0.47). > > cheers > > 2015-11-22 19:32 GMT-02:00 Matt Barber <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

Re: [PD] band limited (anti-alias) techniques

There's also the band-limited pulse wave (Dirichlet kernel oscillator), like gbuzz in csound. See attached. On Mon, Nov 23, 2015 at 9:07 PM, Christof Ressi wrote: > I can think of at least two: > > 1) wavetables filled with sinesum/cosinesum (possibly blending between >

  1   2   3   >