Re: [PD] Zero delay feedback, with settable send?
Hallo, Kim Taylor hat gesagt: // Kim Taylor wrote: I have had success using throw~ and catch~, as the destination bus can be changed by setting throw~, BUT- throw and catch use a minimum block size of 64. Hm? They don't, unless you do feedbacks, but then everyhting~ in Pd has a delay of one block. See http://crca.ucsd.edu/~msp/techniques/latest/book-html/node120.html and http://crca.ucsd.edu/~msp/techniques/latest/book-html/node121.html Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Highlight modified abstraction instances with red
On Thu, 2007-05-10 at 20:42 -0700, Luke Iannini (pd) wrote: Just wanted to post an idea... It would be great if Pd highligted modified abstractions in red in their parent patch (that is, the one pixel bounding box and text. When I've modified one of a bunch of abstractions in a parent and close it without saving, I have to open each one to see if it was the one I modified. you could easily come around this by letting the window of the instance of your abstraction open, that you have modified. when testing is finished and you decide to save changes, you know which one to save. however, i like the idea as well. a visual feedback in the parent patch would be nice. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Connection with sensors - new devices?
This firmware reads 2 ultrasound sensors at the same time, I guess it might read more with a little adjustment in firmware. Firmata Ultrasound firmware will be really great, I remember we had this discussion earlier, and there was some sort of problem to code Pulse in Pd_firmware.pde so that we could read ultrasound sensors through [arduino] in PD. Looking forward to test this library!!! Koray. - M.Koray Tahiroglu Media Lab,UIAH http://mlab.uiah.fi/~korayt/ tel: +358 50 939 02 33 ( in Finland only) tel: +90 533 712 8245 On May 11, 2007, at 1:54 AM, Hans-Christoph Steiner wrote: Does this firmware handle multiple ultrasound sensors? If so, it would awesome to make a Firmata Ultrasound firmware. I just started making the Firmata protocol into a library so that people can write more firmwares and still use the same objects in the host software. A multiple ultrasound sensor would be a great first test of this library, since it would only need to input data. .hc On May 10, 2007, at 5:27 PM, Koray Tahiroglu wrote: Hello Kyle, I am glad that those patches worked and helped you out with your project. I guess big thanks goes to Hans for them, cos during that time, I just modified his existing multi-sensor patches and developed them further to use in my project. Koray. - M.Koray Tahiroglu Media Lab,UIAH http://mlab.uiah.fi/~korayt/ tel: +358 50 939 02 33 ( in Finland only) tel: +90 533 712 8245 On May 10, 2007, at 11:38 PM, Kyle Klipowicz wrote: Thanks so much Koray, it works great! I see you used the same Arduino code for the sensor as I had found, and your Pd patch is very well-written and well-commented. I appreciate this, because I did not want to try coding microsecond-level events in Pd by porting the Arduino code and using firmata, and I didn't want to use the SimpleMessaging library either. This helps us out a TON! ~Kyle On 5/8/07, Koray Tahiroglu [EMAIL PROTECTED] wrote: Hello Kyle, Here I attach .pde files for arduino to read ultrasound sensors (they might have already there in the arduino sketchbook already, but just sending to be sure) and also modified Hans pd patches for arduino-pd communication. I didn't test them lately, but they used to be working fine. best, Koray. - M.Koray Tahiroglu Media Lab,UIAH http://mlab.uiah.fi/~korayt/ tel: +358 50 939 02 33 ( in Finland only) tel: +90 533 712 8245 On May 8, 2007, at 5:48 AM, Kyle Klipowicz wrote: Hi Koray~ I am working on a group project that involves Arduino and the parallax PING ultrasonic sensors. Would you be willing to share your Pd patches regarding this usage, as indicated in this email? Thanks in advance! ~Kyle On 12/22/05, Koray Tahiroglu [EMAIL PROTECTED] wrote: hello Hans, I made couple of test patches just to see the range and the stability of the values that I receive from sensors. At the moment, I am testing ultrasound sensor and also self made solar panel board sensor. After this weekend I will begin to construct my final patches for a gig that will be on 14th of January. I can upload the patches on PD site. During our Arduino+PD workshop two weeks ago, we basically started to develop your multi-sensor patch, which actually David had changed couple of things during a previous workshop in Vancouver. All in all i think it is such a nice idea to make easy-to- use framework for sensor boxes. Especially most of the Mac OS X users have problems with comport communication. Koray. - M.Koray Tahiroglu Media Lab, University of Art and Design Helsinki, TaiK Hameentie 135C 00560 Helsinki Finland http://mlab.uiah.fi/~korayt/ http://purenoise.uiah.fi:8000/ tel: +358 40 754 8449 fax: +358 9 75630 555 On Dec 21, 2005, at 9:32 PM, Hans-Christoph Steiner wrote: Do you have an patches that you are willing to share? I want to see how people are using various boards with Pd. I will be working a lot with sensor boards in the coming months, including the Arduino, MultIO, and STEIM's junXionbox. Basically, I want to make an easy-to-use framework like the [hid] toolkit for sensor boxes. So basically, I'll be making high-level abstractions to interface these boxes which output data in a floating point range of 0-1. That means you can then use all of the mapping objects that I wrote for the [hid] toolkit. Actually, I think the grand plan will be to make a separate library of mapping objects, and then librariess for HIDs, sensor boxes, etc. .hc On Dec 20, 2005, at 2:10 PM, Koray Tahiroglu wrote: I've been using arduino with PD heavily since the beginning of December, I am happy with the ready sensor connections as well as self made sensors. And Arduino is an open source microcontroller hardware, http://www.arduino.cc/ cheers, Koray. On Dec 20, 2005, at 7:55 PM, [EMAIL PROTECTED]
Re: [PD] Highlight modified abstraction instances with red
Yes; this suggestion is for when I close the window inadvertently : ) On 5/11/07, Roman Haefeli [EMAIL PROTECTED] wrote: On Thu, 2007-05-10 at 20:42 -0700, Luke Iannini (pd) wrote: Just wanted to post an idea... It would be great if Pd highligted modified abstractions in red in their parent patch (that is, the one pixel bounding box and text. When I've modified one of a bunch of abstractions in a parent and close it without saving, I have to open each one to see if it was the one I modified. you could easily come around this by letting the window of the instance of your abstraction open, that you have modified. when testing is finished and you decide to save changes, you know which one to save. however, i like the idea as well. a visual feedback in the parent patch would be nice. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ 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] Connection with sensors - new devices?
Yes, it seems better to code these microsecond pulses in the firmware rather than letting Pd control this directly. Maybe at audio signal rate this would be more satisfactory, I am not well-versed in this. Our plan is to use 6 sensors, so we will attempt to modify the existing ultrasound firmware to this end. I see no reason why it would not work! ~Kyle On 5/11/07, Koray Tahiroglu [EMAIL PROTECTED] wrote: This firmware reads 2 ultrasound sensors at the same time, I guess it might read more with a little adjustment in firmware. Firmata Ultrasound firmware will be really great, I remember we had this discussion earlier, and there was some sort of problem to code Pulse in Pd_firmware.pde so that we could read ultrasound sensors through [arduino] in PD. Looking forward to test this library!!! Koray. - M.Koray Tahiroglu Media Lab,UIAH http://mlab.uiah.fi/~korayt/ tel: +358 50 939 02 33 ( in Finland only) tel: +90 533 712 8245 On May 11, 2007, at 1:54 AM, Hans-Christoph Steiner wrote: Does this firmware handle multiple ultrasound sensors? If so, it would awesome to make a Firmata Ultrasound firmware. I just started making the Firmata protocol into a library so that people can write more firmwares and still use the same objects in the host software. A multiple ultrasound sensor would be a great first test of this library, since it would only need to input data. .hc On May 10, 2007, at 5:27 PM, Koray Tahiroglu wrote: Hello Kyle, I am glad that those patches worked and helped you out with your project. I guess big thanks goes to Hans for them, cos during that time, I just modified his existing multi-sensor patches and developed them further to use in my project. Koray. - M.Koray Tahiroglu Media Lab,UIAH http://mlab.uiah.fi/~korayt/ tel: +358 50 939 02 33 ( in Finland only) tel: +90 533 712 8245 On May 10, 2007, at 11:38 PM, Kyle Klipowicz wrote: Thanks so much Koray, it works great! I see you used the same Arduino code for the sensor as I had found, and your Pd patch is very well-written and well-commented. I appreciate this, because I did not want to try coding microsecond-level events in Pd by porting the Arduino code and using firmata, and I didn't want to use the SimpleMessaging library either. This helps us out a TON! ~Kyle On 5/8/07, Koray Tahiroglu [EMAIL PROTECTED] wrote: Hello Kyle, Here I attach .pde files for arduino to read ultrasound sensors (they might have already there in the arduino sketchbook already, but just sending to be sure) and also modified Hans pd patches for arduino-pd communication. I didn't test them lately, but they used to be working fine. best, Koray. - M.Koray Tahiroglu Media Lab,UIAH http://mlab.uiah.fi/~korayt/ tel: +358 50 939 02 33 ( in Finland only) tel: +90 533 712 8245 On May 8, 2007, at 5:48 AM, Kyle Klipowicz wrote: Hi Koray~ I am working on a group project that involves Arduino and the parallax PING ultrasonic sensors. Would you be willing to share your Pd patches regarding this usage, as indicated in this email? Thanks in advance! ~Kyle On 12/22/05, Koray Tahiroglu [EMAIL PROTECTED] wrote: hello Hans, I made couple of test patches just to see the range and the stability of the values that I receive from sensors. At the moment, I am testing ultrasound sensor and also self made solar panel board sensor. After this weekend I will begin to construct my final patches for a gig that will be on 14th of January. I can upload the patches on PD site. During our Arduino+PD workshop two weeks ago, we basically started to develop your multi-sensor patch, which actually David had changed couple of things during a previous workshop in Vancouver. All in all i think it is such a nice idea to make easy-to- use framework for sensor boxes. Especially most of the Mac OS X users have problems with comport communication. Koray. - M.Koray Tahiroglu Media Lab, University of Art and Design Helsinki, TaiK Hameentie 135C 00560 Helsinki Finland http://mlab.uiah.fi/~korayt/ http://purenoise.uiah.fi:8000/ tel: +358 40 754 8449 fax: +358 9 75630 555 On Dec 21, 2005, at 9:32 PM, Hans-Christoph Steiner wrote: Do you have an patches that you are willing to share? I want to see how people are using various boards with Pd. I will be working a lot with sensor boards in the coming months, including the Arduino, MultIO, and STEIM's junXionbox. Basically, I want to make an easy-to-use framework like the [hid] toolkit for sensor boxes. So basically, I'll be making high-level abstractions to interface these boxes which output data in a floating point range of 0-1. That means you can then use all of the mapping objects that I wrote for the [hid] toolkit. Actually, I think the grand plan will be to make a separate
Re: [PD] Zero delay feedback, with settable send?
Hallo, Kim Taylor hat gesagt: // Kim Taylor wrote: I have had success using throw~ and catch~, as the destination bus can be changed by setting throw~, BUT- throw and catch use a minimum block size of 64. Hm? They don't, unless you do feedbacks, but then everyhting~ in Pd has a delay of one block. How true, I must have overlooked this... It's one of the tricky things to get right in Pd. ;) If you really want to make sure not to pick up any unwanted delays you need to use the double-subpatch technique described in Miller's book, as the block-delay of direct connections depends on the order in which you made the connections, and that's to fragile: editing can change the order without you noticing it. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM mapping units to pixels
hello, i think you should also move the camera position. if you use this : dimen 400 300 perspect 0 400 0 300 1 20 then you should also use somthing like this : view 200 150 1000 moving the camera far from the point you look at should reduce distortion. cyrille altern a écrit : hi I am trying to map GEM units to pixels so that i can position some videos in the GEM window using pixels values. For this I understand that i must match the projection values with the window size. So i am doing dimen 400 300 perspect 0 400 0 300 1 20 and i render all objects at z position 1 translateXYZ 100 100 1 However I am getting a weird result, the units are far smaller that pixels, so to move a video 100px in the x i need to change it x position by 300 units or something like this. So I am not sure about what i am doing wrong, I am familiar with OpenGL but i never played too much with GEM before so I am still getting into it. Another small issue is that I would also like to reverse the Y so that upper left is 0,0 and bottom left would be 0,200 for example, not sure about how to change this. I guess it is to do with the gemwin settings but i dont get it right. thanks enrike ___ 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 mapping units to pixels
hi I am trying to map GEM units to pixels so that i can position some videos in the GEM window using pixels values. For this I understand that i must match the projection values with the window size. So i am doing dimen 400 300 perspect 0 400 0 300 1 20 and i render all objects at z position 1 translateXYZ 100 100 1 However I am getting a weird result, the units are far smaller that pixels, so to move a video 100px in the x i need to change it x position by 300 units or something like this. So I am not sure about what i am doing wrong, I am familiar with OpenGL but i never played too much with GEM before so I am still getting into it. Another small issue is that I would also like to reverse the Y so that upper left is 0,0 and bottom left would be 0,200 for example, not sure about how to change this. I guess it is to do with the gemwin settings but i dont get it right. thanks enrike ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
I have had success using throw~ and catch~, as the destination bus can be changed by setting throw~, BUT- throw and catch use a minimum block size of 64. Hm? They don't, unless you do feedbacks, but then everyhting~ in Pd has a delay of one block. How true, I must have overlooked this... Fantastic news Thanks K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
Hallo! If you really want to make sure not to pick up any unwanted delays you need to use the double-subpatch technique described in Miller's book, as the block-delay of direct connections depends on the order in which you made the connections, and that's to fragile: editing can change the order without you noticing it. So you need order forcing (see attached patch). You can get delays down to 1 sample with that method AFAIK. LG Georg #N canvas 546 262 448 422 10; #X obj 46 181 inlet~ signal; #X obj 146 307 sig~; #X obj 46 363 outlet~; #N canvas 0 0 450 212 delay-writer 0; #X obj 22 27 inlet~; #X obj 52 87 delwrite~ \$0-delline1 2000; #X obj 116 113 delwrite~ \$0-delline2 2000; #X obj 22 159 outlet~; #X connect 0 0 1 0; #X connect 0 0 2 0; #X connect 0 0 3 0; #X restore 46 227 pd delay-writer; #N canvas 0 0 450 300 delay-reader 0; #X obj 38 165 vd~ \$0-delline1; #X obj 38 191 outlet~; #X obj 38 139 inlet~; #X obj 35 39 inlet~; #X text 34 61 dummy; #X text 34 75 (to force execution order !); #X connect 0 0 1 0; #X connect 2 0 0 0; #X restore 46 335 pd delay-reader; #X text 55 266 - needed for right execution order !; #X obj 180 181 inlet delay; #X text 15 20 exact-delay~; #X text 15 90 This patch is able to get a delay down to 1 sample because of execution order forcing !; #X text 15 48 in1: the signal; #X text 15 62 in2: delay time in ms; #X text 255 372 Georg Holzmann \, 2007; #X connect 0 0 3 0; #X connect 1 0 4 1; #X connect 3 0 4 0; #X connect 4 0 2 0; #X connect 6 0 1 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pix_record inverting image
Hi all, I am using pix_snap and pix_record to get a series of images with decoration into a video file. This is (surprisingly enough!) working already, but with one interesting feature: the recorded videos are vertically inverted! top-bottom exchange... Hmm, any ideas what that might mean? I am using yesterday's build for OSX PPC from .hc. The problem seems to lie with pix_snap: if I connect the input pix_video straight to pix_record, then it goes through right, gets recorded right, all is well. I build a capture with pix_snap. If I look at the texture coming out of pix_snap by pix_texture-ing it onto a rectangle, then it looks right. It just gets turned upside down when it gets recorded. Any ideas would be great. No huge loss, I am sure it a simple post-processing thing to make it look right, but I would like to know what is going wrong tim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] OT - Pd on Leno
Hey Y'all
Thanks for the good wishes.
Yeah - it's a pretty good gig. I'm feeling kinda lucky to be using Pd
on this gig - so far it's just a couple of synths and some effects,
but as time goes by I'm pretty sure I'll be able to start stretching a
bit (I'm still pretty new to the band).
Kyle: the band is all from Toronto, although lots of the folks on the
records are from Berlin and Paris. And I gotta say, Berlin is wicked
cool. I'm not from there yet, but soon...
If anybody notices we're playing in your town, please email me - I'd
love to hook up, and we generally have a couple of spots each on the
guest list.
Conan O'Brien on June 12! Damn.
cheers
dafydd
On 5/9/07, Kyle Klipowicz [EMAIL PROTECTED] wrote:
Yeah man! I love Feist! I hope to join the Berlin diaspora myself
soon. do you live there?
~Kyle
On 5/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Thanks for sharing!
Congrats Dafydd! Feisty!
I didn't know you played with Feist - great stuff and would seem to me a
very suitable outlet for you to do more audio experimentation while
still in a pop format.
Best,
p
Original Message
Subject: Re: [PD] OT - Pd on Leno
From: Kevin McCoy [EMAIL PROTECTED]
Date: Wed, May 09, 2007 3:00 pm
To: Dafydd Hughes [EMAIL PROTECTED], PD-list@iem.at
http://youtube.com/watch?v=rlxrjIMNIeg
Excellent, band sounded great! I can't wait to see you guys in Ohio. So
you're the one at the piano with the midi controller? Looking smooth,
Dafydd!
Congrats again,
Kevin
On 5/8/07, Dafydd Hughes [EMAIL PROTECTED] wrote:
Hi folks
If you've got nothing better to do this evening, the band I'm touring
with is playing on the Tonight Show, and I'm using Pd for about 8 bars
of a mellotron flute sample. Not nearly as impressive as Bjork's rig,
but what the hey, it's Pd in the pop world:)
cheers
dafydd
--
www.sideshowmedia.ca
skype: chickeninthegrass
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
--
http://pocketkm.blogspot.comhr___
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
--
http://theradioproject.com
http://perhapsidid.blogspot.com
(()()()(()))()()())(
(())(())()(((
))(__
_())(()))___
(((000)))oOO
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
--
www.sideshowmedia.ca
skype: chickeninthegrass
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_record inverting image
Tim Boykett wrote: I build a capture with pix_snap. If I look at the texture coming out of pix_snap by pix_texture-ing it onto a rectangle, then it looks right. It just gets turned upside down when it gets recorded. Any ideas would be great. No huge loss, I am sure it a simple post-processing thing to make it look right, but I would like to know what is going wrong well, openGL originates the image at the bottom-left corner; pixel-formats differ about this, some have the origin in bottom-left, others in top-left. for optimization-reasons, Gem only flags the latter images as upside down and displays them correctly (with special code in [pix_texture]). obviously there is no corresponding code in [pix_record]... as a quick hack you can either flip the pixes after recording (with your favourite editor), or before recording with [pix_flip] fgmsadr.- IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pix_multiblob cpu usage
I made a 400x300 motion JPEG-a movie 15 fps with 5 solid blue circles moving on a black background to test pix_mutiblob. I open it up with pix_film, flip it with pix_flip and send it to pix_multiblob. I suddenly notices PD getting very, very slow. When I look at the cpu usage in activity monitor (if you can believe activity monitor) I get 100-104% cpu usage. I cant do anything else in PD because PD gets so slow. I am using a dual 2Ghz G5 with ATI Radeon 9800 XT and 3GB of internal memory. Is this normal? What can I do to lower cpu usage? What else can I use within Gem to get the same results? I eventually want to be able to track 20-30 objects but It looks like it would be imposible at this rate. Thanks, Alain ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] converting (hebrew) text to numerical values?
Hi list I am willing to set up a patch that could convert letters to numerical values, so i could use converted text to send data to other patches (and then produce sound). My problem is that i want to work with hebrew, and i want pd to be able to differenciate between consonants and vowels, and maybe even to be able to recognize roots within the word. As I am quite a novice concerning pd, I have no clue about the most efficient way to convert letters into values, and i dont even know if it is possible within pd? Any advice will be greatly appreciated. Shalom Cyrill Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
Thanks for this, its cleared things up. Is there any purpose in the $0-delline2 delay line though? K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] converting (hebrew) text to numerical values?
morning Cyrill, Well, the most elegant way to convert back and forth between numerical (ASCII-like) values and text is Martin Peach's string patch to the pd sources (search the PD-dev archives for string type for pd). If you don't feel like going that deep, you can use my [any2string] and [string2any] externals (in CVS, or from me at www.ling.uni-potsdam.de/~moocow/projects/pd). Alternatively, you could split symbols into single characters using [symbol2list] from zexy, and then map these to numbers however you want (e.g. with [index] from zexy, PDContainer, pool, [gfsm_alphabet] from gfsm, etc.) You can do character classification (and even substring classification) with python (in which case you don't really need the string or indexing stuff), or with a simple finite state transducer (gfsm again), although if you're just interested in differentiating between consonants vowels, you're probably better off just using [route] here... marmosets, Bryan On 2007-05-11 21:33:29, Cyrill [EMAIL PROTECTED] appears to have written: Hi list I am willing to set up a patch that could convert letters to numerical values, so i could use converted text to send data to other patches (and then produce sound). My problem is that i want to work with hebrew, and i want pd to be able to differenciate between consonants and vowels, and maybe even to be able to recognize roots within the word. As I am quite a novice concerning pd, I have no clue about the most efficient way to convert letters into values, and i dont even know if it is possible within pd? Any advice will be greatly appreciated. Shalom Cyrill -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
Actually, sorry- I thought I understood this but I've got a problem with this method Considering the patch posted by Georg Holzmann (the same principle as http://crca.ucsd.edu/~msp/techniques/latest/book-html/node121.html)- Surely if the block size is default 64 samples, the delwrite atom will take at least 64 samples to write to the delay line... So the delread (next in sequence) cannot read out the contents of the delay line until AFTER this has happened? I don't understand how a minimum delay of 1 sample can be achieved (although I admit I have made it work in practice!!!) Kim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
