Pd-list April 2010

pd-list@lists.iem.at

143 participants
284 discussions

Re: [PD] Zen Garden re-implementing the wheel in C++?
by Matt Barber 17 Apr '10

17 Apr '10

> unfortunately, this is not a trivial issue. > > dynamically changing the signal graph is possible (actually, i had an > implementation of that in nova). do the topological sorting in the > background and you are fine. > > the tricky part are implicit dependencies. see this trivial patch: > |adc~| > | > |send~ foo| > > |receive~ foo| > | > |dac~| > > it execution order is ambiguous. either (a) adc-send-receive-dac or > (b) receive-dac-adc-send. the actual execution order depends on the > implementation. the case (b) introduces one sample block of latency between > send and receive, (a) doesn't introduce any latency. > without the loss of generality, lets assume that the actual order of the dsp > graph is (b). now you add a connection between adc~ and dac~. the > topological sorting of the dsp graph may come to the execution order (a). > adding the connection, you change the layout of the signal graph, changing > the order of send~ and receive~ and therefore its semantics. you actually > loose one sample block and therefore have an audio dropout. > > if there are any possibilities to circumvent this issue, i haven't found > any. for special cases, it works, but whenever implicit dependencies have to > be taken into account, things are getting very messy. if you want to have > dynamically changing signal graphs, don't use max-like languages. it is not > a problem of the implementation, it is a problem of the programming model in > general! if you need dynamically changing signal graphs, you should use a > system, that is designed for this use case. The standard way of dealing with this problem is probably the same as the way one deals with the analogous problem with delread~/delwrite~. I attached a patch -- if you embed each of the object instances in question within a subpatch and connect the subpatches in the order you want, you'll force the execution order. This little patch is pretty stupid because it looks like it ignores the reasons for needing to use send~/receive~ in the first place (that is, because you're using send~/receive~ AND a connection in the same place). However, I've found it's not that bad if I'm using it in a really large patch, as long as I keep things hierarchical and modular - the hierarchy can help with forcing execution order cleanly, and making things modular makes it easier to do more of it at once. Doing it dynamically is a whole other issue, though (and the point of this thread) -- if I really need a dynamic graph I'll usually use supercollider instead, although sometimes you can fake it in Pd by hard-coding and instantiating everything you need ahead of time if it's simple enough, and then just switch~ing the correct possibility on and the others off when appropriate; a waste of resources. Matt

1 0

(no subject)
by Andrew Faraday 17 Apr '10

17 Apr '10

Hey All I've recently been looking at possibilities for networked performance with pd. So far I've found that [netsend] and [netrecieve] only seem to take numeric data (I.E. no symbols or bangs). This might be the result of the abstraction I'm using (made by one of my workshoppers) which sends messages with through a message box [send chan1 $1(, [send chan2 $1( etc. I've solved the bangs problem by sending a number repeatedly and having a [sel] at the receiving end. However I am interested in using netsend as a basic messaging system (to conduct a laptop group by typing from a central machine). _________________________________________________________________ http://clk.atdmt.com/UKM/go/195013117/direct/01/

8 12

Re: [PD] puredata_gui_design
by errordeveloper＠gmail.com 17 Apr '10

17 Apr '10

Hello Jordi, sure, i will have a look at it later, see what i need to do to package it :) i am supposed to quite a few things this weekend, so please remind me next week if i still didn't post it. cheers, -- Ilya D. On Sat, Apr 17, 2010 at 02:17:51PM +0200, Jordi Sala wrote: > Hi, I'm very interested to try you gui!! it seems very interesting and useful!! > > On 17 April 2010 12:29, <errordeveloper(a)gmail.com> wrote: > > > > I have made a little plugin widget for QTdesigner (well, you really > > wanna use QTcreator IDE) that connects to pd via a TCP socket and you > > can specify the hostname .. > > you can add sliders and buttons and whatever and it all works quite > > fine. > > there's very little to the code, in fact it's damn minimal, so i reckon > > the v0.1 is pretty much bugfree.. > > i haven't yet sorted any hosting ..neither i wrote a README, > > but if anyone is interested i'm post it here. > > > > i have attached a screenshot of one layout that i made with it .. > > > > there a few limitations ..ATM i hope i will manage to overcome those by > > incorporating OpenGL widgets ..)) > > also one main thing now to is configure QT-embedded to work with > > DirectFB, then i'd make some more widgets .. > > well ..SVG could be nice, but i haven't yet figure how to do it in QT in > > nice a streight forward way. > > but there some really nice svg widget example on the Nokia's website :) > > > > anyone interested to try my 'qpd' please drop a line, > > i'll need to install qt4 with qtcreator ..i'm not sure about all the > > dependencies qt4-devel and stuff like that is probably required, > > nothing else major appart form that. > > > > On Fri, Apr 16, 2010 at 03:19:50PM +0200, colet.patrice(a)free.fr wrote: > >> > >> segmented and curvy cords comes with another patching design, > >> Â like in maxMSP where almost all the time the messages order doesn't have an importance. > >> > >> Â Also it's said by some users that max patches works better when everything is in the same subpatch, > >> and that is not the case with pd. > >> > >> Â Many other has explained, certainly better than me, why not using those cords in list archive. > >> > >> Â Also, the project of designing other interfaces for pd is really seducting, > >> Â and there is already some projects that allow the use of another GUI, like > >> > >> the J. Sarlo's Graphical Interface Editing Tool and Run-time Environment (cpu glouton) > >> or > >> T. Grill's python wrapper and tkinter. (require python knowledge) > >> or > >> HC's [sys_gui] Â (require tcl knowledge, and very slow response) > >> or > >> [mixed/toxy/tot] (unstable, require tcl knowledge) > >> and > >> xi widgets that require tcl/tk 8.5, a working [widget] external, and half a dozen of tk libs. > >> > >> Â There are also other projects using pd sources with another GUI design like desiredata > >> > >> > >> ----- Mail Original ----- > >> De: "Lorenzo" <lsutton(a)libero.it> > >> Ã: pd-list(a)iem.at > >> EnvoyÃ©: Vendredi 16 Avril 2010 12h07:08 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne > >> Objet: Re: [PD] puredata_gui_design > >> > >> > >> AndrÃ¡s MurÃ¡nyi wrote: > >> > >> > >> > >> > >> One (hard) aspect of GUI design in case of Pd is that the GUI widgets are provided by Tcl/Tk at the moment, which does not allow for such kind of skinning, afaik. There has been talk, however, about migrating to another GUI toolkit. > >> Really? Which one? > >> > >> As a comment on the designs which graphically look very cool... this will probably be unpopular... but I *wouldn't* second segmented or curvy chords (like in some other popular dataflow programs) as I think they tend to make patches (and one's coding) less clear and in the end a bit "messy".. but it may be me, as I do tend to become messy and like something which constraints me not to :) > >> > >> Lorenzo > >> > >> > >> _______________________________________________ > >> Pd-list(a)iem.at mailing list > >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > >> > >> _______________________________________________ > >> Pd-list(a)iem.at mailing list > >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > > Pd-list(a)iem.at mailing list > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > > > > > > -- > Jordi Sala > http://musa.poperbu.net

