Pd-list April 2010

pd-list@lists.iem.at

143 participants
284 discussions

how to type more than one "space" in GEM with [text2d]
by Ingo Scherzinger 20 Apr '10

20 Apr '10

Is it possible to type more than one consecutive "space" with GEM [text2d] ? I need to print some type of karaoke lyrics with chord changes on the line above. Obviously the chord symbols need to be right where the changes are in the lyrics. Maybe there is another solution or object to do this - I'm quite new to GEM so I don't really know many objects. Thanx, Ingo

4 9

pix_video v4l
by august 20 Apr '10

20 Apr '10

Hey, I have a schleptop with a built-in camera (lenovo t400). Xawtv works great, but I cannot get pix_video to start. When I start it (trying out lots of different options), it says: VIDIOCSCHAN: Invalid argument Anyone have an idea how to fix Pixes/videoV4L.cpp so that it makes the right ioctls? thanks -august. Here is my v4linfo: ### v4l2 device info [/dev/video0] ### general info VIDIOC_QUERYCAP driver : "uvcvideo" card : "Integrated Camera" bus_info : "usb-0000:00:1a.7-6" version : 0.1.0 capabilities : 0x4000001 [VIDEO_CAPTURE,STREAMING] standards inputs VIDIOC_ENUMINPUT(0) index : 0 name : "Camera 1" type : CAMERA audioset : 0 tuner : 0 std : 0x0 [] status : 0x0 [] video capture VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE) index : 0 type : VIDEO_CAPTURE flags : 0 description : "YUV 4:2:2 (YUYV)" pixelformat : 0x56595559 [YUYV] VIDIOC_G_FMT(VIDEO_CAPTURE) type : VIDEO_CAPTURE fmt.pix.width : 640 fmt.pix.height : 480 fmt.pix.pixelformat : 0x56595559 [YUYV] fmt.pix.field : NONE fmt.pix.bytesperline : 1280 fmt.pix.sizeimage : 614400 fmt.pix.colorspace : unknown fmt.pix.priv : 0 controls VIDIOC_QUERYCTRL(BASE+0) id : 9963776 type : INTEGER name : "Brightness" minimum : -128 maximum : 127 step : 1 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(BASE+1) id : 9963777 type : INTEGER name : "Contrast" minimum : 0 maximum : 100 step : 1 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(BASE+2) id : 9963778 type : INTEGER name : "Saturation" minimum : 0 maximum : 100 step : 1 default_value : 0 flags : 0 VIDIOC_QUERYCTRL(BASE+3) id : 9963779 type : INTEGER name : "Hue" minimum : -20 maximum : 20 step : 1 default_value : 0 flags : 0 ### video4linux device info [/dev/video0] ### general info VIDIOCGCAP name : "Integrated Camera" type : 0x1 [CAPTURE] channels : 1 audios : 0 maxwidth : 1280 maxheight : 1024 minwidth : 48 minheight : 32 channels VIDIOCGCHAN(0) channel : 0 name : "Camera 1" tuners : 0 flags : 0x0 [] type : CAMERA norm : 0 tuner audio picture VIDIOCGPICT brightness : 32382 hue : 32768 colour : 0 contrast : 0 whiteness : 0 depth : 16 palette : YUYV buffer window VIDIOCGWIN x : 0 y : 0 width : 640 height : 480 chromakey : 0 flags : 0

5 6

phasor~ and osc~ right inlet: signal?
by Jaime Oliver 20 Apr '10

20 Apr '10

Hi all, It would be great it phasor~ and/or osc~ could receive phase information (right inlet) as a signal. objects like *~ can recognize if they are receiving a float or a signal on their left inlet? if this feature was added in vanilla, would it break anything? is it possible, worthwhile? is there a third party external doing this? 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

7 22

Control-rate computations in the Signal domain (was Re: Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?)
by András Murányi 19 Apr '10

19 Apr '10

On Sun, Apr 18, 2010 at 2:47 PM, Frank Barknecht <fbar(a)footils.org> wrote: > Hi, > > On Sun, Apr 18, 2010 at 01:07:21PM +0200, Matteo Sisti Sette wrote: > > Frank Barknecht escribió: > > > *If* order matters to you (it may not always do) you can still use > > >the subpatch approach with dummy inlet~/outlet~ objects. > > > > That's the part I don't understand. I mean I can't figure out the > > trick. I can easily imagine (and actually tried) how to patch things > > to force the desired order, but then again, I see myself obliged to > > do the wired connections that the [s~]/[r~]s were meant to avoid. > > > > May you please make an example of the technique? I would be so grateful. > > Attached is a very stupid example, which should show what I mean: Here > various abstractions are layed out in a way, that they execute in order. > Only one connection is used for order forcing, but still many s~/r~ are > active, all properly ordered. > > Real life examples may not be so easy to sort, of course. > > > >And don't forget the other application of s~/r~ where you actually > > >*want* to have a delay of one block: feedback algorithms. > > > > Yeah but in that case I would rather use a [delread~]/[delwrite~] pair, > ¿no? > > Well, you could, but s~/r~ is much easier to use. Also > delread~/delwrite~ with a delay set to 0 won't have a delay of 0 in > feedback situations, so it may even be more confusing. > > > Wow that sounds very interesting. I hope you will publish the paper > > on the internet so we can have a look > > It will be in the LAC proceedings available on lac.linuxaudio.org soon. > I'll keep checking but it would be real nice if you could post it here when available. I hear some of my friends using this technique rather successfully... Thanks, Andras

1 0

Re: [PD] ZenGarden license x Pure Data license
by Alexandre Porres 19 Apr '10

19 Apr '10

