Pd-list September 2015

pd-list@lists.iem.at

62 participants
88 discussions

Start a nNew thread

Re: [PD] 8 point average filter with biquad and raw filters?
by Christof Ressi 09 Sep '15

09 Sep '15

3 4

[declare -stdpath] has no effect on Windows
by Roman Haefeli 09 Sep '15

09 Sep '15

Hi all I hoped to be able to dig into it myself, but I can't figure out why it is behaving different on Windows compared to Linux. [declare -stdpath osc] has no effect on Windows. I have 'osc' installed in <pd-path>\extra\osc and when I create [routeOSC /bla], the Pd output looks like this: tried Z:/home/roman/routeOSC.m_i386 and failed tried C:/Program Files/Common Files/Pd/routeOSC.m_i386 and failed tried C:/users/roman/Application Data/Pd/routeOSC.m_i386 and failed tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC.m_i386 and failed tried Z:/home/roman/routeOSC.dll and failed tried C:/Program Files/Common Files/Pd/routeOSC.dll and failed tried C:/users/roman/Application Data/Pd/routeOSC.dll and failed tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC.dll and failed tried Z:/home/roman/routeOSC/routeOSC.m_i386 and failed tried C:/Program Files/Common Files/Pd/routeOSC/routeOSC.m_i386 and failed tried C:/users/roman/Application Data/Pd/routeOSC/routeOSC.m_i386 and failed tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC/routeOSC.m_i386 and failed tried Z:/home/roman/routeOSC/routeOSC.dll and failed tried C:/Program Files/Common Files/Pd/routeOSC/routeOSC.dll and failed tried C:/users/roman/Application Data/Pd/routeOSC/routeOSC.dll and failed tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC/routeOSC.dll and failed tried Z:/home/roman/routeOSC.pd and failed tried C:/Program Files/Common Files/Pd/routeOSC.pd and failed tried C:/users/roman/Application Data/Pd/routeOSC.pd and failed tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC.pd and failed tried Z:/home/roman/routeOSC.pat and failed tried C:/Program Files/Common Files/Pd/routeOSC.pat and failed tried C:/users/roman/Application Data/Pd/routeOSC.pat and failed tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC.pat and failed tried Z:/home/roman/routeOSC/routeOSC.pd and failed tried C:/Program Files/Common Files/Pd/routeOSC/routeOSC.pd and failed tried C:/users/roman/Application Data/Pd/routeOSC/routeOSC.pd and failed tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC/routeOSC.pd and failed routeOSC /bla error: ... couldn't create (The output is actually from Wine, but it really behaves the same on Windows) There is no mention of 'osc' whatsoever. On the other hand, [declare -stdlib zexy] works the same on Linux and on Windows. [declare -stdpath] used to work on Windows in older version of Pd, but I can't tell exactly since when it isn't working anymore. Roman

3 6

Present and future of WebPd
by s p 09 Sep '15

09 Sep '15

Hello Pd list! After receiving many questions, I decided to write a little post to explain about the present and future of WebPd : http://funktion.fm/#post/present-and-future-of-webpd <http://l.facebook.com/l.php?u=http%3A%2F%2Ffunktion.fm%2F%23post%2Fpresent-…> Feel free to comment! -- *Sébastien Piquemal* -----* @sebpiq* ----- http://github.com/sebpiq ----- http://funktion.fm

6 14

fexpr~ block limitations - bug
by Alexandre Torres Porres 09 Sep '15

09 Sep '15

Hi Shahrokh and Pd list I've been testing fexpr~ and it seems it won't get the previous samples from the previous block. For example, a simple mean filter like this: [fexpr~ ($x + $x[-1]) * 0.5] will not work for the first sample of the block, because it won't get the last sample from the previous block. So, I know that in practice it doesn't compromise much, it's just one sample, but in an 16 point average filter this becomes more of a concern. One way or another, even for just one sample, I consider this problematic and a bug, as it should always be able to address previous samples. Am I right? thanks

2 3

8 point average filter with biquad and raw filters?
by Alexandre Torres Porres 08 Sep '15

08 Sep '15

Hi, I was able to implement a 4 point average filter with raw filters and biquad~ in Pd (find attached patch). I'm struggling to finda a way to implement an 8 point average filter with biquads~ and raw filters... Anyone can help? thanks

2 3

