Pd-list September 2010

pd-list@lists.iem.at

138 participants
246 discussions

a really fast-to-read codec in linux?
by Matteo Sisti Sette 14 Oct '10

14 Oct '10

Hi, I'm desperately looking for a codec to code video files with so that pix_film will be able to read them with the best performance. I don't care if the compression rate is very low, as long as the quality is good and reading is fast. Does anybody know any? Mjpeg seems to perform quite well, but not well enough. Maybe that's the best performance I can expect and I have to reduce the video resolution but I would like to be sure. H.264 has the problem that has been mentioned due to an issue of gstream with frame seeking that makes it terribly slow in linux. I'm trying all the codecs I see listed in avidemux, but there are so many and with so many configuration settings that I don't quite understand, and many of them just make Pd crash. By the way I would also like to know the answer to the same question in Mac. As far as I have seen, though, video with GEM seems to perform always much worst in Mac than in Windows and Linux with any codec (except h264 that has a big issue in linux only) - Mathieu said he probably knew the cause of this which was not related to codecs. thanks m.

15 31

Re: [PD] plugin~ external
by Kim Cascone 12 Oct '10

12 Oct '10

> > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/11/2010 10:36 AM, > Kim Cascone wrote: >>>> >>> >>>> >>> plugin~: "Delayorama" >>>> >>> print: port in control Random seed 0 1000 >>>> >>> >>>> >>> >> >>> >> looks good, doesn't it? >>> >> >>> >> > er, sure if it matched the console report (when plugin~ is sent [info]) >> > it would look even better! ;) >> > > it reports all "relevant" information. > ahhhhh...I now see why you say that it reports 'all relevant info' given the console info you posted below because I've been (unknowlingly) using the GridFlow [print] and I'm missing this info [see attached patch] I tested this with both [pd/print] and [print] and here are the results: using the [print] object [info] reports to console: a: port in control Random seed 0 1000 error: [print a]: close-paren without open-paren error: [print a]: close-paren without open-paren a: port in control Number of taps 2 128 error: [print a]: close-paren without open-paren error: [print a]: close-paren without open-paren a: port in control Delay change 0.2 5 error: [print a]: close-paren without open-paren a: port in control Amplitude change 0.2 5 error: [print a]: close-paren without open-paren a: port in control Dry/wet mix 0 1 a: port in audio Input 0 1 a: port out audio Output 0 1 using the [pd/print] object [info] reports to console: b: port in control Random seed 0 1000 b: port in control Input gain (dB) -96 24 b: port in control Feedback (%) 0 100 b: port in control Number of taps 2 128 b: port in control First delay (s) 0 5 b: port in control Delay range (s) 0.0001 6 b: port in control Delay change 0.2 5 b: port in control Delay random (%) 0 100 b: port in control Amplitude change 0.2 5 b: port in control Amplitude random (%) 0 100 b: port in control Dry/wet mix 0 1 b: port in audio Input 0 1 b: port out audio Output 0 1 this is really confusing for people using [print] not knowing they are using the GridFlow external instead of the standard Pd version how do we disentangle this and make it obvious? and why isn't there a GridFlow [print] external called [gf_print] instead? > >> > >> > is this a bug or known issue? >> >>> >> >>> >>>> >>> error: [print]: close-paren without open-paren >>>> >>> >>>> >>> >> >>> >> oops; seems there is a problem with displaying symbols with parenthesis. >>> >> >>> >> > I'm assuming here that not all LADSPA plugs send info with parentheses? >> > so this would be a problem only for those plugs that send data with >> > parentheses >> > > correct. > anyhow, when i try your plugin i get: > <snip> > plugin~: "Delayorama" > a: port in control Random seed 0 1000 > a: port in control Input gain (dB) -96 24 > a: port in control Feedback (%) 0 100 > a: port in control Number of taps 2 128 > a: port in control First delay (s) 0 5 > a: port in control Delay range (s) 0.0001 6 > a: port in control Delay change 0.2 5 > a: port in control Delay random (%) 0 100 > a: port in control Amplitude change 0.2 5 > a: port in control Amplitude random (%) 0 100 > a: port in control Dry/wet mix 0 1 > a: port in audio Input 0 1 > a: port out audio Output 0 1 > </snip> > > looks good to me. > yes and this matches the analyseplugin <foo> data > >> > ?? >> > >> > > >>> >> i don't seem to have this problem here (though i don't have the >>> >> delayorama plugin; >>> >> > I've attached it - see if this works for you? >> >>> >> and the "invada_mono_tube_module_0_1" works just fine >>> >> (with pd-vanilla 0.42.6) >>> >> >>> >> > ***do you have any info on how params are listed in [info]->[plugin~] >> > versus [analyseplugin <foo>] in the term? >> > how does one understand what to name the params when controlling a plugin? >> > >> > > the message is: > "port <symbol:direction> <symbol:type> <symbol:name> <float:lowerlimit> > <float:upperlimit>" > > with <symbol:direction> being either "in" or "out" > with <symbol:type> being "control" or "audio" > with <symbol:name> being the name of the port (e.g. "Amplitude random (%)") > > and lower/upperlimit define the valid range of the value. > > for controlling, you use "control <symbol:name> <float:value>" > > <symbol:name> is not case-sensitive, and it tries to find a simple match. > e.g. "Amplitude random (%)" can be controlled with "amp" or "AMPLItude" > or "Amplitude random (%)". > it will take the first port that matches, so if you have parameters > "FrequencyUpper" and "FrequencyLower", then "freq" will match > "FrequencyUpper", in order to conrol the other param you have to use at > least "frequencyl" > thanks a million for this :) -- let me chew on this info today and I'll see if I have any more questions > >> > also, I also noticed that I can't use a number in the [print] external >> > in my current version of PdX that I'm working in without causing the >> > error: 'expected symbol' >> > but in the latest version of PdX I can use a number as well as a symbol >> > in [print] >> > > well, you can use [print :1], if you want to stay compatible with e.g. > Pd-vanilla. > ok -- a good tip -- thanks again! > mfgasdr > IOhannes > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkwSNM0ACgkQkX2Xpv6ydvRhdACgpld4N/mRShDv/OT6p9Z8D/MT > MyMAn0b1mNdDPvlGn8FuMOf7Fp4iNhZ4 > =v7Gc > -----END PGP SIGNATURE----- >