Wow.... seems like something REALLY important here, huh!?! 2010/4/18 Jarbas Jacome <jandila(a)gmail.com> > ---------- Forwarded message ---------- > From: Jarbas Jacome <jandila(a)gmail.com> > Date: Sun, Apr 18, 2010 at 10:49 PM > Subject: ZenGarden license x Pure Data license > To: Pure Data List <pd-list(a)iem.at> > > > Hello all. > Nice project. > I have a question: > As ZenGarden is LGPL, doesn't it allow someone to do a proprietary and > closed software using it? > If yes, doesn't it conflicts with Pure Data license? > thank you very much. > jjR >

2 1

error: recordQT: EndMediaEdits failed with error -2008
by mail＠c-m-fischer.de 19 Apr '10

19 Apr '10

Dear list, I build myself a machine for live video mixing. That works very stable. PD-extended 0.41.4 on Mac OSX 10.5.8 Now I would like to record the stuff to disk. Only once. I used the complete pix_record device from the helpfile. Unfortunetely the following errors occur. 1. error: recordQT: problem with fd error: recordQT: EndMediaEdits failed with error -2008 2. I name a file and place where to save it. Recording starts, but one can not stop the recording. So no file is saved. Or error one occurs. ( Is there some other way to write a video to the disk than pix_record? Dont want to use a screencapture tool... Best! christian

2 1

Re: [PD] phasor~ and osc~ right inlet: exact timing
by Matt Barber 19 Apr '10

19 Apr '10

> Coming up again with the 'smoother' topic: > Is [phasor~]-[cos~ ] precision-wise and interpolation-wise the same as > an [osc~]? If not, which has less error and why? I think each one is 512-point linear interpolated. m_pd.h: #define LOGCOSTABSIZE 9 #define COSTABSIZE (1<<LOGCOSTABSIZE) This would give you 512 points. The code for both osc~ and cos~ have: *out++ = f1 + frac * (f2 - f1); Which, if the mnemonically named "frac" variable is just the fractional part of the index between f1 and f2, is a simple linear interpolation between the two points. For this reason I almost always use an 8192-point [table] and [tabread4~] if I need more accurate sinusoids; I've gotten pretty severe errors especially in cases where I need to divide a signal by the output of a cosine oscillator near 90-degrees phase (near the zero-crossing), and even more especially where the numerator is also near zero, just using [cos~], presumably both because the values from the oscillator output are near zero and because the function is changing at the greatest rate there. IIRC SuperCollider's SinOsc uses an 8192-point table with linear interpolation, and Phasor+BufRd you specify the table size and the type of interpolation (the cubic is the same as the Hermite one in [tabread4c~]). In csound's oscil* or phasor+table* opcodes you specify the table size (power of 2) and the type of interpolation (the cubic is identical to the Lagrange one in Pd). Someone please correct me if I'm mistaken. MB

2 2

ZenGarden license x Pure Data license
by Jarbas Jacome 19 Apr '10

19 Apr '10

Hello all. Nice project. I have a question: As ZenGarden is LGPL, doesn't it allow someone to do a proprietary and closed software using it? If yes, doesn't it conflicts with Pure Data license? thank you very much. jjR

3 2

Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
by Matteo Sisti Sette 19 Apr '10

19 Apr '10

Hi frank, Thank you for the clarifications. However, I don't see how you would "sort" (i.e. force a desired execution order) [send~]s and [receive~]s in a useful way, that is in situations where you need them. If the only way to force execution order is by actually creating a "wired" path with subpatches, then it seems to me it is useless for [s~]s and [r~]s because if you can sort them in a wired way, then you can just replace them by wires, so you didn't need them in the first place. Is there some other way of "sorting" them?? > It's the > same for messages, that's why I always keep telling newbies to > use more > [trigger] objects. No it's not the same. There is a big difference. A [s] and a [r] (no tilde) _is_ equivalent to a wired connection. Ok if you have a [s xxx] and multiple [r xxx]s you cannot control the order of execution of the receives, but you _do_ know that all those [r]s (and their subtree) will be executed before the following "sibling" nodes of the [s] are executed. That is exactly the same that would happen if you had a wired connection between what is connected to [s] and all the subtrees that are connected to the [r]s: a direct one-to-many wired connection without a [trigger]. The problem with [s~] and [r~] is not the execution order among the multiple [r~]s, i.e. which [r~] is executed first. The problem is that you don't know whether the [s~] or the [r~] is executed first. That has no analogy with [s] and [r] as far as i can see. -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

3 7

Re: [PD] line~ weird behavior
by colet.patrice＠free.fr 19 Apr '10

19 Apr '10

hi, I tried a quartic enveloppe generator for building a drumbass and observed a weird modulation, the ramp signal moves following a cycle around several samples, using vline~ fixes it, the attached patch shows this weird behavior. ----- Mail Original ----- De: "Matteo Sisti Sette" <matteosistisette(a)gmail.com> À: reduzierer(a)yahoo.de Cc: "PD list" <pd-list(a)iem.at> Envoyé: Dimanche 18 Avril 2010 20h42:40 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [PD] phasor~ and osc~ right inlet: exact timing Roman Haefeli escribió: > On Sun, 2010-04-18 at 11:43 -0400, Mike Moser-Booth wrote: >> Matteo Sisti Sette wrote: >>> By the way, what about the sample-accurate-phase-resettable osc~? >>> >>> >> Hey Matteo, >> >> Just use [vphasor.mmb~] to look up [cos~]. > > Coming up again with the 'smoother' topic: > Is [phasor~]-[cos~ ] precision-wise and interpolation-wise the same as > an [osc~]? If not, which has less error and why? I subscribe the same question -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com _______________________________________________ Pd-list(a)iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

2 1

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