Re: [PD] gem advanced video keying
by Marco Donnarumma 08 Sep '15

08 Sep '15

Hi there, perhaps this Pd project below may be of some help. I remember the presentation in Weimar and it was very well done. https://puredata.info/downloads/extended-view-toolkit It's not about keying, but, if I recall correctly, has a very nice setup for blurring edges and combining multiple video streams for panoramic projections using shaders. Not sure whether it's still maintained or compatible with newer Pd version. sorry if someone pointed it out already, I haven't followed the whole conversation. best, M 3. Re: gem advanced video keying (Py Fave) > > > Date: Tue, 8 Sep 2015 16:44:46 +0200 > From: Py Fave <pyfave(a)gmail.com> > To: hi <joson.android(a)googlemail.com> > Cc: "pd-list(a)lists.iem.at" <pd-list(a)lists.iem.at> > Subject: Re: [PD] gem advanced video keying > Message-ID: > <CAAQHdpBr7j0RNwzDU+fMgy= > q37ioY+haZw-CMYB42g4XCN-cZQ(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > check this > > http://www.casparcg.com/ > > 2015-09-07 19:28 GMT+02:00 hi <joson.android(a)googlemail.com>: > > thanks for the answer! > > > > i will need to start to use shaders one day, i know that long already > **dream** For now the project goes back to the drawer > > > > I would love to see a new pd convention to find motivation for week > intense pd work.. > > > > > > Am 26.08.2015 um 09:46 schrieb Py Fave <pyfave(a)gmail.com>: > > > >> you need to use glsl shaders to do that efficiently . > >> > >> first check for existing shaders > >> > >> you will need a powerful gpu > >> > >> > >> > >> ------------ > >> this is a lumakey example (was sent to me by chdh) > >> -------------- > >> keying.frag > >> > >> ------------- > >> uniform float R,G,B,K; > >> uniform sampler2D texture; > >> > >> void main (void) > >> { > >> float d = 0.; > >> vec4 color = texture2D(texture, gl_TexCoord[0].st ); > >> > >> d+= abs(color.r - R); > >> d+= abs(color.g - G); > >> d+= abs(color.b - B); > >> > >> d*=K; > >> > >> color.a = abs(d); > >> > >> gl_FragColor = color; > >> > >> } > >> > >> ------------------------------ > >> > >> > >> 2015-08-12 15:13 GMT+02:00 hi via Pd-list <pd-list(a)lists.iem.at>: > >>> Dear Pd folk, > >>> > >>> I am investigating options to improve chroma keying within pd and gem > to use within a theater installation. I need more advanced keying features > than seemingly possible with [pix_choma_key], like border corrections and > smoother edge transparencies. The best thing i found so far is this: > >>> > >>> http://forum.pdpatchrepo.info/topic/2953/neat-chroma-keying/3 > >>> > >>> very nice, but i would need more a quality like in readymade video > mixers > >>> Did any of you program anything like that? > >>> > >>> Also i'm trying to find out, whether a potential setup with a computer > with 4 HD-SDI inputs would be capable of keying 2 HD-live-signals at the > same time and overlay that over one HD-live-background. > >>> > >>> Are there any experiences (hardware and software) from your side, you > could share? > >>> > >>> I would so much love to make this happen with pd and not with an > expensive video mixer i would have to buy. > >>> > >>> Any help or ideas are appreciated. > >>> > >>> Love to pd, > >>> > >>> jonny > >>> _______________________________________________ > >>> Pd-list(a)lists.iem.at mailing list > >>> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > **************************************** >

2 1

cyclone/average~ should output signal, not data
by Alexandre Torres Porres 08 Sep '15

08 Sep '15

hi there, found a problem with average~, it's sending numbers instead of audio signal like in Max/MSP You could implement moving average filters with average~, by the way, it seems there are no objects for that in Pd - but the output needs to be It'd be really nice. cheers

1 0

Re: [PD] Pd-list Digest, Vol 126, Issue 26
by ryan legge 08 Sep '15

08 Sep '15