13 34

VisualTracker 1 ALPHA 2 released
by Caucasian Caucasian 12 Oct '10

12 Oct '10

Dear all, second ALPHA of GUI sequencer including load/save system is finally done. Now it contains all the core functions planned for version 1 and up to BETA the focus will be made on graphics and usability. More info and download: http://code.google.com/p/visualtracker/ Hope some of you find the project interesting and will be able to leave a comment ( Hey!, 59 downloads of ALPHA 1 and not even single response ?!?!? ;-) or contribute) Many thanks to Bérenger for ideas, testing and even contributing one module. Looking forward to your opinions. aleš

3 3

[out-of-the-blue] a neat GUI feature?
by Pedro Lopes 12 Oct '10

12 Oct '10

I just remembered a feature* one could have in the future (it relates to various threads and interesting discussions we had here): - When rolling the mouse over a outlet of an abstraction it could tell what that was. (useful for those crazy objects with n-th outs) How could he tell what that outlet carries? This could be a sort of metadata comment (or other better/clever idea) added to the subpatch/abstraction that would be parsed and read by the GUI in order to simplify your work. Like "Metadata/Outlets: sound(mono); data(0.0-1.0); toogle(0-1); on-off(bang);" Then in our main patch: __________________ |my_giant_abstraction| | *_ *_ _ _ ___________| When rolling through outlet "1" it would say "Sound(mono)"., and so forth Conversely, one could do the same for inputs/inlets. Just a though after many hours of pd, Best regards, Pedro * maybe this has been though/brought up here, its worth the try. p.s.: anyway I'll take note of this, maybe I could try a simple version of it sometime... -- Pedro Lopes (ongoing MSc) contact: pedro.lopes(a)ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes

