Re: [PD] Http request
yes i tried this already before, looks pretty advanced but alas!! not so much on linux .. it doesn't implement video... maybe it's really good for osx, seems their native platform jim wrote: you could also take a look at Lily http://code.google.com/p/lilyapp/ Thanks Marco, I had never seen Lily before. It looks great and easy to use if you know PD. Looks like development on it has slowed down which is too bad but super useful as it is now. Thanks again!! Jim I'm using php sockets to connect web to pd. Using TCP or UDP, you can send values that are sent via GET or POST. check fsockopen and fwrite :) hope to release soon a patch for php and pd to make it fun - ignacio aguirre Marco ___ 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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Http request
> you could also take a look at Lily http://code.google.com/p/lilyapp/ Thanks Marco, I had never seen Lily before. It looks great and easy to use if you know PD. Looks like development on it has slowed down which is too bad but super useful as it is now. Thanks again!! Jim > > > I'm using php sockets to connect web to pd. Using TCP or UDP, > you can send > values that are sent via GET or POST. > > check fsockopen and fwrite :) > > > hope to release soon a patch for php and pd to make it fun > > > - ignacio aguirre > > Marco > ___ > 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] [list] output
--- On Sun, 2/7/10, Frank Barknecht wrote: > From: Frank Barknecht > Subject: Re: [PD] [list] output > To: pd-list@iem.at > Date: Sunday, February 7, 2010, 12:48 PM > Hallo, > Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote: > > > A list with one pointer element will trick [route]: > > > > [traverse some-canvas, bang( > > | > > [pointer] > > | > > [list append] > > | > > [route symbol] > > Is this crasher bug already reported on Sourceforge? You > can crash Pd without > the [list append] here, btw. and also by replaceing the > [print] with a [set > $1(--->[ ( message box construction. > > Anyway to "route" pointers one usually uses the [pointer] > object. For pointers > it's useful to know what type of [struct] they belong to, > so something like > [pointer event time score] will dispatch your event, time > and score pointers > accordingly through their respective inlets. I've never actually used [route] with a pointer in practice. It could be useful in teaching, however, to show how the standard messages are routed according to their selector (as far as I can tell, pointer messages have the selector "pointer", right?). In Chapter 2.9.1, the Pd manual states: 'The pointer data type is also integrated into pipe-fitting objects such as "pack", "unpack", and "route".' So it seems like [route] should handle pointers just as it does other the other "standard" message types. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
> >> It would be nice though, to know also on a theoretical level. Which one >> should be more expensive and (maybe) why. > > I was just taking a look at d_ctl.c from source. It looks like > snapshot~ is cheapest because it's not trying to get any specific > sample from the block. vsnapshot~ gets the logical time on every DSP > tick and copies each passing block to memory. Then, upon receiving a > bang, it gets the time elapsed since that last DSP tick. Based on > that time, it makes an index into the copied block to bring up the > exact sample that was flying by when you banged it (at least, as close > as possible). So that's a clock call and a block copy every 1.45 ms > with normal 64 sample block size, plus the arithmetic necessary to > compute the index into the block. By using [block~ 1], you're > increasing the number of clock calls, and the arithmetic for finding > an index is kind of wasted since the block is only one sample long. > Maybe it would be best to avoid [block~] and bang vsnapshot~ with a > metro set to 1/44.1 ms. You'd at least be reducing the number of > clock_getlogicaltime() calls. > > env~ is more or less just summing and squaring each block (very > cheap), then calling a powtodb conversion function. You've got it set > to process a block of 4096 samples every 2048 samples. So that's > taking advantage of the more efficient block processing strategy. > Also, you should know that the result of [env~] is something akin to a low-pass filter; the "speed limiting" from the original patch might be done more efficiently by squaring the signal and sending it through a (probably aggressive) low-pass filter before sending it to vsnapshot -- in that case it's possible that regular old snapshot with a larger [block~] size might work just as well, since you'll be sending a signal that doesn't change as quickly. You also need to take into account that doing message-level computations every sample might be fairly inefficient in general, and this is not something that [env~] is usually doing. Further, updating a vu gui every sample will probably be almost ridiculously inefficient -- try comparing the two setups with and without the vu connected (it may be that you have already taken care of this in the "speed limiting" and are not actually updating it every sample after all). Either way, it's always good to test efficiency with and without the guis, since the gui operations add an extra layer. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM]framebuffer vs pix_multiimage
hello, framebuffer are innocent here : the patch does not work better without framebuffer. it look like you can have only 1 pix_multiimage for a single gemhead. as a workaround, i suggest to use 2 gemhead. There is an example somwhere how to use multiples gemhead in a framebuffer. Cyrille colet.patr...@free.fr a écrit : hello, attached doesn't need externals , just Gem, as the same problem as described before, only one pix_multiimage can do it's job in a framebuffer, why? patko ___ 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] [GEM]framebuffer vs pix_multiimage
hello, attached doesn't need externals , just Gem, as the same problem as described before, only one pix_multiimage can do it's job in a framebuffer, why? patko#N canvas 619 4 654 539 10; #X obj 16 22 cnv 15 100 60 empty empty empty 20 12 0 14 -195568 -66577 0; #N canvas 0 0 450 300 gemwin 0; #X obj 132 136 gemwin; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 132 112 create \, 1; #X msg 198 112 destroy; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 6 0; #X connect 3 1 5 0; #X connect 3 1 7 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X restore 21 61 pd gemwin; #X msg 21 42 destroy; #X text 17 21 Create window:; #X obj 399 328 pix_texture; #X obj 399 351 square; #X obj 399 304 pix_multiimage; #X msg 399 213 open myFiles*.tif 5; #X floatatom 476 278 3 0 5 0 image# - -; #X obj 265 28 gemhead 10; #X obj 510 94 gemhead 20; #X obj 510 126 pix_texture; #X obj 510 179 rectangle 4 3; #X obj 265 87 translateXYZ 0 0 -4; #X obj 265 113 t a a a; #X obj 332 424 pix_texture; #X obj 332 447 square; #X obj 332 400 pix_multiimage; #X floatatom 410 375 3 0 5 0 image# - -; #X msg 154 470 open C:/Users/patko/Documents/data/formatA4/visu/anim-A4/Drum*.tif 5; #X obj 246 269 translateXYZ -2 0 0; #X obj 304 163 translateXYZ 2 0 0; #X obj 304 136 separator; #X obj 285 238 separator; #X text 499 272 <--- work; #X text 433 372 <--- doesn't work; #N canvas 0 0 450 300 framebuffer 1; #X obj 83 41 inlet; #X obj 83 92 gemframebuffer; #X obj 64 220 outlet; #X obj 228 233 outlet; #X msg 135 34 dim 512 512; #X obj 163 -8 loadbang; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 1 3 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X restore 265 62 pd framebuffer; #X connect 1 0 2 0; #X connect 2 0 1 0; #X connect 4 0 5 0; #X connect 6 0 4 0; #X connect 7 0 6 0; #X connect 8 0 6 1; #X connect 9 0 26 0; #X connect 10 0 11 0; #X connect 11 0 12 0; #X connect 13 0 14 0; #X connect 14 1 23 0; #X connect 14 2 22 0; #X connect 15 0 16 0; #X connect 17 0 15 0; #X connect 18 0 17 1; #X connect 19 0 17 0; #X connect 19 0 6 0; #X connect 20 0 17 0; #X connect 21 0 6 0; #X connect 22 0 21 0; #X connect 23 0 20 0; #X connect 26 0 13 0; #X connect 26 1 11 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Ardour + Jack GUI patch
Hello, I've made a patch to control ardour and jack directly from Pd. The patch works through osc and [shell], and was made in jaunty. I didn't test it on macOs, but it should work, I think. Just unpack the file somewhere (don't loose the icon folder) and tell me about it. Everything else should be clear in the patch. I would also apreciate a screen capture of a macOs version, to see if the GUI looks good enough. Best, João Pais -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jm...@gmx.net | skype: jmmmpjmmmp ardour-gui.tar.gz Description: GNU Zip compressed data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Http request
you could also take a look at Lily http://code.google.com/p/lilyapp/ > I'm using php sockets to connect web to pd. Using TCP or UDP, you can send > values that are sent via GET or POST. > > check fsockopen and fwrite :) > > > hope to release soon a patch for php and pd to make it fun > > > - ignacio aguirre > Marco ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [list] output
Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote: > A list with one pointer element will trick [route]: > > [traverse some-canvas, bang( > | > [pointer] > | > [list append] > | > [route symbol] Is this crasher bug already reported on Sourceforge? You can crash Pd without the [list append] here, btw. and also by replaceing the [print] with a [set $1(--->[ ( message box construction. Anyway to "route" pointers one usually uses the [pointer] object. For pointers it's useful to know what type of [struct] they belong to, so something like [pointer event time score] will dispatch your event, time and score pointers accordingly through their respective inlets. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [list] output
Jonathan Wilkes escribió: Now try hooking that symbol outlet up to some object like [print], or a symbol box, save all your important patches, and click the message box... I kind of guess what's gonna happen :) -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] latency solutions... and then some
hi, I totally agree with Michal about the OS. I haven't tried MacOS but i know for sure that XP can't beat a good rt Linux kernel. That being said, I personnally spent about 6 months trying various Linux distros before i found a good match with my hardware. Although I have had very little luck with Ubuntu, you should probably start with this OS, and then try other options (Pure:Dyne, Fedora with Planet CCRMA, 64 Studio...). Most of these come with a live version which you can try without installing anything. Here's what I'd advise you to do everytime you install a new distro: 1) Install it or run the live cd (of course) 2) Run QJAckCtl or Jack Control to try the audio server first (google it to find the proper settings for realtime use). If you don't get a decent latency without any Xruns (shouldn't be higher than 6 ms on your hardware), then you can either try another distro OR install the rt-kernel for your OS (in case the standard install did not include it). 3) Once you are sure that JACK is working fine with a low latency and no Xruns, you can try your Pd patches. Hope this helps. Pierre 2010/2/7 Michal Seta > On Wed, Feb 3, 2010 at 9:22 PM, Jeffrey Concepcion > wrote: > > Thanks for the suggestions, i'll deffinately be looking into your > > suggestions (i'm not familiar with some of the terms ). For now i must > deal > > with what i have at home, which is an acer netbook w/ windows Xp @ 1.6 > GHz, > > 1GB RAM btw! No external soundcard as of yet. i should get (in theory) a > > similar result to Pierre's so i'll be trying that approach for now > > Don't be fooled by the processor Hz count. First of all, different > operating systems deal with system resources in different ways. > Whether you can get reliable, low latency performance from XP on a > netbook is beyond my experience but AFAIK, Windows and MacOS are not > as transparent and easily tuned as *NIX are. I still use very lean > and small window manager when I want to be sure to have clean audio > without dropouts in low latency. > > Beyond that, the hardware performance has a lot to do with latency. > The cheap audio interfaces that are bundled with today's computers, > especially netbooks, are not necessarily useful for for real-time, low > latency work. They will usually require a relatively large buffers to > convert analog<->digital without hick-ups and that will add up to the > buffers needed by the audio driver, pd, CPU's workload etc. > > That said, you may want to look at this thread (and/or google similar): > http://linuxaudio.org/mailarchive/lau/2009/5/6/154392 > > There are some people using linux on netbooks for realtime processing > and therefore it is possible. YYMV, depending on your needs, your > perception of "real time" and the hardware/software configuration. > Note, that if you want to give linux a try you can grab pure:dyne or > ubuntu and install it on a USB stick or HD and take it from there > until you decide which OS works best for your particular needs. > pure:dyne will give you immediate access to media applications > (including pd) and realtime kernel. > > I am actually working these days with an Acer netbook (aspire one) > running ubuntu 9.10. Using a rt kernel improves audio performance > somewhat. I just used a stock rt build, I could probably roll my own, > tuned to my liking but I think I am getting too old for that :). > However, the hardware cannot really keep up with very low latencies. > My focus is not on getting lowest possible latency right now so I do > not have any better advice at the moment. > > half a cent from yours truly. > > ./MiS > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
hello! By using [block~ 1], you're > increasing the number of clock calls, and the arithmetic for finding > an index is kind of wasted since the block is only one sample long. > Maybe it would be best to avoid [block~] and bang vsnapshot~ with a > metro set to 1/44.1 ms. You'd at least be reducing the number of > clock_getlogicaltime() calls. > Thanks for that. I had no idea that there would be a difference between the two. All this being said, the CPU load difference between these setups is > basically nothing on my 2.5GHz MacBook Pro. I guess the differences > would start to emerge if you compared dozens of instances of each. > Yeah, in my tests i got notable differences from about 512 to 1024 instances. > > Hope that helps... > Not only did it help, it made my day. I hope the time you spend peaking in the code will be useful to you and others. Thank you -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
