Re: [PD] compiling pd on fedora 9
Jaime Oliver wrote: Hello I´m compiling pd on fedora 9 in a core 2 duo machine, doing the following yum install tk-devel and pd doesn´t work correctly, (for example ctrl-n and ctrl-q don´t work) i guess(!) this is a problem withthe tcl/tk version you are using. try using tck/tk-8.4 and see if it goes away (if available on fc9) alternatively try using an uptodate version of Pd (don't know whether there have been some fixes; but i also don't know whether you are trying to run Pd-0.37 or 0.52; and whether this is about plain Pd (aka Pd-vanilla) or some otherwise patched version (like Pd-extended) fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 2 questions for hans about the upcoming 0.40 extended release
hans, my library is not externals, its a library of abstractions. lots of building blocks for drums, synths, effects and samplers. i'd really like to include it in pd-extended,a s it contains a lot of stuff that would be very useful for people making music with pd. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Ubuntu Studio and other media-related distros
Derek, wasn't it you who posted a link to gentoo is for ricers site on this list years ago? :) (site seems to be down now) I used to use gentoo because, for years, I had a pII 500mhz laptop with a max of 128mb of ram. I thought with gentoo, I would be able to slim the memory usage down and max out the amount of mmx and sse instructions used in code overall. And, I remember it running really smoothly. At one point, however, I got sick of compiling X for 2 days straight every time that needed to be upgraded. I also spent 3 or 4 days trying to get it to work with a wireless card with which I was stuck. At that point, I installed ubuntu 5.10 (i think. this was 2004).In my experience, ubuntu has been good at recognizing the most kinds of general use hardware (wireless cards, bluetooth, openGL, usb cards and media readers etc) so long as you use their gnome environment. It also has a very large selection of packages. I stuck to the apt-get'able packages and never had a single problem in the last 4 years. I spent considerably less time futzing around with various options...and learned to live with what was there. I was also able to mount and use normal non-journaled HFS+ drives, although only did that on one or two occasions when I was forced to 'think different'. I now have a laptop with pIII 600mhz and 256mb of ram with Ubuntu Hardy Heron (the latest).If you have less than a 1Gig of RAM, I would seriously not recommend using this distro. It was an amazing difference in memory usage from the last distro version to this one. I have stopped all unnecessary daemons and had to stop using the gnome window manager and now use fluxbox...and it will still swap like crazy every now and then. I'm actually considering switching back to gentoo. -august. Hey gang, In a search for distraction from the project I'm really supposed to be working on, I decided to update my (until now stable but very outdated) Gentoo media editing machine. A couple days of circular package blocks, missing dependencies and vanishing libraries later, I'm really curious why I once decided it was a good idea to compile everything myself ;-) (Note to Gentooers: emerge --update --deep world once a month, or get the thing stable and never touch it again! If you wait too long, and your current packages go out of Portage, it can be hellish!). So if and when this machine is hosed, what would be a good distro to put on it? I don't feel much like the super-hacker I was a four or five years ago when I got into Gentoo, but I like a distro that I can configure to be extremely minimal and transparent. And what is absolutely necessary is that it has well-configured versions of all the audio softs that I depend on, such as Ardour (w/ VST support!), Jamin, LADSPAs, JACK, etc. Realtime/prempt kernel = A-OK. Ability to use PD-Extended is of course a plus, and also the ability to mount HFS+ drives without destroying them (as Ubuntu has done to me in the past) is also necessary. I looked at Ubuntu Studio, but I wanted to ask who actually uses it. From the page it seems like maybe it's not well-maintained, and that's another requirement for me after messing around with different audio-related overlays for Portage that eventually get abandoned. If Ubuntu Studio isn't the right one, can anyone suggest another option? My last criteria is that it has a coherent user community and excellent docs (strongest point of Gentoo, and from what I recall a weak point of straight Debian, IMHO). thx + best! D. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Ubuntu Studio and other media-related distros
On Mon, 14 Jul 2008, august wrote: wasn't it you who posted a link to gentoo is for ricers site on this list years ago? :) (site seems to be down now) It was reestablished and renamed to http://funroll-loops.info/ _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Ubuntu Studio and other media-related distros
It wasn't me that originally posted it I think. Can't remember, actually... But it did get sent to me by several well-meaning people. And I always wondered what a funroll tastes like maybe shrimpy? d. Mathieu Bouchard wrote: On Mon, 14 Jul 2008, august wrote: wasn't it you who posted a link to gentoo is for ricers site on this list years ago? :) (site seems to be down now) It was reestablished and renamed to http://funroll-loops.info/ -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 93: Into the impossible ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pd on fedora 9
it's pd 0.41-4 Gem 0.91 cvs, in the case of pd i tried tcl/tk 8.4 and 8.5, the strange thing is that everything worked using the -nosound flag, except of course sound... in the case of gem i got all sorts of weird errors, but i didn't document them well because i needed to get everything up and running fast, which fc8 allowed me to do with no errors whatsoever. thanks again, J On Mon, Jul 14, 2008 at 2:15 AM, IOhannes m zmoelnig [EMAIL PROTECTED] wrote: Jaime Oliver wrote: Hello I´m compiling pd on fedora 9 in a core 2 duo machine, doing the following yum install tk-devel and pd doesn´t work correctly, (for example ctrl-n and ctrl-q don´t work) i guess(!) this is a problem withthe tcl/tk version you are using. try using tck/tk-8.4 and see if it goes away (if available on fc9) alternatively try using an uptodate version of Pd (don't know whether there have been some fixes; but i also don't know whether you are trying to run Pd-0.37 or 0.52; and whether this is about plain Pd (aka Pd-vanilla) or some otherwise patched version (like Pd-extended) fgmasdr IOhannes -- Jaime E Oliver LR [EMAIL PROTECTED] www.realidadvisual.org/jaimeoliver www-crca.ucsd.edu/ www.realidadvisual.org 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to avoid (most/many/some) readsf~ dropouts
Matt Barber wrote: Date: Sat, 12 Jul 2008 13:56:54 +0200 From: Damian Stewart [EMAIL PROTECTED] Subject: [PD] how to avoid (most/many/some) readsf~ dropouts To: PD-List pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed hey, one thing i've noticed with readsf~ using it in my own live-performance sets is that doing this [symbol blahblahblah.aif] | [open $1, bang( | [readsf~] sometimes causes dropouts. but if you go [symbol blahblahblah.aif] | [t b a] | \ | \ [del 50][open $1( | __/ |/ [readsf~] then you remove (all/many/some) of the dropouts. i haven't extensively tested this, but anecdotal evidence seems to suggest that it works. I think this is because the former method may not let the buffer fill before you start playing. I usually don't like the second method, either, because of the 50 ms delay (which isn't much, but I'm finicky about that kind of thing). Depending on the setup, I usually prefer something like the following: [loadbang] | | [r open] | / [open file.ext ( [0 ( [1 (| | \__ | [t b f ]_\ | | [readsf~ ] [s open]| [s open] I hope things line up okay there... at any rate, you load the buffer at the beginning, or if your piece/performance has a master clock, a couple of seconds before you need it. Then for rehearsal, if you need to stop the file you can use a trigger to reload it immediately. Also, if you need to play the file again, you can send the open message when the file is done playing. This makes the whole process a little more front-loaded, so that the soundfile is always open no matter what. My intuition is that it's more robust than other schemes I've tried. I haven't tested it very hard, though, as I've only ever needed up to 9-10 simultaneous 96k files... maybe it would be neat to find some old, slow hardware to see how far different methods can be pushed. =o) More advanced for stopping would be something that fades out the sound with a [line~] over 20 ms or so, and then sends the stop message to [readsf~] after a comparable delay -- that way you won't get an annoying transient upon stop -- same deal with a fade in if you are starting in the middle of the soundfile, but without the delay. I usually wrap the whole thing in an abstraction -- I keep three or four different ones lying around with different properties for different situations, and I'm happy to share with anyone who might find them useful. Thanks, Matt Matt and Damian, In working on a recent piece for marimba and 8-channel computer (24bit/88.2kHz), I consistently experienced intermittent clicks and audio dropouts -- even on high-end hardware running GNU/Linux. Increasing the readsf buffer and the time between file load (open) and playback (readsf) helped some, but not enough. Since the premiere last month, I've been rebuilding the abstractions for better efficiency, but am still not happy with the results -- and before the soloist can safely tour the piece, I need to work out a more robust solution. I've attached the latest version of my basic playback (w/fade) patch for suggestions/comments... Unfortunately, your ascii patch didn't line up, would you mind posting an example patch that shows your method? Best, G -- http://www.orpheusmediaresearch.com/ http://www.gregwilder.com/ +1 215-764-6057 (office) +1 215-205-2893 (cell) #N canvas 65 224 902 519 10; #X msg 86 198 1; #X msg 129 198 0; #X obj 175 128 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 129 178 r stop; #X obj 86 105 + 6; #X floatatom 86 125 5 0 0 0 - - -; #X obj 175 373 *~; #X obj 383 147 loadbang; #X obj 441 147 r reset_vol; #X text 401 127 master volume; #X obj 86 84 random 50; #X obj 243 373 *~; #X obj 174 395 throw~ ch1; #X obj 242 395 throw~ ch2; #X obj 312 373 *~; #X obj 380 373 *~; #X obj 311 395 throw~ ch3; #X obj 379 395 throw~ ch4; #X obj 574 145 delay 500; #X msg 383 168 100; #X msg 441 168 100; #X obj 667 241 \$1; #X obj 395 351 vline~; #X obj 328 351 vline~; #X obj 258 351 vline~; #X obj 191 351 vline~; #X obj 86 143 delay; #X obj 448 373 *~; #X obj 516 373 *~; #X obj 584 373 *~; #X obj 574 224 dbtorms; #X floatatom 574 185 5 0 0 0 - - -; #X obj 574 203 * 1; #X obj 652 373 *~; #X obj 667 351 vline~; #X obj 600 351 vline~; #X obj 531 351 vline~; #X obj 464 351 vline~; #X text 599 204 (vol%); #X obj 447 395 throw~ ch5; #X obj 515 395 throw~ ch6; #X obj 583 395 throw~ ch7; #X obj 651 395 throw~ ch8; #X msg 175 151 open 8ch_acheron_blasts.wav; #X msg 574 165 0; #X msg 667 262 \$1 3500; #X obj 667 283 unpack f f; #X obj 724 304 + 1025; #X text 719 262 fade time in ms; #X floatatom 724 325 5 0 0 0 - - -; #X obj 441 189 delay; #X obj 441 209 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144 -1 -1; #X obj 175 67 r acheron_play; #X
Re: [PD] shell problem on osx
Luke Iannini wrote: On Thu, Jul 10, 2008 at 11:39 AM, marius schebella [EMAIL PROTECTED] wrote: Hi, when I use the shell object on osx, I get an error after every command I send to it. The application pd quit unexpectedly. anybody know why and how to get rid of that? I found a glimmer but never had the chops to implement it: http://sourceforge.net/tracker/index.php?func=detailaid=1825056group_id=55736atid=478070 (see the comments) ok, so this is a mac OS X 10.5 problem... the exec*() thing could be the solution, but I don't know how to fix that. marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] unclamped pix_subtract?
I'm trying to implement a background subtractor using pix_buffer to store the reference frame, and then subtracting it from the live video input, then using that subtraction as an alpha mask for the live video. The problem is that pix_subtract clamps the output at 0, but I need it to not clamp, and then I can take the absolute value. Is there a way to do unclamped subtraction of pix objects in GEM? thanks, spencer ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] unclamped pix_subtract?
pix_diff gives the absolute value of the right image subtracted from the left. On Mon, Jul 14, 2008 at 4:08 PM, Spencer Russell [EMAIL PROTECTED] wrote: I'm trying to implement a background subtractor using pix_buffer to store the reference frame, and then subtracting it from the live video input, then using that subtraction as an alpha mask for the live video. The problem is that pix_subtract clamps the output at 0, but I need it to not clamp, and then I can take the absolute value. Is there a way to do unclamped subtraction of pix objects in GEM? thanks, spencer ___ 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] how to avoid (most/many/some) readsf~ dropouts
Damian Stewart wrote: Dr. Greg Wilder wrote: I've attached the latest version of my basic playback (w/fade) patch for suggestions/comments... Unfortunately, your ascii patch didn't line up, would you mind posting an example patch that shows your method? first thing i notice when i open it up is this: on the left hand side, you've got a 'random 50' and a '+ 6', going into the delay. this means the minimum delay will be 6ms, which i doubt is long enough. why the random? why not just hardcode 50ms in there? or at least go 'random 30' and '+ 40' or something. hth, d Indeed. Sorry about that -- I pulled the example from a larger abstraction which added another 2000 to the delay amount, but the +2000 didn't get copied. At any rate, the randomized load time is there to prevent the patch triggering multiple files at exactly the same moment. My understanding is that PD's execution order doesn't allow simultaneous events to collide, however I have found I get better results when I leave a few extra milliseconds between simultaneous triggers. Perhaps it would be smarter to use a hard coded [t b b b]? Also, I should point out that the dropouts I experienced happened at different points during playback. Sometimes near the beginning, other times 50 seconds in... G ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to avoid (most/many/some) readsf~ dropouts
i just found that removing the [wavinfo] external from my patch also helped reduce clicking. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to avoid (most/many/some) readsf~ dropouts
Damian Stewart wrote: Dr. Greg Wilder wrote: I've attached the latest version of my basic playback (w/fade) patch for suggestions/comments... Unfortunately, your ascii patch didn't line up, would you mind posting an example patch that shows your method? first thing i notice when i open it up is this: on the left hand side, you've got a 'random 50' and a '+ 6', going into the delay. this means the minimum delay will be 6ms, which i doubt is long enough. why the random? why not just hardcode 50ms in there? or at least go 'random 30' and '+ 40' or something. hth, d Here's a cleaner version of the example patch -- without the random delay and a larger readsf~ buffer. Still no joy -- even with 92.9 ms latency. I'm beginning to think my system simply isn't fast enough to play more than 10 (or so) channels of 24bit/88.2kHz sound at a time... G -- http://www.orpheusmediaresearch.com/ http://www.gregwilder.com/ +1 215-764-6057 (office) +1 215-205-2893 (cell) #N canvas 311 207 902 479 10; #X msg 86 174 1; #X msg 129 174 0; #X obj 129 154 r stop; #X obj 175 349 *~; #X obj 383 123 loadbang; #X obj 441 123 r reset_vol; #X text 401 103 master volume; #X obj 243 349 *~; #X obj 174 371 throw~ ch1; #X obj 242 371 throw~ ch2; #X obj 312 349 *~; #X obj 380 349 *~; #X obj 311 371 throw~ ch3; #X obj 379 371 throw~ ch4; #X obj 574 121 delay 500; #X msg 383 144 100; #X msg 441 144 100; #X obj 667 217 \$1; #X obj 395 327 vline~; #X obj 328 327 vline~; #X obj 258 327 vline~; #X obj 191 327 vline~; #X obj 448 349 *~; #X obj 516 349 *~; #X obj 584 349 *~; #X obj 574 200 dbtorms; #X floatatom 574 161 5 0 0 0 - - -; #X obj 574 179 * 1; #X obj 652 349 *~; #X obj 667 327 vline~; #X obj 600 327 vline~; #X obj 531 327 vline~; #X obj 464 327 vline~; #X text 599 180 (vol%); #X obj 447 371 throw~ ch5; #X obj 515 371 throw~ ch6; #X obj 583 371 throw~ ch7; #X obj 651 371 throw~ ch8; #X msg 175 127 open 8ch_acheron_blasts.wav; #X msg 574 141 0; #X msg 667 238 \$1 3500; #X obj 667 259 unpack f f; #X obj 724 280 + 1025; #X text 719 238 fade time in ms; #X floatatom 724 301 5 0 0 0 - - -; #X obj 441 165 delay; #X obj 441 185 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144 -1 -1; #X obj 148 55 r acheron_play; #X obj 574 100 r acheron_fade; #X obj 148 76 t b a; #X obj 175 191 readsf~ 8 1e+12; #X obj 148 97 del 1500; #X connect 0 0 50 0; #X connect 1 0 50 0; #X connect 2 0 1 0; #X connect 3 0 8 0; #X connect 4 0 15 0; #X connect 5 0 16 0; #X connect 7 0 9 0; #X connect 10 0 12 0; #X connect 11 0 13 0; #X connect 14 0 39 0; #X connect 15 0 26 0; #X connect 16 0 26 0; #X connect 17 0 40 0; #X connect 18 0 11 1; #X connect 19 0 10 1; #X connect 20 0 7 1; #X connect 21 0 3 1; #X connect 22 0 34 0; #X connect 23 0 35 0; #X connect 24 0 36 0; #X connect 25 0 17 0; #X connect 26 0 27 0; #X connect 27 0 25 0; #X connect 28 0 37 0; #X connect 29 0 28 1; #X connect 30 0 24 1; #X connect 31 0 23 1; #X connect 32 0 22 1; #X connect 38 0 50 0; #X connect 39 0 26 0; #X connect 40 0 18 0; #X connect 40 0 19 0; #X connect 40 0 20 0; #X connect 40 0 21 0; #X connect 40 0 32 0; #X connect 40 0 31 0; #X connect 40 0 30 0; #X connect 40 0 29 0; #X connect 40 0 41 0; #X connect 41 1 42 0; #X connect 42 0 44 0; #X connect 44 0 45 1; #X connect 45 0 16 0; #X connect 45 0 46 0; #X connect 46 0 1 0; #X connect 47 0 49 0; #X connect 48 0 14 0; #X connect 48 0 45 0; #X connect 49 0 51 0; #X connect 49 1 38 0; #X connect 50 0 3 0; #X connect 50 1 7 0; #X connect 50 2 10 0; #X connect 50 3 11 0; #X connect 50 4 22 0; #X connect 50 5 23 0; #X connect 50 6 24 0; #X connect 50 7 28 0; #X connect 51 0 0 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to avoid (most/many/some) readsf~ dropouts
Greg, you may like to experiment with tweaking the disk caches. For linux see here: http://www.linuxdevcenter.com/pub/a/linux/2000/06/29/hdparm.html On Mon, 14 Jul 2008 17:11:02 -0400 Dr. Greg Wilder [EMAIL PROTECTED] wrote: Damian Stewart wrote: Dr. Greg Wilder wrote: I've attached the latest version of my basic playback (w/fade) patch for suggestions/comments... Unfortunately, your ascii patch didn't line up, would you mind posting an example patch that shows your method? first thing i notice when i open it up is this: on the left hand side, you've got a 'random 50' and a '+ 6', going into the delay. this means the minimum delay will be 6ms, which i doubt is long enough. why the random? why not just hardcode 50ms in there? or at least go 'random 30' and '+ 40' or something. hth, d Indeed. Sorry about that -- I pulled the example from a larger abstraction which added another 2000 to the delay amount, but the +2000 didn't get copied. At any rate, the randomized load time is there to prevent the patch triggering multiple files at exactly the same moment. My understanding is that PD's execution order doesn't allow simultaneous events to collide, however I have found I get better results when I leave a few extra milliseconds between simultaneous triggers. Perhaps it would be smarter to use a hard coded [t b b b]? Also, I should point out that the dropouts I experienced happened at different points during playback. Sometimes near the beginning, other times 50 seconds in... G ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Real Time Kernel Debian
Okay after my third attempt and second complete re-install.. does any-one have links, suggestions about installing a real time kernel. I think my main problems are with make oldconfig I can't find the original .conf file to back it up or copy it to the new kernel package. If my install is fresh would I have one? One site suggests downloading the .conf file for my kernel version and copying it into the new kernel package. I have now seen that with ncurses menuconfig I can just use .conf file at that point. Problem with all these Linux Debian How To's there seems to be numerous ways to achieve the same result. I realize that a lot of Pd linux users must have installed a rt kernel and am hoping to find a good ie its worked for some one link to a how to... My next problem comes during make-dpkg -i This seemed to only last a second seems to me it would be a longer process? I do however get a kernel-version .rt in /boot but I am not sure how to edit yaboot.conf to add it to initial boot. On my last attempt it did boot into the rt kernel but the kernel didn't load. kernel panic message saying FS: Cannot open root device hdb1 or unknown block (0,0) kernel panic: not syncing: unable to mount root fs on unknown- block(0,0) I don't really understand doesn't the kernel become part of my original Debian install? ie there is no repartitioning of the hard- drive its just an alternate install. I am assuming this is some problem with yaboot.conf? Any help would be appreciated Dual boot mac Os X Debian/ ppc powerbook g4 Any useful links would be great I used these: http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO http://forums.debian.net/viewtopic.php?t=17035 (suggested make- dpkg command didn't work) http://newbiedoc.sourceforge.net/system/kernel-pkg.html http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html plus a bunch more but these were the main ones. Thanks Ede ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to avoid (most/many/some) readsf~ dropouts
Andy Farnell wrote: Greg, you may like to experiment with tweaking the disk caches. For linux see here: http://www.linuxdevcenter.com/pub/a/linux/2000/06/29/hdparm.html Thanks for the idea, Andy. It seems my stock Studio64 RT kernel is treating my SATA as a SCSI device -- but sdparm only coughs up errors. I'm gonna have to look deeper into this... G ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to avoid (most/many/some) readsf~ dropouts
That would be a very nice object to have: [nosleep]. It probably wouldn't be hard on GNU/Linux. Then you could embed in performance patches. .hc On Jul 12, 2008, at 10:39 PM, hard off wrote: julian! you're a legend!!! that was totally the problem. it totally makes sense too, because when i sent a couple of 'open' messages in a row, i wouldn't get clicks, but if i left it for a while, it would drop out. now i have zero dropouts. awesome. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list If you are not part of the solution, you are part of the problem. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to avoid (most/many/some) readsf~ dropouts
Hey Greg, I threw together a couple of abstractions to show how I usually do it, but I'm not sure it will help with playback of multiple 8-channel files. I've never tried this before, but I wonder what would happen if you split your 8-channel files and played them simultaneously as 4-channel soundfiles... or, if it's always running on your computer, you might try storing half of your soundfiles on one disk and the other half on another -- it's hard to know whether the disk is going bonkers or readsf~ breaks. Depending on the size of your files you might bite the bullet and load them into tables... At any rate, you should have three files -- one is a generic abstraction that shows the general method. The other abstraction (playback_8ch_fade) is based on your first patch, and is generalized to play any 8-channel soundfile -- hopefully the comments in them are useful. I kept your 6n56 ms humanization in the file, as well as the throws to ch1-ch8 (I'd probably use outlet~ more often than not, but this is fine if you know how you need to set up the rest of the patch). It uses the same general method as the generic patch, but adds some other goodies I would feel obligated to provide if I were giving the abstraction to someone to use... but maybe it's way overkill for personal use, or inside a patch where nobody's gonna see it. It has some basic type-checking and conversion, but no error printing, which I would normally do if I had the time or were building a library. It also has a small example of some dynamic patching, which might better be left out, and could maybe even be avoided in this example (nothing comes to mind instantly)... I like having the option to change things on the fly, though, so I use this kind of thing in my own patches all the time. Let me know if it's even readable. The third file (marked revised) is an example of how to use the bigger abstraction. I haven't fully debugged it all, and lots of optimizations could be made all over the place but I think it should work as an example patch. Of course others are welcome to comment if it sucks, or use any of it if they find it compelling. =o) Let me know if this helps out, but I've a feeling your problem is deeper than any method for using [readsf~]. Matt On Mon, Jul 14, 2008 at 12:51 PM, Dr. Greg Wilder [EMAIL PROTECTED] wrote: Matt Barber wrote: Date: Sat, 12 Jul 2008 13:56:54 +0200 From: Damian Stewart [EMAIL PROTECTED] Subject: [PD] how to avoid (most/many/some) readsf~ dropouts To: PD-List pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed hey, one thing i've noticed with readsf~ using it in my own live-performance sets is that doing this [symbol blahblahblah.aif] | [open $1, bang( | [readsf~] sometimes causes dropouts. but if you go [symbol blahblahblah.aif] | [t b a] | \ | \ [del 50][open $1( | __/ |/ [readsf~] then you remove (all/many/some) of the dropouts. i haven't extensively tested this, but anecdotal evidence seems to suggest that it works. I think this is because the former method may not let the buffer fill before you start playing. I usually don't like the second method, either, because of the 50 ms delay (which isn't much, but I'm finicky about that kind of thing). Depending on the setup, I usually prefer something like the following: [loadbang] | | [r open] | / [open file.ext ( [0 ( [1 (| | \__ | [t b f ]_\ | | [readsf~ ] [s open]| [s open] I hope things line up okay there... at any rate, you load the buffer at the beginning, or if your piece/performance has a master clock, a couple of seconds before you need it. Then for rehearsal, if you need to stop the file you can use a trigger to reload it immediately. Also, if you need to play the file again, you can send the open message when the file is done playing. This makes the whole process a little more front-loaded, so that the soundfile is always open no matter what. My intuition is that it's more robust than other schemes I've tried. I haven't tested it very hard, though, as I've only ever needed up to 9-10 simultaneous 96k files... maybe it would be neat to find some old, slow hardware to see how far different methods can be pushed. =o) More advanced for stopping would be something that fades out the sound with a [line~] over 20 ms or so, and then sends the stop message to [readsf~] after a comparable delay -- that way you won't get an annoying transient upon stop -- same deal with a fade in if you are starting in the middle of the soundfile, but without the delay. I usually wrap the whole thing in an abstraction -- I keep three or four different ones lying around with different properties for different situations,