8 26

Re: [PD] [PD-dev] odd key object behavior under Linux
by Ivica Ico Bukvic 12 Oct '10

12 Oct '10

Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-). Best wishes, Ico martin.peach(a)sympatico.ca wrote: > >It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. >So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;) > >Martin > > > > >Ico wrote: > >> It all started when I noticed that my threaded version of coll object >> tended to freeze Pd at apparently random points. As it turns out, I was >> testing its robustness simply by passing a key into a read/write message >> and holding the key down to generate a large number of requests per >> second and the [key] object at times seemed to spit out (while >> autorepeat of the pressed key was taking place) two outputs at the same >> time which in turn crashed Pd as threaded coll object did not handle >> this gracefully. I've since fixed the coll object but the key behavior >> baffles me. >> >> The double redundant output is apparent in both rt and non-rt Pd (on >> Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is >> the simplest patch to invoke this. >> >> Basically, I am measuring the aforesaid time delta between broadcast >> strokes using timer object and printing it out to console. >> >> #N canvas 549 345 383 297 10; >> #X obj 162 83 key; >> #X obj 162 107 sel 32; >> #X text 208 108 space; >> #X obj 162 145 timer; >> #X obj 162 182 print; >> #X connect 0 0 1 0; >> #X connect 1 0 3 1; >> #X connect 1 0 3 0; >> #X connect 3 0 4 0; >> >> So, while certainly the fact that threaded version of coll wasn't >> handling gracefully multiple redundant requests at the same time was a >> bug (which I am hoping has been fixed now), I am wondering whether the >> aforesaid [key] behavior might be a bug as it seems to me that >> keystrokes of the same key, even if the key is autorepeating should >> never have a time delta of zero. Naturally, one can always put a >> speedlim after the [key] object but that might result in a truncated >> output of fast typing. >> >> I would greatly appreciate it if others can test this to see if they are >> getting the same results. >> >> FWIW, allowing this kind of key behavior in more complex patches did >> result in the pd<->gui communication tearing with the stderr reporting >> several truncated messages before crashing. Due to their complexity and >> unpredictability of a point where tearing would occur I am not sure >> where the problem might be stemming from but it is undoubtedly at least >> in part instigated by double redundant output from the key object >> possibly in conjunction with objects that may have not provided graceful >> handling of such requests. >> >> NB: I only tested the same patch on Win platform and there it does not >> exhibit this problem. >> >> Any thoughts would be most appreciated. >> >> Best wishes, >> >> Ico >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev(a)iem.at >> http://lists.puredata.info/listinfo/pd-dev >

8 12

svn co ...documentation
by august 09 Oct '10

09 Oct '10

Hi, I just spent about 30-40 minutes trying to figure out how to get a writable svn checkout. Is there any way someone could add that info to one of the multiple pages that try to instruct you to get the source? http://puredata.info/docs/developer/GettingPdSource http://puredata.info/docs/developer/SourceRepositories http://puredata.info/docs/developer/SVNCommitAccess For developers like myself who only make occasional commits, something like this would really help. There are too many version control systems and frameworks to remember how to do everything, everywhere. A few simple command line examples would really help. thank you -august.

6 11

jMax Phoenix
by Maurizio De Cecco 08 Oct '10

08 Oct '10