Help unsubscribe Sent from Outlook On Tue, Sep 8, 2015 at 7:21 AM -0700, <pd-list-request(a)lists.iem.at> wrote: Send Pd-list mailing list submissions to pd-list(a)lists.iem.at To subscribe or unsubscribe via the World Wide Web, visit http://lists.puredata.info/listinfo/pd-list or, via email, send a message with subject or body 'help' to pd-list-request(a)lists.iem.at You can reach the person managing the list at pd-list-owner(a)lists.iem.at When replying, please edit your Subject line so it is more specific than "Re: Contents of Pd-list digest..." Today's Topics: 1. Re: Present and future of WebPd (Julian Brooks) 2. Re: "G05.execution.order" issue (bug? just wrong?) (Alexandre Torres Porres) 3. Re: "G05.execution.order" issue (bug? just wrong?) (Joe White) ---------------------------------------------------------------------- Message: 1 Date: Tue, 8 Sep 2015 14:23:53 +0100 From: Julian Brooks <jbeezez(a)gmail.com> To: s p <sebpiq(a)gmail.com> Cc: Chris McCormick <chris(a)mccormick.cx>, "pd-list(a)lists.iem.at" <pd-list(a)lists.iem.at> Subject: Re: [PD] Present and future of WebPd Message-ID: <CAGemBFQQT+swRwvqxWUtuT1fHZ2Nqsqs_SAwe-i72Xxw41hdOw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hey Seb. Good informative post, thanks for that. It does seem you're taking the right approach to this dilemma. Think too you're being a bit hard on yourself - I wouldn't describe the list of objects implemented with native audio nodes as 'not much' at all! Quite the opposite. Conceptually, for me, it makes sense to have some separation between those native nodes that do, in effect, behave exactly like Pd vanilla objects and have a low overhead. Presumably these should be straightforward to separately maintain as a WebPd vanilla. BTW - I'm actually happy to reconceptualise/refactor some of my own patches to run on WebPd - it's ok for things to turn into something else:). And then there's those future ScriptProcessorNode possibilities that I could conceptualise as similar to PdE - something to go to when I can't find a WebPdVanilla solution. This and Jonathan's GUI rewrite are currently really interesting - this is awesome stuff you guys are up to. Regards, Julian On 8 September 2015 at 09:46, s p <sebpiq(a)gmail.com> wrote: > dammit ... JavaScript bug on my website maybe? > This pure - and ugly - html version should work : > http://funktion.fm/post/present-and-future-of-webpd > > On Tue, Sep 8, 2015 at 10:42 AM, Julian Brooks <jbeezez(a)gmail.com> wrote: > >> THis all sounds very interesting, unfortunately this: >> http://funktion.fm/#post/present-and-future-of-webpd >> is still devoid of text on my machine (what the deuce!:) >> >> On 8 September 2015 at 07:47, s p <sebpiq(a)gmail.com> wrote: >> >>> > When I handed WebPd over to you, one feature that was important to me >>> was to have WebPd work as a system where you could take an existing Pd >>> patch and be pretty sure it would sound and work the same >>> >>> And I agreed with this goal of yours! Only if you remember, these were >>> different times. Web Audio API had not fully landed, WebPd was firefox only >>> and working on Audio Data API, which provided a simple callback to write >>> audio to the sound card buffers and nothing else, so custom dsp was the >>> only way to go. With the deprecation of Audio data API in favor of web >>> audio API, and native nodes becoming the default thing (custom dsp being >>> only a second class citizen), I couldn't just ignore the option of >>> rebuilding it on native nodes. >>> >>> My hope was that : >>> 1) native nodes would be enough to implement a significant part of Pd's >>> functionalities, with ScriptProcessorNode complementing what couldn't be >>> implemented with a big !!!use these objects carefully : performance penalty >>> warning sign >>> 2) the difference in implementation in native nodes compared to pd >>> objects wouldn't be that significant. >>> >>> I think I was mostly wrong on both points ... However, the biggie, which >>> decided me on this, is that you couldn't really use WebPd on mobile devices >>> with custom dsp. ScriptProcessorNode would immediately choke, and make the >>> whole thing pretty much unusable. So this was basically a choice between on >>> one hand purity and sticking to desktop Pd, on the other hand usability and >>> cross-browser / cross-device -ness. And so I chose pragmatism over purity >>> (and that was a heartbreaking choice : after my first failed attempt at >>> reimplementing WebPd with native nodes I was totally gutted : >>> https://github.com/WebAudio/web-audio-api/issues/263 ). >>> >>> I think for now that was somehow the right choice, since I came up with >>> a version of WebPd which ... even if it parts from Pd on some points, is >>> much more useful than a faithful version which couldn't run on most >>> devices. I myself used WebPd to do things I coudn't have done before (live >>> performances on mobile phones). And I think that makes the library more >>> sustainable, since it becomes not just a fancy toy, but a serious >>> alternative to using plain Web Audio. >>> >>> I woudn't reconsider that decision if it wasn't for the fact that times >>> they are a changing again, with the arrival of AudioWorker to replace >>> ScriptProcessorNode... which MIGHT make custom dsp a viable option once >>> again. So this is really all this is about. Bloody specifications changing >>> every 6 months, and me trying to keep up ;) >>> >>> > I only hope to persuade you that faithfulness to Pd's output is >>> probably a feature that users will appreciate a lot. >>> >>> to conclude ... you don't need to persuade me of this :) I just think it >>> is more important to have something you can use at all. But the future >>> might be brighter, and maybe these two goals won't contradict each other >>> any more. >>> >>> >>> On Tue, Sep 8, 2015 at 5:00 AM, Chris McCormick <chris(a)mccormick.cx> >>> wrote: >>> >>>> On 08/09/15 10:49, Chris McCormick wrote: >>>> >>>>> I am glad to see it live on with >>>>> somebody who codes as energetically as you >>>>> >>>> >>>> chr15m: 98 commits / 8,028 ++ / 1,712 -- >>>> sebpiq: 253 commits / 322,207 ++ / 250,725 -- >>>> >>>> Lol! >>>> >>>> Chris. >>>> >>>> -- >>>> http://mccormick.cx/ >>>> >>> >>> >>> >>> -- >>> >>> *Sébastien Piquemal* >>> >>> -----* @sebpiq* >>> ----- http://github.com/sebpiq >>> ----- http://funktion.fm >>> >>> _______________________________________________ >>> Pd-list(a)lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> >> > > > -- > > *Sébastien Piquemal* > > -----* @sebpiq* > ----- http://github.com/sebpiq > ----- http://funktion.fm >