1 0

Re: [PD] PD] Zen Garden re-implementing the wheel in C++?
by Matteo Sisti Sette 17 Apr '10

17 Apr '10

> depending on their implementation, it may be possible to do > click-free changes of the dsp graph, which is the weakest part > of the dsp engine of pd. This recalls me of a possibly unrelated even "bigger" problem: you get audio dropouts even by opening a window (such as a subpatch or abstraction by right click -> open). Why? Is the dsp graph redrawn when opening a window? Is there a reason for doing that? Or is something else the cause for such dropouts (maybe some memory allocation)? But then, shouldn't _anything_ happening when opening a window affect _only_ the gui process? -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

1 0

Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd?
by colet.patrice＠free.fr 17 Apr '10

17 Apr '10

Roman, //---------- //----- Mail Original ----- //De: "Roman Haefeli" <reduzierer(a)yahoo.de> //À: "colet patrice" <colet.patrice(a)free.fr> //Cc: "Mathieu Bouchard" <matju(a)artengine.ca>, "pd-list" <pd-list(a)iem.at> //Envoyé: Samedi 17 Avril 2010 00h14:24 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne //Objet: Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd? //A djembé drummer says: "You cannot make dance music alone, you need //other drummers as well". Patko says: "Making dance music requires //advanced technologies". Roman says: "Where is the sine? I cannot dance //without an [osc~ =<20]". //---------- I'd say we won't dance without also trigging [osc~ 71] //---------- > Not to say that an instrument would sound better if there is a background image or such, > but the way we are accessing data and modulate them has a severe influence on inspiration. > > At the end the best compromise I've found is like obiwannabe's work, where the patch is the piece. //I guess I'm missing your point here. How does that relate to what you //said above? //---------------------- I say that because I and others tried to build some kinds of tools to group all the tools made with pd, the only one I know that work is netpd, and wasn't satisfied of the result of a ton of work, because there is always something missing, but with grouping everything in a patch, it's possible to combine all the necessary stuff needed by inspirations coming from different cultural influences.

