Pd-list April 2016

pd-list@lists.iem.at

75 participants
106 discussions

Camomile build problem
by Dave Phillips 02 Apr '16

02 Apr '16

Greetings, I'm building Camomile on Fedora 21 x86_64. Everything goes along well until here : make: *** No rule to make target '../../ThirdParty/PureData/src/x_vexp_fun.c', needed by 'build/intermediate/Debug/x_vexp_fun_e64128cb.o'. Stop. Indeed, in 0.46-6 and 0.46-7 I can find no x_vexp* and I'm stalled. Any suggestions ? Pure Data plain vanilla from Miller's page. Best, dp

2 1

Fwd: [PD-announce] Camomile: An audio plugin that loads Pure Data patches
by Olivier Bélanger 02 Apr '16

02 Apr '16

Hi, Win64-release works very well (multiple instances) with Reaper under Wine (Xubuntu 15.10 64-bit). Olivier On Sat, Apr 2, 2016 at 2:52 PM, Pagano, Patrick <pat(a)digitalworlds.ufl.edu> wrote: > I can confirm Camomile works like a dream on OSX in ableton live with > multiple instances. > > Just one question about externals. Can they be us d successfully? I am going > to make a granulator > > Patrick Pagano B.S, M.F.A > Interactive Media & Education > +1352.226.2016 > https://patrickrpagano.wordpress.com/ > > > On Apr 2, 2016, at 1:40 PM, phil jones <interstar(a)gmail.com> wrote: > > Thanks Pierre Guillot > > This looks really useful. Is there a windows binary download available? I > don't have Visual Studio to do the compilation. But I'd love to try this > with FL Studio and can give feedback. > > cheers > > Phil > > On 2 April 2016 at 13:46, Pierre Guillot <guillotpierre6(a)gmail.com> wrote: >> >> Hi all, >> I'm pleased to announce the release of Camomile, a plugin that allows to >> load Pure Data patches inside a DAW. >> >> Feature: >> Support for multiple plugin instances. >> Automatic creation of GUIs (toggle, slider, radio, comment, numbox) >> Automatic creation of parameters (name, label, range, minimum, maximum, >> etc.) >> Up to 16 audio channels >> Up to 64 parameters >> Support for MIDI input and output >> Support for play head information >> Support for BPM information >> Available for Linux, Mac and Windows. >> >> I'll be happy to receive your feedback. >> Download and further information on the wiki: >> https://github.com/pierreguillot/Camomile/wiki >> >> Have a good week-end! >> >> _______________________________________________ >> Pd-announce mailing list >> Pd-announce(a)lists.iem.at >> http://lists.puredata.info/listinfo/pd-announce >> >> _______________________________________________ >> Pd-list(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

1 0

holding keys on patchload to affect object behaviour
by Alexandre Torres Porres 01 Apr '16

01 Apr '16

hello, is the a way for Pd to know what keys are being held down when a patch is loading so it changes the behaviour of an object? for example, to prevent loadbangs to send a bang at load time? it would have to be something like: hold down Shift-Command (Mac) or Shift-Ctrl (PC) to disable loadmess firing at patcher load yes, this is for implementing a clone of [loadmess] object from max, and this is the only discrepancy left... cheers

4 9

EHU-abstractions new version
by enrike 01 Apr '16

01 Apr '16

hi all This year I have been involved again in some PD teaching so I updated a library of abstractions I use for students. I thought it might be interesting for someone out there. Find it here in the PD section http://www.ixi-audio.net/content/backyard.html and the github page is http://github.com/enrike/ehu-abstractions This is the description: EHU is a set of abstractions for PureData real-time graphical programming environment. EHU aims to allow for rapid prototyping of interactive systems. Most abstractions in EHU encapsulate the GUI widgets to control them minimising the job of creation of widgets and connections. EHU covers playing video files, controlling video cameras, displaying pictures, playing samples, audio effects, DMX controls, and some general utilities. It is based on pd-extended :/ and relies on few abstractions there. enrike

1 0

Multiprocessing in Pd (was DSP and Gem in the same instance of Pd)
by Matt Barber 01 Apr '16

01 Apr '16