1 0

weird behavior of [vd~] in phave vocoder (overlapping subpatches)
by Alexandre Torres Porres 07 Sep '15

07 Sep '15

Dear list, long ago I made a live sampler where you can start recording into an array and right away start phase vocoding on the fly - based on the "I07" example, so I was using a regular buffer/array. So I wanted to make it run with a circular buffer, and once in january 2012, someone here on the list told me to try using [vd~]. Well, I never really could do it, and it's only these days that I was able to sit down and finally nail it. I made it happen, but I can't really understand it and I hope you can help me. I have patches attached so it'll help point out what I say. In the same file I have a regular granular pitch shift + time stretch and the same patch adapted to use the phase vocoder "phase accumulation" procedure. I know there are issues that come up with the way overlapping works in Pd. For example, if you are doing a pitch shifting with a granular engine using [vline~] to read the grains, you'll have to increase the reading speed of [vline~] times the overlapping. So, in an overlap of "4", time will have to be 4 times faster (so divide time in ms by 4). Other issues related to overlapping besides this "oversampling" is that some objects won't make it right, they'll chop the blocks with discontinuities, such as the case with [osc~]. But as it turns out, unlike [osc~], [vd~] will get the continuities between blocks right! So I'm reading grains out of a delay line with [vd~] using [vline~]. For a regular buffer/array I know I have to get the time of [vlaine~] faster, but with vd~] 'm having to divide EVERYTHING by the overlap number, that includes the starting point, the end point, and the difference in ms between the front and back FFT window... It might have something to do with the way I described [vd~] works in an overlapping subpatch, but I just can't get it - it makes no sense to me. And even more weirdly, in the Pvoc patch I have to multiply the difference between the front and back windows to the ratio of transposition. This is even crazier than the last issue, and I have no idea why that has to be this way... So I have these two adaptations I had to make, divide by overlap and multiply by the ratio, they're marked with "*" in the phase vocoder subpatch, hopefully it'll be quite clear. Besides this, both patches I have attached are about the exact same. cheers

1 0

Re: [PD] changing font size overall
by rolfm＠dds.nl 07 Sep '15

07 Sep '15

cyrille wrote > this is the same size as what i'm using on my 13 inchs 1920x1080 screen. > i'm not using the same font, but you can change that to (using the > -font-face option) > for my eyes it is very uncomfortable, so i would like to be able to change it. rolf

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list September 2015