Pd-list October 2010

pd-list@lists.iem.at

124 participants
181 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

pix_film: get frame rate
by tim vets 14 Oct '10

14 Oct '10

Hi all, (Apologies if this has been answered before) How do I get the frame rate of a video ? pix_film prints it to the console, but I'd like to get that number (29 or 25...) in my patch. the help says: Outlet 2: list: <length> <width> <height>: gets the dimensions (in fps and pixels) of a film ... but obviously "length" (number of frames) is not the same as "fps" (number of frames per second...)? Thanks, Tim

2 1

[tabosc4~] help
by Philip Cunningham 13 Oct '10

13 Oct '10

hey all. i'm using a monome/arduinome to write 8 values between 1 and -1 in an array and then using [tabosc4~] as a wavetable synth and then using [snapshot~] to take values and use them as control data. it works okay but i seem to be getting "bumps" in my waveform. some values slightly less than -1 and slightly more than 1. it may be because i've misunderstood the wraparound/interpolation but would appreciate if someone could give some guidance as how to achieve "cleaner" waveforms. i've removed the most of the monome parts for the patch. it should work fine with a bit of tinkering. cheers! http://philipcunningham.org/lfo.pd

1 0

Re: [PD] ps3eye, pix_video
by servando barreiro 13 Oct '10

13 Oct '10

HI. Have you tried to downscale the resolution of the image in pd? send the message [dimen 400 300( or whatever you need to pix_video I have tried that cam in a small laptop w linux and it was working very good and very fast out of the box. nº2- you need drivers for mac but you don´t need drivers for linux (I mean, all webcams/dv´s I tried, they worked perfectly in linux out ouf th box ), things are changing... cheers Hi Using a PS3 eye on Mas osX 10.6 : - with the macam program, out of PD, the response of the camera is very fast, - inside GEM, (pix_video) the latency is half a second, as much as with DV camcorders. I know this seems to be a recurring issue : Anyone has a way to get a quick response with pix_video in GEM OsX ? Any solution in pdp ? Is it necessary to switch to linux, DC cameras and complex drivers ? Any hint ? JmA

1 0

[PD-announce] /dev/art/#0 à Paris le 16/10/2010
by Jack 13 Oct '10

13 Oct '10

In french only (désolé pour le même mail provenant de différentes listes !). Pour une meilleure mise en page, vous pouvez consulter le PDF joint à ce mail : /dev/art/#0 Rencontres, discussions et échanges entre artistes et développeurs utilisant les nouvelles technologies de programmation issues du libre (PureData/Processing/Arduino/SuperCollider/etc.). Le 16 octobre de 14h à 18h au BlackBoxe 17 rue de la Chapelle / 75018 Paris Metro ligne 12 / Station Marx Dormoy ou Porte de la Chapelle 14h / 16h30 : rencontres, discussions et échanges autour des arts numériques et du développement d'applications, d'installations ou de performances. Avec Jack/RYbN, Sylvain Le Beux, Maurin Donneaud et Vincent Rioux. 16h30 / 18h : présentation du travail de Art Of Failure : Laps. Art Of Failure est un duo d'artistes français composé de Nicolas Maigret et Nicolas Montgermont. Leur travail se nourrit des avant-gardes historiques et d'expérimentations artistiques et scientifiques. Ils opèrent des glissements ou des transpositions, notamment de concepts vers le domaine plastique, de données géologiques vers l'édition vinyle, ou encore de l'informatique médicale vers le format concert. Ces détournements mettent en lumière des problématiques et des esthétiques propres aux technologies qui nous sont contemporaines. Leur travail est présenté sous de multiples formes : performances, installations, projets en ligne ou éditions. Le champ de recherche "Laps" se concentre sur la création de représentations sensibles d'Internet, en l'utilisant comme un espace de diffusion sonore. Les qualités spatiales et géographiques du réseau sont mises en évidence en diffusant des flux audio qui voyagent et résonnent à travers le web. L'écoute de ces flux par des procédés spécifiques permet de rendre audible une infinité de transformations affectant le son pendant qu'il circule sur le réseau. Ces altérations sont assimilables à une forme d'érosion causée par l'espace du réseau, une clé permettant différentes représentations mentales de cette topographie numérique. http://artoffailure.free.fr/ Entrée libre. Pass annuel au BlackBoxe offert. Prochain rendez-vous /dev/art/#1 le samedi 30 octobre à la Générale Nord-Est / 14 avenue Parmentier / 75011 Paris ++ Jack _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

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

Re: [PD] ugly fonts under pdextended 0.42.5
by Hans-Christoph Steiner 12 Oct '10

12 Oct '10

That's how Pd looks using Tcl/Tk 8.4 0.42.5 does not fully support Tcl/Tk newer than that, so Pd-extended uses 8.4. You can build Pd- extended against Tcl/Tk 8.5 if you want, or wait for Pd 0.43, which is fully compatible with Tcl/Tk 8.5 or newer. .hc On Oct 5, 2010, at 3:51 PM, Erik Maes wrote: > Repost; didn't make it to the list somehow. > > Hi, > > I have the same problem. after enabling the repo on Ubuntu Lucid, > aptitude first removed tk8.5. I reinstalled tk, but to no avail, and > update-alternatives didn't help either. > screenshot: <http://www.xs4all.nl/~dwaes/images/Screenshot.png> > > > On Tue, 2010-10-05 at 11:09 +0200, Hans-Christoph Steiner wrote: >> Can you post screenshots somewhere? >> >> .hc >> >> On Oct 4, 2010, at 3:02 PM, michael noble wrote: >> >>> Hi Hans, >>> >>> Neither reinstalling the fonts or switching to Tcl/Tk 8.5 made a >>> difference. Fonts in PD vanilla (0.42.6 from the repos) look fine, >>> by >>> the way. This is in Lucid and Maverick, not able to test on >>> Squeeze at >>> the moment. >>> >>> -m >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> "Free software means you control what your computer does. Non-free >> software means someone else controls that, and to some extent >> controls >> you." - Richard M. Stallman >> >> >> >> _______________________________________________ >> Pd-list(a)iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > ---------------------------------------------------------------------------- "We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill

5 7

← Newer
1
...
10
11
12
13
14
15
16
...
19
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 October 2010