[PD] Mutable Instruments Grids as a Pure Data external

Hi all, One module that I find very tempting and that is always threatening to pull me down the rabbit hole of eurorack madness is Mutable Instruments' Grids: http://mutable-instruments.net/modules/grids A few years ago Henri David made a Max external version of Grids (

[PD] Audio looping on the Organelle

I made a live looping patch for the Critter & Guitari Organelle by adapting Marco Baumgartner's ALFALOOP looper for the Organelle (info: http://marcobaumgartner.com/#puredata/ALFALOOP1). The record function is mapped to the lowest C key on the Organelle. Pressing record once starts recording and

Re: [PD] what's the deal with [utime] object?

> actually i think that a lot of code to review could be identified with a grep for "\bfloat\b", so the chores might not be so horrific. I doubt that would find everything, but that's certainly a good starting point if you're interested in pursuing this. -Jonathan On Sunday, February 28,

Re: [PD] what's the deal with [utime] object?

On 02/27/2016 06:09 PM, Jonathan Wilkes via Pd-list wrote: >> hmm, what again was wrong with my proposal to distinguish between single > and double precision externals, allowing to have externals that would > work on both precisions ("phat")? [...] > And that's just a single issue with type

Re: [PD] s~ & r~ with block size other than 64?

On 02/28/2016 11:03 PM, Matt Barber wrote: > Just to confirm, this bug is only on patch load, right? Does it only happen > when it's loading a table stored in a patch, or does it do the same if the > table is loaded via soundfiler it generated algorithmically? > > Is this fixable in partconv~ or

[PD] partconv~ bug (was Re: s~ & r~ with block size other than 64?)

On 02/28/2016 10:54 PM, Alexandre Torres Porres wrote: > 2016-02-28 16:08 GMT-03:00 IOhannes m zmölnig : > >> On 02/27/2016 10:33 PM, Alexandre Torres Porres wrote: >>> by the way, partconv~ is buggy, we should fix it... I emailed bsaylor a >>> couple of years ago and he said he

Re: [PD] s~ & r~ with block size other than 64?

Just to confirm, this bug is only on patch load, right? Does it only happen when it's loading a table stored in a patch, or does it do the same if the table is loaded via soundfiler it generated algorithmically? Is this fixable in partconv~ or is it a consequence of the design of the patch load

Re: [PD] s~ & r~ with block size other than 64?

2016-02-28 16:08 GMT-03:00 IOhannes m zmölnig : > On 02/27/2016 10:33 PM, Alexandre Torres Porres wrote: > > by the way, partconv~ is buggy, we should fix it... I emailed bsaylor a > > couple of years ago and he said he didnt have time for it > > what's that bug? > has it been

Re: [PD] [Bulk] Re: [Bulk] Re: How to check if a patch is vanilla

Hi Cyrille, On 28/02/2016 14:14, cyrille henry wrote: this is certainly possible, if someone spend time working on this. but my concern is : why is this important? i mean : if you don't care about conservation or portability, just start pd loading a maximum of externals and use all of them.

Re: [PD] s~ & r~ with block size other than 64?

On 02/27/2016 10:33 PM, Alexandre Torres Porres wrote: > by the way, partconv~ is buggy, we should fix it... I emailed bsaylor a > couple of years ago and he said he didnt have time for it what's that bug? has it been reported in some public place? why not? gfmards IOhannes signature.asc

[PD] Announcing native Pd patch display in MobMuPlat Android

Hi all, A little while ago, I released a version of MobMuPlat for iOS with native Pd patch rendering. https://itunes.apple.com/us/app/mobmuplat/id597679399?mt=8 Now, I'd like to announce that feature has come to Android as well!

Re: [PD] s~ & r~ with block size other than 64?

Definitely no windowing for the kind of time-domain convolution done by [partconv~]. On Sun, Feb 28, 2016 at 4:52 AM, Christof Ressi wrote: > > one of them are plain linear convolution > > of course meant: "none of them". > > > Gesendet: Sonntag, 28. Februar 2016 um 10:49

Re: [PD] [Bulk] Re: How to check if a patch is vanilla

I tried to install via deken all externals disponibles for Mac in vanilla 0.46-7 to load all patches of the world, but I was stopped because pd limit the number of loading path externals in 98 libraries. What the importance of this limitation? Em dom, 28 de fev de 2016 10:15, cyrille henry

Re: [PD] [Bulk] Re: How to check if a patch is vanilla

Le 28/02/2016 13:26, Alessio Degani via Pd-list a écrit : On 27/02/2016 16:35, IOhannes m zmölnig wrote: On 02/27/2016 12:05 PM, Alessio Degani via Pd-list wrote: Is there a simple way to chek if a pd patch is made only using vanilla object? Hi IOhannes, as in: install Pd-vanilla, start

Re: [PD] [Bulk] Re: How to check if a patch is vanilla

Hello, One possibility : A patch is a text file. In this file each object is represented with a line beginning with : #X obj ... For example, a [drip] at position (179,93) is : #X obj 179 93 drip; So it could be doable, with the [text] object, to analize your patch and return each object. Then

Re: [PD] [Bulk] Re: How to check if a patch is vanilla

On 27/02/2016 16:35, IOhannes m zmölnig wrote: On 02/27/2016 12:05 PM, Alessio Degani via Pd-list wrote: Is there a simple way to chek if a pd patch is made only using vanilla object? Hi IOhannes, as in: install Pd-vanilla, start it with "-noprefs -verbose" and load the patch? Thank you

Re: [PD] s~ & r~ with block size other than 64?

> one of them are plain linear convolution of course meant: "none of them". > Gesendet: Sonntag, 28. Februar 2016 um 10:49 Uhr > Von: "Christof Ressi" > An: "Matt Barber" > Cc: "pd-list@lists.iem.at" > Betreff: Re: [PD] s~ & r~

Re: [PD] s~ & r~ with block size other than 64?

All the FFT example patches work with squared hann-window and overlap 4 and the FFT examples I've seen in books do as well. On the other hand, when I think of it, one of them are plain linear convolution of two audio signals, at least one of the two spectra is always somewhat arbitray (e.g.