1 0

second instrument/piece in the silent percussion project...
by Jaime Oliver 17 Apr '10

17 Apr '10

hello everyone, In the link below there is a video documentation of a brand new performance with the new MANO Controller called Silent Construction 2 in a new webpage... lots of new things... For those who were in Sao Paulo for the PdCon you may have heard Silent Construction 1 (for Silent Drum). As in that case everything is done in Pd/GEM and a few new externals... hope you like it...: http://www.jaimeoliver.pe/workobra/silent-construction-series/sc2 best, J -- Jaime E Oliver LR www.jaimeoliver.pe 858 750 0924 (cel) 858 202 1522 (home) 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA

5 14

Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd?
by colet.patrice＠free.fr 17 Apr '10

17 Apr '10

uh I missed roman inputs, fortunately there are the archives " Are you implying there was no dance music since the 80's? How bad will actual 'best technologies' will be in a few years? Is that a discussion about certain aesthethics you're looking for or about technical possibilities? " I took dance as an example of musics that needs to answer a number of sound characteristics where technical possibilities are seriously implied in aestethics. Not to say that an instrument would sound better if there is a background image or such, but the way we are accessing data and modulate them has a severe influence on inspiration. At the end the best compromise I've found is like obiwannabe's work, where the patch is the piece. ----- Mail Original ----- De: "Mathieu Bouchard" <matju(a)artengine.ca> À: "Roman Haefeli" <reduzierer(a)yahoo.de> Cc: "colet patrice" <colet.patrice(a)free.fr>, "pd-list" <pd-list(a)iem.at> Envoyé: Vendredi 16 Avril 2010 18h53:40 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd? On Fri, 16 Apr 2010, Roman Haefeli wrote: > On Fri, 2010-04-16 at 14:04 +0200, colet.patrice(a)free.fr wrote: >> show me a patch that correctly mix soundfiles. > That interests me. Can you elaborate a bit more what you mean by > "mixing"? Interesting, I was more concerned by the use of the word « correctly ». For a even a simple cross-fade, any way of smoothing the output of a slider is a potential matter of personal preference, and whichever way you pick has eventual slightly different consequences on the result. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

4 4

Re: [PD] Zen Garden re-implementing the wheel in C++?
by Spencer Russell 17 Apr '10

17 Apr '10