Pd's constraints make the automatic allocation unlikely. Read this: http://puredata.info/community/conventions/convention09/puckette.pdf 'Since at least 1990, users and critics of Max/FTS have observed that it would be desirable for objects to be automatically allocated to processors in a way that would minimize the bandwidth of interconnections between the objects. This would free the user from the cumbersome task of understanding the actual flow of data between objects in the patch; the software would automatically assess that. This didn’t prove practical, for two reasons. First, as has long been well known, one can’t compute the quantity of data that will flow between any given pair of objects in a patch (at least, not if the patching language is able to solve arbitrary computing problems). Predicting how much data will flow where is hopeless. The second problem is that nobody has been able to make an expressive patching language that doesn’t depend on objects sharing data. In Max/FTS (and in Pd as well) this takes the form of “named” objects such as arrays. Any automatic distribution of patches that allows accessing arrays would have to place every object that accesses any particular array on the same processor, or else use some kind of locking mechanism that would be unlikely to work in real time. Also, any situation in which there is of recombination of message fanout would require that both message paths be synchronized, i.e., that both message paths go through the same itinerary of processors or be otherwise delay-equalized. In combination, these constraints would require that, for complete transparency, almost any interesting patch would have to reside on a single processor. It appears to be an inescapable fact that multiprocessing has non-hideable effects on the execution of “patches” and can’t effectively be carried out without the user’s active participation.' It might be easier if Pd used a system of buses for routing rather than arbitrarily drawn patch connections, or if a graphical patching environment had a good way of implementing something like SuperCollider's Synth, which works with a flexible node order but has relatively limited means of input and output. Here's what I see as the bare minimum of what we'd need to address to make your wish a reality: 1) Unit generators instantiated in Pd have to exist somewhere in a running patch to output. This is in distinction to SC3 and csound, where instances of Synths or instrument templates are instantiated and destroyed. In the latter two, the order of creation and destruction of instruments (and in csound, the order they're defined in the orchestra) matters a lot in the DSP graph, which makes it more predictable. SC3 also has user methods for ordering nodes. 2) Connections in Pd are flexible and arbitrarily complex, which makes the DSP graph a lot more ramified than a mixer model with buses, inserts, aux sends, etc., and therefore much less predictable in the abstract. 3) Pd is deterministic, which means that (as noted in the quote above), any memory sharing across threads would need to involve locks, which can be killer in real-time, not to mention difficult to scale and guarantee thread safety. [pd~] communicates via FIFO because it needs to be able to keep messages and audio in sync by block. I'm sure there's more. On Thu, Mar 31, 2016 at 11:07 PM, William Huston <williamahuston(a)gmail.com> wrote: > Slightly OT-- but related: > I'm going to throw out a wish-list item > which is probably impossible or very hard to implement, > > Find a way for the DSP Graph compiler to naturally > break up the task into small chunks, which all use shared > memory in a thread-safe way, so that the PD job automagically > spreads itself out over available cores without any special > work by the programmer. > > Now that I've got my big, fast, lots of ram, 6-core AMD > box running again, I notice that I can run MUCH larger > graphs there than on my Raspberry Pi. > > But I think it's just a raw CPU speed, or Cache Speed, or > speed to RAM which matters, and not the number of cores. > > I notice that on my Pi there seems to be two processes, one for > the GUI and one for the DSP. 2 cores are wasted unless I use > the [pd~] object, and I have to basically guess how to split up the job. > > I know, I'm dreaming here.... > > > > > > > On Thu, Mar 31, 2016 at 10:57 PM, Lucas Cordiviola <lucarda27(a)hotmail.com> > wrote: > >> And more, >> >> A single thread calculation divided between 2 cores in its 1 core time is >> more stable. >> >> 1 0 >> 0 1 >> 1 0 >> 0 1 >> >> transistors have more idle time. >> >> Mensaje telepatico asistido por maquinas. >> >> ------------------------------ >> From: brbrofsvl(a)gmail.com >> Date: Thu, 31 Mar 2016 22:45:57 -0400 >> Subject: Re: [PD] DSP and Gem in the same instance of Pd >> To: jancsika(a)yahoo.com >> CC: lucarda27(a)hotmail.com; pd-list(a)lists.iem.at >> >> >> Right, so the point of [pd~] is that the OS can now throw whatever is >> going on in the subprocess onto another core. The idea from what I've heard >> for Gem is that you can leave the DSP off in the [pd~] instance, run Gem >> from there (on another core, possibly). Then if together they would have >> maxed out one core they could split the work among two and proceed in time. >> >> But if the problem is that Gem has to wait for something to happen >> elsewhere before it can proceed, it won't help. Kind of in the same way >> that running an infinite [until] loop on the subprocess will halt the main >> process, too. >> >> On Thu, Mar 31, 2016 at 9:24 PM, Jonathan Wilkes via Pd-list < >> pd-list(a)lists.iem.at> wrote: >> >> But [cpu_hungry_hippo~] needs input from [pd~] in order to >> compute its output. So [pd~] must send output before [cpu_hungry_hippo~] >> can execute its perform routine. >> >> >> On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola < >> lucarda27(a)hotmail.com> wrote: >> >> >> Isn`t >> >> [pd~] <-- some dsp stuff going on in here >> >> To take advantage of multi-core CPUs? >> >> Mensaje telepatico asistido por maquinas. >> >> ------------------------------ >> Date: Fri, 1 Apr 2016 00:37:26 +0000 >> To: brbrofsvl(a)gmail.com; reduzent(a)gmail.com >> CC: pd-list(a)lists.iem.at >> Subject: Re: [PD] DSP and Gem in the same instance of Pd >> From: pd-list(a)lists.iem.at >> >> I'm not sure I understand [pd~]. Consider: >> >> [foo~] >> | >> [pd~] <-- some dsp stuff going on in here >> | >> [cpu_hungy_hippo~] >> >> How does [pd~] help me in this case, as opposed to just putting the >> "dsp stuff" directly in the patch? >> >> And in general, how is the super-process able to anything >> other than block when waiting for output from [pd~]? >> >> -Jonathan >> >> >> >> On Thursday, March 31, 2016 5:17 PM, Matt Barber <brbrofsvl(a)gmail.com> >> wrote: >> >> >> One other thing that's helped in an emergency is increasing Pd's audio >> buffer in the preferences. >> >> One thing I've heard of but never tried is running Gem from a slave >> instance in [pd~]. I don't know enough about it to know whether this could >> work or why; it might just be a rain dance. >> >> On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli <reduzent(a)gmail.com> >> wrote: >> >> On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote: >> > >> > Le 31/03/2016 11:19, Roman Haefeli a écrit : >> > > >> > > BTW: Why does the graphics rendering|clock have precedence over the >> > > audio rendering (at least, it seems to be like that in Pure >> Data/Gem)? I >> > > guess most softwares do it the other way around, since clicks are much >> > > more noticeable than a frame being a few milliseconds late. >> > >> > Gem have no precedence over audio : they both have the same priority. >> > when having priorities on audio, the openGL rendering did not have >> > fixed frame rate, and it's not possible any-more to have smooth hight >> > speed movement. >> > >> > So, i like the way it is, even if it cause implementation problem. >> >> Oh, now since I understand, I like the way it is, too ;-) >> >> > one possible explanation of your problem is that you are rendering a >> > 60 fps, and that openGL is sync on the 60fps screen. >> > You can have jitter between the 2 different 60fps clock. If Gem is >> > waiting for the screen, then everything (including audio) is on pause. >> >> That is exactly what I was doing. >> >> > if this is the cause of your problem, then reduce Gem fps to 59, or >> > remove openGL syncro (sync to vblank). >> >> This is exactly what helped (reducing fps to 59). Thanks for your sharp >> thinking. >> >> Roman >> >> >> _______________________________________________ >> Pd-list(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> _______________________________________________ >> Pd-list(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> _______________________________________________ Pd-list(a)lists.iem.at >> mailing list UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> _______________________________________________ >> Pd-list(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> _______________________________________________ >> Pd-list(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> > > > -- > -- > May you, and all beings > be happy and free from suffering :) > -- ancient Buddhist Prayer (Metta) >

3 3

DSP and Gem in the same instance of Pd
by Roman Haefeli 01 Apr '16

01 Apr '16

Hey all It's a well know issue and the solution has been discussed many times: When you're using audio and Gem rendering, it's wise to separate those two into their own instance of Pd. I'm working on a project that does both, audio processing and Gem rendering. The OpenGL rendering is very light-weight and does only require minimal resources. Also the audio part uses a fraction of the available CPU power. What I observe is that I get a zipping noise for ~15 seconds, then clean audio for another 15 seconds before the zipping noise returns. The zipping noise occurs only when Gem rendering is turned on. To me it looks like the problem is not related to limited resources, rather it seems that both, OpenGL and audio rendering, are tied to their respective clock and those clocks are not coupled and thus are not completely in sync. I know I could put both parts into their own instances of Pd and that's what I'll do if there is no resolution, but for convenience reasons I'd prefer to have only one patch in one instance of Pd. Now, is there a way to loosen the coupling to OpenGL clock (is it the same as the monitor clock?) so that audio is not affected? I don't care about any side-effects like tearing (it won't be visible anyway for the kind of image). Roman

7 16

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 April 2016