Hallo, my name is Maurizio De Cecco, and i am the maintainer and developper of the jMax Phoenix project, a kind of cousin of Puredata. Having release a new beta for jMax (on Linux and Mac OS X), and after discussing with Miller Puckette, i think the members of this list may be interested in knowing more about the project, and may be take a look. A bit of history: i worked in Ircam in the 90s, where i was lucky enough to work with Miller Puckette on Max/ISPW and following versions; i then worked on jMax, that was intended to be a 'next generation' Max for the Ircam projects; jMax was used in a few large productions; i left in 99 for pursing other interest (Linux Mandrake, at that time :), and forgot for a while about jMax. In the meanwhile, jMax was put under a GPL licence, and after a couple of years Ircam stopped its development (don't ask me why, i wasn't there). In 2008 i was getting severely bored: server side Java, quality indicators and software engineering was my daily bread, and no code to write; so, to keep my developer mind healthy, i took up the development of jMax, starting from the last release i worked on. Given the fact that jMax slept a few years, it cannot compete with puredata in terms of available libraries, patches, and in general maturity of the solution. But it have its own peculiarity, a number of different ideas, and having a code base but no users (yet, i hope:) allows some bold design decision to be taken; think of jMax Phoenix as a kind of research project in same family where Puredata is. Describing the differences between jMax and Puredata would be long, because it would need to go back to the original developments; to be very synthetic i would resume in the following: 1) Architecture: the jMax user interface run on a different process, and it written in Java. 2) APIs are completely different, but see below. 3) The Object Set is reduced to the old ISPW object set; jMax can also transparently include LADSPA plugins as objects; finally, i developped compatibility layer (to be completed) that allows to recompile simple pd objects for jMax, and possibly to load pd abstractions. 4) User Interface: there is a lot of work going on in the UI, that allows, between other, the used of a single window IDE style interface. 5) Packaging and configuration: jMax Phoenix support the packaging of complex libraries and applications in a single file, and even automatically grab libraries from the internet. 6) The language: jMax support the use of expressions in object definition, like in | int ( 10 + $foo) | so that objects in abstractions can be parametrised with respect to the arguments. 7) Hopefully in between 6 month and a year: an optimising dsp compiler and engine able to run a patch in parallel on multiple core (where multiple means around 8). For anybody more interested, the project site is http://www.jmax-phoenix.org/, and the binaries and sources can be loaded from the project sourceforge site, http://sourceforge.net/projects/jmax-phoenix/ For your information, i include at the end of the mail the formal announce of the 0.6 beta release; it does not mention the Max OS X version, that was not ready at the time. Maurizio ------------------------------------------------------------------------- After many month of development, we are proud to announce the version 0.6 beta of jMax Phoenix. The major highlights for this version are: - A first version of the puredata source compatibility kit, including the build system and a full example of recompiled object library. - A large set of usability bug fixed; all the bugs preventing a smooth work flow have been fixed. - Error handling improvements: most of the bugs and configuration errors now results in error messages, and not unexplained freezes. - A set of examples and tutorials has been recovered from old ISPW archives; they are not updated to include all the major jMax functionalities, but it is better than nothing. Full release notes are available in the release notes section of the projet site. This release has been tested on Ubuntu and Ubuntu Studio 10.04, Debian 5, Fedora 13 and Mandriva Spring 2010; check the installation instruction on the projet site for specific caveats for Debian and Fedora. The Puredata compatibility sub-project has been *very* time consuming; in order to better manage my scarce time resources, we need some user feedback (and possibly help) to be able to evaluate the actual interest of pursuing this development direction. For more information and download and installation instructions go to http://www.jmax-phoenix.org/. For contacting the project team: contact(a)jmax-phoenix.org The jMax Phoenix team __________ Maurizio De Cecco - Music: http://www.myspace.com/mauriziodececco Blog: http://maurizio.dececco.name/ Software: http://www.jmax-phoenix.org/

10 59

Flexible Step Sequencers For Pd Vanilla
by saint 08 Oct '10

08 Oct '10

Hi, Following the Pd Berlin meeting last Tuesday, the guys encouraged me to share my patches. Here are my step sequencers for Pd vanilla. With a bit of imagination they can be used for many things other than beat/drum patterns. In the example patches you can see one used as a metro to drive the other sequencers which can lead to interesting groove/swing/shuffle sounds. Also to repetitively control parameters like filter cutoff/pitch/LFO rate/effects on synthesizers too. Connect them to each other to create conditionally generative randomness. All these methods are employed in the example patches. http://puredata.info/Members/saintidle/j-array-lane-pd-j-array-numbers-pd-j… Feedback welcome of course but I'm afraid they're supplied as is for you to use and abuse. I doubt I'll have the time to update/document them properly! Cheers, John Flynn.

