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

Matt-- I don't believe that bug has been fixed. Roman-- I haven't looked closely at the relevant code, but it looks like Pd recalculates the graph-- a single graph for the runninginstance of Pd-- every time you add/remove a tilde object.  (Not sure aboutcontrol objects, but it's easy to test.)

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

While I don't know much about the draw group yet, it is conceivably possible the order by which inlets are created and depending on what kind they are could have something to do with it. Best, -- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS,

[PD] frameaccum~ missing wrap argument

originally frameaccum~ can perform a "phase wrap" just like phasewrap~ does with an argument that is non zero, this is missing in the Pd version, so you need to use both frameaccum~ and phasewrap~, which is also less efficient than a single object. >From Max's documentation Arguments

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] [PD-announce] ANN: pd-l2ork version 20150917 now available

OK, I seem to have found the culprit. A new version 20150919 of the 32bit, 64bit, and Raspberry Pi builds is now available. Please let me know if this fixes your problem. Thank you. On Sat, Sep 19, 2015 at 12:48 PM, Ivica Bukvic <i...@vt.edu> wrote: > Oops, looks like I missed a fi

Re: [PD] sampstoms~ (was Re: weird behavior of [vd~] in phave vocoder (overlapping subpatches))

in max, these objects won't convert differently in overlapping subpatches for fft, so it's a global pd thing, it'll interfere in the way many objects work, like vline~ / phasor~ / whatever... sampstoms~ is just another one, but it may be come in hand to deal with wrong time computations. anyway,

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

It doesn't look to be much different atm. In fact, I can't even figure out how subpatches actually reorder their inlets and outlets when you add new [inlet] and [outlet] objects inside them.  I have anobject in Pd-l2ork called [draw group], which is essentially just a subpatchwith an inlet-- to

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

It's a bug that conrol values aren't promoted to signals when appropriate by inlet~ objects - I tried to figure out how to fix this a couple of years ago but couldn't immediately figure it out... cheers Miller On Sat, Sep 19, 2015 at 11:20:47PM -0400, Ivica Bukvic wrote: > While I don't know

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

[PD] how to expand time limit for video delay?

Hi, list members, I've been using Pd for several years, and till now I've been able to solve my problems by myself or consulting this list, so thanks very much everyone for your help in these years. But now I've got a problem that I can´t solve, so I´ll appreciate so much your help. I'm working

Re: [PD] [PD-announce] ANN: pd-l2ork version 20150917 now available

I got this err when installing. Sure I installed the all listed dependencies. Ubuntu 14.10 64bit Pre-Installed Pd Vers: Pd 0.45.5 Pd-extended 0.43.4 $ sudo dpkg -i pd-l2ork*deb (Reading database ... 466217 files and directories currently installed.) Preparing to unpack