[PD] Infrared tracking Mac OS
Hello, I am looking for an affordable IR camera for use on Mac OS with passive markers : has anyone a reference to recommand ? (Im an IR newbee) Is there somewhere a Mac driver for the V120 slim by Optitrack ? Thanks a lot ! JmAdrien ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI and DSP
Hmm, thanks ! Sorry i was just wondering wether i had to erase all my signal driven sliders deep in subpatches :)) ...got some info thus, thanks, i love this list JmAdrien Le 8 févr. 2012 à 21:33, Ivica Ico Bukvic a écrit : > > > Mathieu Bouchard wrote: > >> Le 2012-02-08 à 11:55:00, Jonathan Wilkes a écrit : >> >>> While technically correct that's misleading because there's a lot of >>> stuff happening on the 'pd' side that a reasonable person would >> assume >>> to be handled on the 'pd-gui' side. Well, more than that-- there's >>> stuff happening on the 'pd' side that doesn't need to happen at all, >> but >>> it can use massive amounts of CPU and consequently a reasonable >> person >>> gets dropouts when moving an array that has only 100 points visible >> and >>> erroneously thinks, "Wow, I get dropouts just moving some polygons >>> around on the screen? Tk stinks!" > > Or you could simply use pd-l2ork and a move arrays and other complex > graphical user interface objects using tags and never worry about that > problem again. > > >> Besides, you could save some cpu, ram and bandwidth if all those array >> floats were hex-encoded instead of dec-encoded. Don't use "%g" nor "%d" >> >> when you can use "%x" and similar... especially fixed-width %x such as >> "%04x". >> >> If Tcl had fast base64 support (like Perl/Ruby), the difference would >> be >> even bigger. And it would bigger with the ability to send binary data >> (which can't happen now because "}" counts as end-of-block). >> >> __ >> | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, >> QC___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > > Ivica Ico Bukvic, D.M.A > Composition, Music Technology > Director, DISIS Interactive Sound & Intermedia Studio > Director, L2Ork Linux Laptop Orchestra > Assistant Director, CCTAD > Virginia Tech > Department of Music > Blacksburg, VA 24061-0240 > (540) 231-6139 > (540) 231-5034 (fax) > disis.music.vt.edu > l2ork.music.vt.edu > ico.bukvic.net > > ___ > 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] Structures & lists
Great, thanks. JmA Le 30 déc. 2011 à 16:17, Jonathan Wilkes a écrit : > > > > > - Original Message ----- >> From: Jma/celeonet >> To: "Pd-list@iem.at" >> Cc: >> Sent: Friday, December 30, 2011 6:14 AM >> Subject: [PD] Structures & lists >> >> Hello, >> basic : the manual about data structures and lists seems out of date ... >> what would be the straighforward way to deal with (point to) many lists of >> different lengths (matrices inappropriate) without declaring lengths at >> first ? >> (using float arrays in data structures requires prior length declaration , >> correct ?) > > You can use [setsize] to change the length at any time after the containing > scalar gets created. > > -Jonathan > >> Thanks >> JmAdrien >> ___ >> 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
[PD] Structures & lists
Hello, basic : the manual about data structures and lists seems out of date ... what would be the straighforward way to deal with (point to) many lists of different lengths (matrices inappropriate) without declaring lengths at first ? (using float arrays in data structures requires prior length declaration , correct ?) Thanks JmAdrien ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Soundfiler / ram
Hi list Probably has been discussed million times : how is it possible to open / close large number of sound samples dynamically in arrays to keep ram low ? (all samples not used at the same time). Set to zero, resize to zero and reload ? Any clear command ? Any clean and up-to-date way (Mac Os) ? Thanks JmAdrien ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] PS3 eye, Pix_video, low latency
Iohannes Thanks a lot for the bright info. 1 frame versus 10 frames latency was meant as 40ms versus 500ms latency at 25fps. 40ms is already long for musical instrument real time feeback, and 500ms is the huge latency of the wiener philharmoniker ! (conductor speaking). Would you recommand a specific analog grabber card that works fine with Mac ? JmAdrien Le 14 oct. 2010 à 10:45, IOhannes m zmoelnig a écrit : > On 2010-10-14 10:09, Jean-Marie Adrien wrote: >> Hi chris >> Im glad you jumped in. Concerning the topic would the following theory >> make sense ? >> >> it seems that video capture and video tracking do not adress the same >> purposes : >> >> - video capture allows 10 frames of latency to ensure that frame >> transfer is correct to the machine for later uses (post production, >> montage). This is the major usage now of video, because of DV camescopes >> and so on. >> >> - whereas video tracking requires 1 frame of latency maximum, to produce > > which of course is not true at all. > it's like saying that audio capture for use with real time processing > requires a latency of 1 sample. > >> real time responses. This is a emergent need, that seems to be covered >> by other softwares. > > 1 frame can be quite long, whereas 10 frames can be way shorter. > >> >> Im trying to crawl to the second point. >> For instance, in pidip, it seems that there is a IE1394 object that >> processes DV type signals with a long latency, like pix_video does in >> GEM, and there is another object pdp_DC1394, that would be quicker, and >> could thus interface DC uncompressed industrial cameras without sticking >> them into the DVlike process, on Linux at least. >> >> Does this make sense ? > > in Gem you don't have different objects for different grabbing APIs. > e.g. you would use [pix_video] for grabbing from your dv1394 consumer > camera, from your analog capture card and from IDC. > >> Any DC pix_video object in GEM on MAC with 1 frame of latency ? >> DC1394 available on MAC or only on LINUX ? > > on OSX, Gem uses QuickTime for about everything concerned with image > acquisition (thus all the problems with OSX10.6). > so on OSX this means: if QuickTime provides support for IIDC, then you > get IIDC in Gem; if QuickTime does not support GiG-E, then you don't > have GiG-E in Gem > > on linux there is no grand unified image acquisition API, so there are a > number of different backends for the various APIs (thus: Gem has > explicit support for GiG-E and IIDC cameras on linux; it only has > implicit support (if at all) for those cameras on OSX) > > > and finally: the old rule-of-thumb was, that you get the best latency > with analog grabber cards you put into your PCI/express slot. > > fgmsdr > IOhannes > > ___ > 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