2 1

namecanvas obsolete? Why? Re: Dynamic Graph on Parent
by brandon zeeb 05 Oct '10

05 Oct '10

According to [namecanvas] help, this object is obsolete? How else can one send a message to one and only one abstraction without using namecanvas? Is there the concept of 'this'? The example below will send a message to all patchname.pd abstractions, this is not what I think most require: [message( | [s pd-patchname.pd] On Wed, Sep 29, 2010 at 10:30 PM, brandon zeeb <zeeb.brandon(a)gmail.com>wrote: > Oh, that is awesome! Thanks a bunch for compiling these for me. > > Going to have some fun tonight... > > ~B > > > On Wed, Sep 29, 2010 at 10:13 PM, Jonathan Wilkes <jancsika(a)yahoo.com>wrote: > >> You can create [namecanvas $0-foo] in the relevant canvas, then >> [message( >> | >> [s $0-foo] >> >> You can also send a message to a named subpatch like [pd foo] by >> prefixing the subpatch name with "pd-" like this: >> >> [message( >> | >> [s pd-foo] >> >> And finally, send to an abstraction or open patch (globally) by >> using: >> >> [message( >> | >> [s pd-patchname.pd] >> >> I'm not sure if the "pd-" prefix is explicitly documented anywhere-- >> I only remember seeing it in passing with reference to traversing >> scalars. Maybe it could be added to doc/manuals/pd-msg, then >> have a link to that from canvas-help.pd. >> >> -Jonathan >> >> >> --- On *Thu, 9/30/10, brandon zeeb <zeeb.brandon(a)gmail.com>* wrote: >> >> >> From: brandon zeeb <zeeb.brandon(a)gmail.com> >> Subject: Re: [PD] Dynamic Graph on Parent >> >> To: "PD List" <pd-list(a)iem.at> >> Date: Thursday, September 30, 2010, 3:53 AM >> >> >> How is this sent to the current patch? Can you give me a quick example. >> >> Thanks >> ~B >> >> On Wed, Sep 29, 2010 at 4:41 PM, Jonathan Wilkes <jancsika(a)yahoo.com<http://mc/compose?to=jancsika@yahoo.com> >> > wrote: >> >> A canvas accepts a "donecanvasdialog" message that can be used >> to do what you want. Search the list for that. >> >> There's also the "coords" message, which takes its arguments in a >> different order than "donecanvasdialog" and doesn't set the dirty >> flag for Pd < 0.43. Other than that I'm not sure what the >> differences are between the two messages. >> >> -Jonathan >> >> --- On *Wed, 9/29/10, brandon zeeb <zeeb.brandon(a)gmail.com<http://mc/compose?to=zeeb.brandon@gmail.com> >> >* wrote: >> >> >> From: brandon zeeb <zeeb.brandon(a)gmail.com<http://mc/compose?to=zeeb.brandon@gmail.com> >> > >> Subject: [PD] Dynamic Graph on Parent >> To: "PD List" <pd-list(a)iem.at <http://mc/compose?to=pd-list@iem.at>> >> Date: Wednesday, September 29, 2010, 10:08 PM >> >> >> Is there a way to dynamically adjust and enabled graph on parent (GOP)? >> I'm building some UI sequencer widgets and it would be preferable to >> dynamically adjust the GOP size given user input, say number of steps in a >> step sequencer (ie: an 8x8 vs a 16x16 step sequencer using the same >> abstraction). >> >> If this is documented anywhere a link to the docs will suffice, I'm unable >> to find any. >> >> Thanks, >> ~Brandon >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> Pd-list(a)iem.at <http://mc/compose?to=Pd-list@iem.at> mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> Pd-list(a)iem.at <http://mc/compose?to=Pd-list@iem.at> mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >

5 19

PureData to C/C++ language
by ankur gandhe 05 Oct '10

05 Oct '10

I was working on a Sound renderer project made in PD and to reduce the latency, we wanted to write the module in C, implementing all the features. Is their a simple way of doing so? If so, please do help Ankur

7 12

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 September 2010