I apoligize for the perhaps poor choice of words. I wasn't bashing tcl in general, but only meant that there seems to be a fairly large sentiment that it doesn't belong in the interface between client and server processes. -s On Apr 16, 2010 9:02 PM, errordeveloper(a)gmail.com <errordeveloper(a)gmail.com> wrote: i think by calling Tcl a garbage you are certainly provoking a flame war. On Fri, Apr 16, 2010 at 02:46:44PM -0400, Spencer Russell wrote: > Hey List. > > Just came across Zen Garden: > > http://wiki.github.com/mhroth/ZenGarden/ > > Seems like the RJDJ crew is re-implementing PD in C++, in it's full > object-oriented glory. > > I'm excited about the idea of a more object-oriented approach, and > especially with the idea of ditching all the Tk/Tcl garbage, but I > don't really see the utility of re-implementing all the DSP graph > code. > > I haven't looked at the ZenGarden code at all yet though, so maybe > they're doing a lot of borrowing where it makes sense? > > Maybe we can talk about this interesting development without a flame > war? Unlikely. > > -s > > _______________________________________________ > Pd-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

1 0

Re: [PD] second instrument/piece in the silent percussion project...
by luigi rensinghoff 17 Apr '10

17 Apr '10

Hey Jaime i can only talk for me ;-) I like it a lot....the MANO controller. And its just one object ??? Very cool work... please organize concerts in europe, or better germany Thumbs up ciao luigi Am 16.04.2010 um 23:46 schrieb pd-list-request(a)iem.at: >>>>> hello everyone, >>>>> >>>>> >>>>> In the link below there is a video documentation of a brand >>>> new >>>>> performance with the new MANO Controller called Silent >>>> Construction 2 >>>>> in a new webpage... lots of new things... >>>>> For those who were in Sao Paulo for the PdCon you may have >>>> heard >>>>> Silent Construction 1 (for Silent Drum). As in that case >>>> everything is >>>>> done in Pd/GEM and a few new externals... >>>>> >>>>> >>>>> hope you like it...: >>>>> >>>>> >>>> Dipl.-Ing. Luigi Rensinghoff postmaster(a)halbsolaut.de Mobil: 01775412191 Festnetz: 0351-7966370 web: www.halbsolaut.de

2 1

Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd?
by Jonathan Wilkes 16 Apr '10

16 Apr '10

--- On Fri, 4/16/10, Jonathan Wilkes <jancsika(a)yahoo.com> wrote: > From: Jonathan Wilkes <jancsika(a)yahoo.com> > Subject: Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd? > To: "PD list" <pd-list(a)iem.at>, "Phil Stone" <pkstone(a)ucdavis.edu> > Date: Friday, April 16, 2010, 8:11 AM > > > --- On Thu, 4/15/10, Phil Stone <pkstone(a)ucdavis.edu> > wrote: > > > From: Phil Stone <pkstone(a)ucdavis.edu> > > Subject: Re: [PD] nusmuk_audio WAS: Max Smoother Audio > than Pd? > > To: "PD list" <pd-list(a)iem.at> > > Date: Thursday, April 15, 2010, 7:49 PM > > In addition to disagreeing vehemently > > with your main point (Pd is good for little more than > > experimentation), I find this a piss-poor acid test > for > > "music that sounds good": > > > > colet.patrice(a)free.fr > > wrote: > > > there is no such project that show how pd is cool > to > > make people moving on the dance floor. > > > > > Phil- I dig music with compelling sounds, and I generally > feel the > urge to move my body to music I dig. One can use > whatever > test one wants to hold up some music as "genuine," and the > question "does > it draw people out onto the dance floor?" is just as valid > as any other in > this regard. > > But then if the point of the acid test is to demonstrate > the strengths > of a visual programming paradigm for the rapid > implementation of various > dsp techniques to generate music, I'd say the OP's test is > quite a fitting > and effective "Hello World" for Pd. > > -Jonathan Btw- I don't mean "this will be a 'Hello World' for Pd at some future point in its development." I just mean it's a good way for users to test how flexible and expressive their software is in a live setting. I mean let's face it-- you crash at a performance and people sit and read their programs while you restart the program. You crash while people are dancing, and they leave. -Jonathan

6 6

← Newer
1
...
12
13
14
15
16
17
18
...
29
Older →

Jump to page:

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 2010