Re: [PD] phasor~ and osc~ right inlet: exact timing
Hi, On Sun, Apr 18, 2010 at 11:42:45AM -0400, Mike Moser-Booth wrote: Frank, I was looking at your comparison patch and noticed you took the [+~ 2] out. The reason I put this in is because [wrap~] converts 0 to 1, so if you reset the phase to 0 you'll end up starting at the end instead of the beginning. Yeah, that's a nasty old bug of wrap~. Miller, when can we get a fix? :) I simplified it away here just to concentrate on the other aspect. Btw.: vanilla's [wrap] in Pd can be used to replace the modf-expr you use after the phase inlet - [wrap] for messages is even correct for 0. :) Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
Hi, On Sun, Apr 18, 2010 at 03:24:56PM +0200, Matteo Sisti Sette wrote: By the way a similar improvement in the message domain would be the possibility to force an order among [r]s of a given [s]. In this case the interface would be simpler: just a numeric argument for the [r], for example: [s xxx], [r xxx 0], [r xxx 1], etc. where receives with the same number would be executed in unpredictable order. Btw. [gemhead] has this in a way. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Hi, On Mon, Apr 19, 2010 at 09:21:35AM +0200, Frank Barknecht wrote: On Sun, Apr 18, 2010 at 11:42:45AM -0400, Mike Moser-Booth wrote: Frank, I was looking at your comparison patch and noticed you took the [+~ 2] out. The reason I put this in is because [wrap~] converts 0 to 1, so if you reset the phase to 0 you'll end up starting at the end instead of the beginning. Yeah, that's a nasty old bug of wrap~. Miller, when can we get a fix? :) I simplified it away here just to concentrate on the other aspect. Btw.: vanilla's [wrap] in Pd can be used to replace the modf-expr you use after the phase inlet - [wrap] for messages is even correct for 0. :) Oh, and I hope you don't mind, but I added a simplified, expr-less version to the rj library as s_vphasor as attached (giving you credit). There I added the 2 to the phase value sent into the vline~ to save on signal addition object - iDevices are slow. :) Ciao -- Frank #N canvas 118 17 879 550 10; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-s 100 float 0; #X coords 0 1 99 -1 200 140 1; #X restore 529 255 graph; #X obj 630 206 tabwrite~ \$0-s; #X obj 630 60 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 630 85 metro 150; #N canvas 377 58 827 710 REFERENCE 0; #X text 114 141 Summary: phasor~ clone with sample accurate phase setting ; #X text 114 121 Name: s_vphasor; #X text 114 164 Inlet 0: audio signal or float to set frequency; #X text 114 217 Outlet 0: phasor signal between 0 and 1; #X text 122 529 Tags: phasor \, phase \, sample accurate \, samphold ; #X text 114 184 Inlet 1: float to set phase. Range is 0 to 1 \, values outside are wrapped.; #X text 112 251 Description: s_vphasor is almost like [phasor~] in Pd \, but it allows setting the phase through the left inlet with sample accuracy and it does not support setting its frequency with an argument. Based on an approach by Mike Moser-Booth.; #X coords 0 -1 1 1 450 450 1 100 100; #X restore 5 48 pd REFERENCE; #X text 5 13 s_vphasor - phasor~ clone with sample accurate phase setting ; #X obj 526 161 s_vphasor; #X obj 527 90 sig~ 1234; #X msg 586 125 0.25; #X floatatom 527 62 5 0 0 0 - - -; #X msg 528 454 yticks 0 0.1 5; #X obj 528 475 s \$0-s; #X obj 528 432 loadbang; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 3 0 8 0; #X connect 6 0 1 0; #X connect 7 0 6 0; #X connect 8 0 6 1; #X connect 9 0 7 0; #X connect 10 0 11 0; #X connect 12 0 10 0; #N canvas 326 55 693 430 10; #X obj 73 44 inlet~; #X obj 72 335 outlet~; #N canvas 263 13 762 384 banghold~ 0; #X obj 101 280 samphold~; #X obj 162 255 vline~; #X obj 205 100 samplerate~; #X obj 205 122 swap 1000; #X obj 205 147 /; #X obj 205 69 loadbang; #X obj 162 198 f; #X msg 162 230 -1 \, 0 0 \$1; #X obj 162 41 inlet; #X obj 162 177 b; #X obj 102 41 inlet~; #X obj 101 304 outlet~; #X msg 289 69 bang; #X text 234 24 samples its input whenever it receives a bang at the first inlet. Accurate up to one sample duration.; #X connect 0 0 11 0; #X connect 1 0 0 1; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 1 4 1; #X connect 4 0 6 1; #X connect 5 0 2 0; #X connect 6 0 7 0; #X connect 7 0 1 0; #X connect 8 0 9 0; #X connect 9 0 6 0; #X connect 10 0 0 0; #X connect 12 0 2 0; #X restore 89 127 pd banghold~; #X obj 71 165 -~; #X obj 71 297 wrap~; #X obj 71 240 +~; #X obj 72 81 phasor~; #X obj 170 43 inlet; #X obj 202 206 vline~; #X obj 202 95 wrap; #N canvas 228 198 627 317 LICENSE-BSD 0; #X text 121 56 This software is copyrighted by Miller Puckette \, Reality Jockey Ltd. and others. The terms (the Standard Improved BSD License) apply to all files associated with the software unless explicitly disclaimed in individual files.; #X text 123 148 See the file LICENSE.txt for the full license text. ; #X restore 233 40 pd LICENSE-BSD; #X obj 202 177 + 2; #X obj 170 67 t b f; #X text 235 177 workaround for a bug in [wrap~] which converts 0 to 1; #X connect 0 0 6 0; #X connect 2 0 3 1; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X connect 6 0 3 0; #X connect 6 0 2 0; #X connect 7 0 12 0; #X connect 8 0 5 1; #X connect 9 0 11 0; #X connect 11 0 8 0; #X connect 12 0 2 1; #X connect 12 1 9 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to type more than one space in GEM with [text2d] - [textfile] output?
On 2010-04-18 16:16, Martin Peach wrote: Ingo Scherzinger wrote: Is there an object that can read textfiles (or any other file type) that includes spaces and can output these spaces (as something) so I can convert them to ascii 32 or ascii 160? [mrpeach/binfile] will output raw bytes from any file, so spaces in a text file will show up as 32. and Gem is (almost[1]) able to directly read these via the string message. that's all documented for [text3d], and all [text*] objects basically have the same interface. gmasd IOhannes [1] if you only use ASCII; if you want to use extended characters, you have to convert the UTF-8 bytes that you get out from [binfile] into Unicode-codepoint numbers. there's an abstraction somewhere in iem/unicode/ that does just that. i seem to remember that something like this was on the list just recently... smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] line~ weird behavior
On Mon, 2010-04-19 at 03:45 +0200, colet.patr...@free.fr wrote: 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. I guess, you forgot the attachment. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
On 2010-04-19 09:27, Frank Barknecht wrote: Hi, On Sun, Apr 18, 2010 at 03:24:56PM +0200, Matteo Sisti Sette wrote: By the way a similar improvement in the message domain would be the possibility to force an order among [r]s of a given [s]. In this case the interface would be simpler: just a numeric argument for the [r], for example: [s xxx], [r xxx 0], [r xxx 1], etc. where receives with the same number would be executed in unpredictable order. Btw. [gemhead] has this in a way. and [gemreceive] has it exactly in this way. (its [gemreceive] because i would like to replace [gemhead] with an abstraction, and don't depend on external libraries like iemguts where you have the [oreceive] (Ordered RECEIVE) object, both of which are identically) fgamsdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] tables in 64bit puredata
On 2010-04-18 22:05, august wrote: I just built pd 0.41.4 extended and can see that in all of the sampler i seems like you really should to try to update to the newest versions of everything. ghmsdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ZenGarden license x Pure Data license
On 2010-04-19 03:49, Jarbas Jacome wrote: 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? why would it? max/MSP did not conflict either fgamsr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] second instrument/piece in the silent percussion project...
+1! M On Fri, Apr 16, 2010 at 12:26 AM, Jaime Oliver jaime.oliv...@gmail.comwrote: well, it isn't more sensitive in terms of resolution: same camera, dimensions, etc. it actually currently runs at a lower frame rate than the drum, but it is really analyzing the hand multidimensionally so you get much more nuance than analyzing the fabric and much more variables are extracted, many of them interdependent. so with practice, things start to come along, curiously, just like any other instrument...! J On Thu, Apr 15, 2010 at 5:46 AM, Marco Donnarumma de...@thesaddj.comwrote: I'm always impressed by the sensitivity of your instruments. Brilliant work. MANO looks far more sensitive than the silent drum, or is it just my impression? -- Marco Donnarumma aka TheSAD Independent New Media Arts Professional, Performer, Teacher - Edinburgh, UK PORTFOLIO: http://marcodonnarumma.com LAB: http://www.thesaddj.com | http://cntrl.sourceforge.net | http://www.flxer.net EVENT: http://www.liveperformersmeeting.net -- 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 -- Marco Donnarumma aka TheSAD Independent New Media Arts Professional, Performer, Teacher - Edinburgh, UK PORTFOLIO: http://marcodonnarumma.com LAB: http://www.thesaddj.com | http://cntrl.sourceforge.net | http://www.flxer.net EVENT: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Thanks a lot for your explanations! On Sun, 2010-04-18 at 22:14 -0400, Matt Barber wrote: For this reason I almost always use an 8192-point [table] and [tabread4~] if I need more accurate sinusoids; By using 'sinesum' messages to [table]s? I can't think of another way to have access to more precise sinusoids in Pd, or is there any? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] error: recordQT: EndMediaEdits failed with error -2008
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Thanks a lot for your explanations! On Sun, 2010-04-18 at 22:14 -0400, Matt Barber wrote: For this reason I almost always use an 8192-point [table] and [tabread4~] if I need more accurate sinusoids; By using 'sinesum' messages to [table]s? I can't think of another way to have access to more precise sinusoids in Pd, or is there any? Yes, either that (which seems to use the math.h sin or cos functions), or an [until] + [sin] + [tabwrite] routine. The former is easier, obviously, and also adds the three guard points automatically (it also seems to use the same precision of PI=3.14159 that you can get with floats in Pd patches). If you want the code, look for the function garray_dofo in g_array.c Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] error: recordQT: EndMediaEdits failed with error -2008
[pix_write] or [pix_writer] to save each frame as picture on hard drive. Then use another tool to make your movie. ++ Jack Le lundi 19 avril 2010 à 13:44 +0200, m...@c-m-fischer.de a écrit : 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ZenGarden license x Pure Data license
Wow seems like something REALLY important here, huh!?! 2010/4/18 Jarbas Jacome jand...@gmail.com -- Forwarded message -- From: Jarbas Jacome jand...@gmail.com Date: Sun, Apr 18, 2010 at 10:49 PM Subject: ZenGarden license x Pure Data license To: Pure Data List pd-list@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ZenGarden license x Pure Data license
On Mon, 19 Apr 2010, Alexandre Porres wrote: Wow seems like something REALLY important here, huh!?! 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. GPL and LGPL licenses don't conflict with SIBSD. SIBSD is the version of the BSD license that Pd uses and that most people mean when they say « BSD license » nowadays. It resulted from the idea of Richard Stallman to get everybody on the BSD license to drop the Advertisement Clause, which was not only conflicting with the GPL, but also with customised versions of the BSD license... It's a long story. http://en.wikipedia.org/wiki/BSD_license http://www.fsf.org/licensing/compliance/index_html/contact/education/essays/index_html/bsd.html IanaL. PS: Apparently, « Standard Improved BSD » is an expression that is only used in the Pd world. I thought I had originally read that name from the FSF site, but apparently, I didn't. Apparently, there is no standard name for that license, but that name is the one that Miller used in LICENSE.txt. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD] Zen Garden re-implementing the wheel in C++?
Guys, and how about PD-anywhere? How ZenGarden is influenced by? Isn't them so similar? Thanks. 2010/4/18 Frank Barknecht f...@footils.org On Sat, Apr 17, 2010 at 04:12:51PM +0200, Matteo Sisti Sette wrote: I don't think it is more ambiguous than the order of execution of this: [adc~] | [dac~] Either (a) adc-dac or (b) dac-adc. In Pd it's always (a) because patch cords define the execution order for signals. There's no ambiguity, but you cannot do loops this way (DSP loop detected). Indeed loops by direct wiring are not allowed in Pd. But to my surprise I find out that loops using send~ and receive~ are. So does a send~-receive~ pair always implicitly have a one-block latency??? Not always, but always when you do a loop. When you don't do a loop, you can order them so they have zero latency using patchcords/subpatches. So my question is which of these is true: A) there is always a one-block latency between a s~ and a corresponding r~ No. B) there _can_ be a latency, depending on the execution order Pd choses, and you can't know whether there will or won't be. Yes, there can be a latency, but you can make sure there is none by sorting manually using subpatches/patchcords, or you can make sure Pd introduces latency by doing a DSP loop. If you try both at the same time, you get an error message - the famous DSP loop detected. C) there _can_ be a latency, but if there is no dsp loop on the graph, then you can be sure there won't be any avoidable latency due to execution order. I'm not sure I understand this sentence, but if you don't have loops, you can avoid latency between s~/r~, yes, by sorting. Does anybody know the answer? http://crca.ucsd.edu/~msp/techniques/latest/book-html/node120.htmlhttp://crca.ucsd.edu/%7Emsp/techniques/latest/book-html/node120.htmland following. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Vilson Vieira vil...@void.cc ((( http://automata.cc ))) ((( http://musa.cc ))) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] External to get boxes' informations
Guys, is there any object (or any way to create an external object) to get informations about other objects on the patch at the moment (for example, the number of inlets/outlets of one object, it's state (number, symbol, ...) and other things)? Thanks! -- Vilson Vieira vil...@void.cc ((( http://automata.cc ))) ((( http://musa.cc ))) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Control-rate computations in the Signal domain (was Re: Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?)
On Sun, Apr 18, 2010 at 2:47 PM, Frank Barknecht f...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_video v4l
On Mon, 19 Apr 2010, IOhannes m zmoelnig wrote: FFMPEG support has been dropped totally since at least 0.92. the way to go is to use gmerlin_avdec (and i'm actually surprised that you don't) What happened with FFMPEG support ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pix_opencv error
sorry for bothering, but i dont know, where to ask, and i spend all my possibilities with google and testing. i succesfully compiled pix_opencv, lot of objects is working well, but the most important objects for optical flow instantly quit pd with this output in terminal: v4l2: VIDIOC_S_FMT: Invalid argument OpenCV ERROR: Sizes of input arguments do not match () in function cvCalcOpticalFlowBM, cvoptflowbm.cpp(592) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... pd_gui: pd process exited it happens with pix_opencv_of_bm and pix_opencv_of_lk. v4l2: VIDIOC_S_FMT: Invalid argument is written everytime i use webcam, whis is perfectly working - so i dont know, if there is some relationship between this errors.. everything on my ubuntu karmic amd64, and succesfully compiled Pd version 0.42.5, and gem ver: 0.92.2 i will be very lucky if somebody has a clue, whats going on. thanks, kubriel ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_opencv error
kubriel wrote: sorry for bothering, but i dont know, where to ask, and i spend all my possibilities with google and testing. i succesfully compiled pix_opencv, lot of objects is working well, but the most important objects for optical flow instantly quit pd with this output in terminal: v4l2: VIDIOC_S_FMT: Invalid argument OpenCV ERROR: Sizes of input arguments do not match () in function cvCalcOpticalFlowBM, cvoptflowbm.cpp(592) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... called from cvUnregisterType, cxpersistence.cpp(4933) Terminating the application... pd_gui: pd process exited it happens with pix_opencv_of_bm and pix_opencv_of_lk. v4l2: VIDIOC_S_FMT: Invalid argument is written everytime i use webcam, whis is perfectly working - so i dont know, if there is some relationship between this errors.. everything on my ubuntu karmic amd64, and succesfully compiled Pd version 0.42.5, and gem ver: 0.92.2 i will be very lucky if somebody has a clue, whats going on. thanks, kubriel ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list salam, this opencv objects only work well with an opencv from the SVN masalama, sevy ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_video v4l
I'm not completely clear on what gmerlin is, but I believe ffmpeg is an underlying component: http://gmerlin.sourceforge.net/avdec_frame.html So if you compile with gmerlin support, you get a whole mess of decoding options. -martin On Mon, 2010-04-19 at 15:56 -0400, Mathieu Bouchard wrote: On Mon, 19 Apr 2010, IOhannes m zmoelnig wrote: FFMPEG support has been dropped totally since at least 0.92. the way to go is to use gmerlin_avdec (and i'm actually surprised that you don't) What happened with FFMPEG support ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] tables in 64bit puredata
On 2010-04-18 22:05, august wrote: I just built pd 0.41.4 extended and can see that in all of the sampler i seems like you really should to try to update to the newest versions of everything. hmm. it is hard to know what is the right pd to download. Can someone recommend a version, era, or branch that works on ubuntu karmic? * I tried Pd-0.41.4-extended, but it has problems with tables (64bit issue) * I tried pd-0.42-5.src.tar.gz, and the table issue is gone, but the sound is completely unreliable with ubuntu's pulseaudio setup. Pd-0.41.4-extended doesn't have this problem. * I also tried pd-2010-04-15-linux-ubuntu-karmic-i386-i686.tar.bz2 but it does not build. I like very much how pd-extended looks with the toned patch cords and pleasant colors/fonts...and would love to have a version of that that doesn't have the table issue under 64bit...and the also the audio works with pulseaudio. any help is much appreciated. thanks -august. PS: I am looking forward to using the new Gem with gmerlin-avdec bindings, but will have to get to that later. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Hey Frank, Frank Barknecht wrote: Hi, On Mon, Apr 19, 2010 at 09:21:35AM +0200, Frank Barknecht wrote: On Sun, Apr 18, 2010 at 11:42:45AM -0400, Mike Moser-Booth wrote: Frank, I was looking at your comparison patch and noticed you took the [+~ 2] out. The reason I put this in is because [wrap~] converts 0 to 1, so if you reset the phase to 0 you'll end up starting at the end instead of the beginning. Yeah, that's a nasty old bug of wrap~. Miller, when can we get a fix? :) I simplified it away here just to concentrate on the other aspect. Btw.: vanilla's [wrap] in Pd can be used to replace the modf-expr you use after the phase inlet - [wrap] for messages is even correct for 0. :) Oh, and I hope you don't mind, but I added a simplified, expr-less version to the rj library as s_vphasor as attached (giving you credit). I am totally okay with this! Thanks. :-) There I added the 2 to the phase value sent into the vline~ to save on signal addition object - iDevices are slow. :) Even better. I wasn't sure about vanilla's [wrap]. I'm using extended, and it uses zexy's instead. I wanted to make sure this worked in both vanilla and extended, and since you can't do [vanilla/wrap] I just made it with [expr]. But I guess with no arguments they work the same. Good to know, thanks. .mmb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
