Re: [PD] Message from the boss of Raspberry Pi Foundation !
Hi, Ok, so Charles Henry has been working on this, good. Anybody else would have something to propose ? I'd love to help but my technical background is far from sufficient. Bringing this to the attention of the RPi foundation is about all I could do I think. @Hardoff : the patch i'm using in the video requires 16 ms of latency, because it uses phase vocoding. You can drop to 10 ms without it, and I guess even lower would be possible. I use the very first version of the Pi, with half the RAM the new model has. If we can get the GPU to compute the audio i hope that we'll be able to get to really reasonable latencies (to me 6 to 8 ms is really enough to play live). Also, i use the regular Pd fro the debian repos. I can't tell you whether Miller's or Katja's version work better. Cheers, Piere. 2013/2/8 Simon Iten itensi...@gmail.com pierre wrote in his blog that he can go as low as 10ms, later in the settings he writes about 16ms. On Feb 8, 2013, at 1:57 PM, i go bananas hard@gmail.com wrote: sorry, i don't think this is the thread i should be asking this in, but how low latency can you get with pd on a pi ? ___ 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] Message from the boss of Raspberry Pi Foundation !
10ms or less would be totally acceptable. wow, i really wanna give this a go ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Message from the boss of Raspberry Pi Foundation !
Hi Pierre, There has been intensive discussion about GPU processing on RPI: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33t=6188 Did you read it? In the light of this discussion, I wonder what Eben means when writing We have a bunch of GPU compute available on the device just waiting for an application like this. Anyway it's great they have put your project on RPi blog. You will be famous, Pi Massat! Congrats again. Katja On Fri, Feb 8, 2013 at 10:51 AM, Pierre Massat pimas...@gmail.com wrote: Dear all, Please read below the message I received from Eben Upton, the boss of Raspberry Pi foundation. It looks like he was impressed by the video I made, and he says that there's a possibility of letting the GPU do some DSP computation. I guess you'll all agree that this is awesome news. I have no idea how we can proceed now. I think i'm absolutely incapable of doing anything useful in this field, so i told him that i would transfer this message to you, hoping that Miller, HC, Katja (and others) would know what needs to be done. We should probably ask him if you guys could work directly with their developers. Let me know what you think. Cheers! Pierre. -- Forwarded message -- From: Eben Upton e...@raspberrypi.org Date: 2013/2/8 Subject: Re: RPi as multi-effects for guitar To: Pierre Massat pimas...@gmail.com Hi Pierre Awesome stuff - I think Liz is preparing a blog post about this as we speak. I'd be very interested in knowing a bit more about the DSP code that runs this stuff. We have a bunch of GPU compute available on the device just waiting for an application like this. Cheers Eben On Thu, Feb 7, 2013 at 2:29 AM, Pierre Massat pimas...@gmail.com wrote: Hi, I write a blog about how to make guitar effects with computers running Pure Data in real-time. When I first heard about the Raspberry Pi I thought it would be great if I could use it for the same purpose. It would only be much cheaper, and much smaller than my current laptop, and could fit in my hand-made stompbox. Recent improvements in Raspbian have finally made this possible, and this makes me very happy ! The Raspberry Pi is now actually capable of running rather demanding Pure Data patches in (quasi-) real-time (at least with a latency that's low enough to play live with it). I quickly assembled a small patch to test it and make a video to demonstrate that it actually works very well. It is obviously not the use the RPi was originally intended for, but to me (and I'm sure to other musicians as well), this sounds like a revolution. I'm currently documenting my setup on my blog : - video : http://guitarextended.wordpress.com/2013/01/27/real-time-guitar-effects-with-raspberry-pi-pd-and-arduino/ - blog post about hardware : http://guitarextended.wordpress.com/2013/01/31/raspberry-pi-multi-effects-overview-of-the-setup/ There's no trick, the Pi really IS doing all the DSP work. A reader posted a comment to ask where the computer was :) I take this opportunity to thank the RPi foundation for all the good work you put in this amazing tiny thing. I see that the cam should be out in a few months, this is all very exciting. I'm sure the Pi has already changed the life of a lot of people ! Cheers, Pierre. ___ 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] Object cursor don´t work in 0.43.4 / Windows 7
Object cursor don´t work in 0.43.4 / Windows 7, === (maybe its in a special library not included now in the new version? Might it be a crappy installation I did? For instance I keep the old 0.42.3 installation, might that interfere with the newer?) I filled in an error report at sourceforge, but thought I should send it here aswell, as I am using the [cursor] in some teaching soon. First I was thinking to let the students install the 0.42.3 just out of a small fear that it might be a bit unstable with some things, but thinking on it twice made me go for the newer because it should be more up to date, and also has some rather amazing functions implemented. /Björn Eriksson Ok, here is the error text that appears: (Tcl) INVALID COMMAND NAME: invalid command name pd while executing pd [concat #hcs_cursor_class_receive motion $x $y \;] (procedure ::hcs_cursor_class::motion line 3) invoked from within ::hcs_cursor_class::motion [winfo pointerx .] [winfo pointery .] (procedure ::hcs_cursor_class::pollmotion line 2) invoked from within ::hcs_cursor_class::pollmotion (uplevel body line 4) invoked from within uplevel #0 $cmds_from_pd System: Pd version 0.43.4-extended Win 7 M-Audio Fast Track Ultra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Message from the boss of Raspberry Pi Foundation !
Hi Katja, I wasn't aware of this at all. Thanks for the link ! I'll read it this afternoon. Thank you! Pierre. 2013/2/9 katja katjavet...@gmail.com Hi Pierre, There has been intensive discussion about GPU processing on RPI: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33t=6188 Did you read it? In the light of this discussion, I wonder what Eben means when writing We have a bunch of GPU compute available on the device just waiting for an application like this. Anyway it's great they have put your project on RPi blog. You will be famous, Pi Massat! Congrats again. Katja On Fri, Feb 8, 2013 at 10:51 AM, Pierre Massat pimas...@gmail.com wrote: Dear all, Please read below the message I received from Eben Upton, the boss of Raspberry Pi foundation. It looks like he was impressed by the video I made, and he says that there's a possibility of letting the GPU do some DSP computation. I guess you'll all agree that this is awesome news. I have no idea how we can proceed now. I think i'm absolutely incapable of doing anything useful in this field, so i told him that i would transfer this message to you, hoping that Miller, HC, Katja (and others) would know what needs to be done. We should probably ask him if you guys could work directly with their developers. Let me know what you think. Cheers! Pierre. -- Forwarded message -- From: Eben Upton e...@raspberrypi.org Date: 2013/2/8 Subject: Re: RPi as multi-effects for guitar To: Pierre Massat pimas...@gmail.com Hi Pierre Awesome stuff - I think Liz is preparing a blog post about this as we speak. I'd be very interested in knowing a bit more about the DSP code that runs this stuff. We have a bunch of GPU compute available on the device just waiting for an application like this. Cheers Eben On Thu, Feb 7, 2013 at 2:29 AM, Pierre Massat pimas...@gmail.com wrote: Hi, I write a blog about how to make guitar effects with computers running Pure Data in real-time. When I first heard about the Raspberry Pi I thought it would be great if I could use it for the same purpose. It would only be much cheaper, and much smaller than my current laptop, and could fit in my hand-made stompbox. Recent improvements in Raspbian have finally made this possible, and this makes me very happy ! The Raspberry Pi is now actually capable of running rather demanding Pure Data patches in (quasi-) real-time (at least with a latency that's low enough to play live with it). I quickly assembled a small patch to test it and make a video to demonstrate that it actually works very well. It is obviously not the use the RPi was originally intended for, but to me (and I'm sure to other musicians as well), this sounds like a revolution. I'm currently documenting my setup on my blog : - video : http://guitarextended.wordpress.com/2013/01/27/real-time-guitar-effects-with-raspberry-pi-pd-and-arduino/ - blog post about hardware : http://guitarextended.wordpress.com/2013/01/31/raspberry-pi-multi-effects-overview-of-the-setup/ There's no trick, the Pi really IS doing all the DSP work. A reader posted a comment to ask where the computer was :) I take this opportunity to thank the RPi foundation for all the good work you put in this amazing tiny thing. I see that the cam should be out in a few months, this is all very exciting. I'm sure the Pi has already changed the life of a lot of people ! Cheers, Pierre. ___ 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] Archlinux packages (was: enhance...)
On Sat, Feb 9, 2013 at 7:31 AM, Fero Kiraly fero.kir...@gmail.com wrote: ok. I get working pd-vanilla, pdx, pd-l2ork on one archlinux system. https://aur.archlinux.org/packages/pd-l2ork/ Fantastic that you've made these available. Thanks a lot. Unfortunately, the build for pd-l2ork is failing for me at the disis_wiimote build stage. I can post the errors if you like but I suspect the build fails because disis_wiimote requires the pd-l2ork vesion of cwiid. For now I 'll try building without disis_wiimote, but it is something I would like to use so that's not an ideal solution. I was wondering how you have been able to successfully build pd-l2ork with this external included, since the PKGBUILD does not download the required cwiid tarball or attempt to build it so far as I can tell. thanks again Michael ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Archlinux packages (was: enhance...)
honestly I dont know where could be problem with compiling disis wiimote, on my system it builds. I just tried example disis_wiimote-help.pd and the object is not available. In console are errors: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote ... couldn't create /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote 00:19:1D:BE:6A:66 ... couldn't create /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote ... couldn't create /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote 00:19:1D:BE:6A:66 ... couldn't create ??? fk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] gimbal lock solution?
Iam trying to rotate GEM object with my android phone, sending from acc sensor througth OSC Gem object rotateXYZ is not the solution for that, maybe because of gimbal lock effect... Did anybody similar working patch in pd ? Or can somebody hel me ? many thanks. fk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Archlinux packages (was: enhance...)
On Sat, Feb 9, 2013 at 9:02 PM, Fero Kiraly fero.kir...@gmail.com wrote: honestly I dont know where could be problem with compiling disis wiimote, on my system it builds. I just tried example disis_wiimote-help.pd and the object is not available. In console are errors: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote ... couldn't create /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote 00:19:1D:BE:6A:66 ... couldn't create /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote ... couldn't create /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote 00:19:1D:BE:6A:66 ... couldn't create ??? fk. On the l2ork website it states that there is a specific build of cwiid needed that is downloadable from the site. Ivica mentioned something about this in an earlier email as well, so I suspect it is the cause of the issue. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Message from the boss of Raspberry Pi Foundation ! (Jon)
Hi All, I've been a silent observer for some time now, but since GPU processing is 'close to my heart', I thought I'd jump in... So there goes my first post in the pd-list... In general, GPUs are really beneficial for parallelisable algorithms involving heavy-computations, such as FFTs, fast convolution, BLAS with huge matrices, finite difference modelling etc... To maximise performance, the GPU kernel needs to unanimously operate over a large enough data set which needs to be copied into the device's memory, as GPUs generally can't access the host memory. This would mean large buffers -- increased latency. So doing 'real-time' DSP on a GPU would probably make more sense for stuff like physical modelling, complex additive synthesis etc..., rather than to 'generally reduce the system latency'. *However*, if the SoC platform physically shares memory between the GPU and the CPU, then this could, in theory, help reduce the inherent latency (as no memory transfers would be required), but without having detailed documentation, this would be difficult to assess. Cheers, Jon. www.jonsh.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gimbal lock solution?
On Sam, 2013-02-09 at 13:07 +0100, Fero Kiraly wrote: Iam trying to rotate GEM object with my android phone, sending from acc sensor througth OSC Gem object rotateXYZ is not the solution for that, maybe because of gimbal lock effect... Did anybody similar working patch in pd ? Or can somebody hel me ? many thanks. If I understand the gimbal lock correctly (I only read about it now), your problem seems not related to it. With accelerometer data only, you can only calculate two axis of orientation (pitch and roll), while yaw is still missing. You cannot measure the angle of rotation along the direction of gravity with accelerometers. You'd need something else for yaw, a compass or a gyroscope (while the latter is giving you only relative measurements). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
Hi again Katja, I just read through it. Couldn't find anything about having the GPU process some audio. It's really mostly about why it's a bad (or good) thing to keep the GPU closed-source (at least that's what I understand [?]). So I guess there isn't must we can do on our own to access the GPU. But then, what can Eben and his team do about it ? I'd like to know what answer we can give him. If he says just waiting for an application like this I am assuming that it must have aroused his interest somehow. And I believe that it would be great if people in the Pd community got involved. All I can provide is some testing, but others could contribute more (if i'm not mistaken, Miller Puckette did a great job fixing the analog out for instance). I think we should try and play a part in the development of the Pi. And if we're lucky we'll finally have that Pd box people have been dreaming about for years. Cheers, Pierre. 2013/2/9 katja katjavet...@gmail.com Hi Pierre, There has been intensive discussion about GPU processing on RPI: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33t=6188 Did you read it? In the light of this discussion, I wonder what Eben means when writing We have a bunch of GPU compute available on the device just waiting for an application like this. Anyway it's great they have put your project on RPi blog. You will be famous, Pi Massat! Congrats again. Katja On Fri, Feb 8, 2013 at 10:51 AM, Pierre Massat pimas...@gmail.com wrote: Dear all, Please read below the message I received from Eben Upton, the boss of Raspberry Pi foundation. It looks like he was impressed by the video I made, and he says that there's a possibility of letting the GPU do some DSP computation. I guess you'll all agree that this is awesome news. I have no idea how we can proceed now. I think i'm absolutely incapable of doing anything useful in this field, so i told him that i would transfer this message to you, hoping that Miller, HC, Katja (and others) would know what needs to be done. We should probably ask him if you guys could work directly with their developers. Let me know what you think. Cheers! Pierre. -- Forwarded message -- From: Eben Upton e...@raspberrypi.org Date: 2013/2/8 Subject: Re: RPi as multi-effects for guitar To: Pierre Massat pimas...@gmail.com Hi Pierre Awesome stuff - I think Liz is preparing a blog post about this as we speak. I'd be very interested in knowing a bit more about the DSP code that runs this stuff. We have a bunch of GPU compute available on the device just waiting for an application like this. Cheers Eben On Thu, Feb 7, 2013 at 2:29 AM, Pierre Massat pimas...@gmail.com wrote: Hi, I write a blog about how to make guitar effects with computers running Pure Data in real-time. When I first heard about the Raspberry Pi I thought it would be great if I could use it for the same purpose. It would only be much cheaper, and much smaller than my current laptop, and could fit in my hand-made stompbox. Recent improvements in Raspbian have finally made this possible, and this makes me very happy ! The Raspberry Pi is now actually capable of running rather demanding Pure Data patches in (quasi-) real-time (at least with a latency that's low enough to play live with it). I quickly assembled a small patch to test it and make a video to demonstrate that it actually works very well. It is obviously not the use the RPi was originally intended for, but to me (and I'm sure to other musicians as well), this sounds like a revolution. I'm currently documenting my setup on my blog : - video : http://guitarextended.wordpress.com/2013/01/27/real-time-guitar-effects-with-raspberry-pi-pd-and-arduino/ - blog post about hardware : http://guitarextended.wordpress.com/2013/01/31/raspberry-pi-multi-effects-overview-of-the-setup/ There's no trick, the Pi really IS doing all the DSP work. A reader posted a comment to ask where the computer was :) I take this opportunity to thank the RPi foundation for all the good work you put in this amazing tiny thing. I see that the cam should be out in a few months, this is all very exciting. I'm sure the Pi has already changed the life of a lot of people ! Cheers, Pierre. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list 33D.gif___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Archlinux packages (was: enhance...)
maybe should be packaged as cwid-pd-l2ork. I have no time now. fk. 2013/2/9 michael noble loop...@gmail.com On Sat, Feb 9, 2013 at 9:02 PM, Fero Kiraly fero.kir...@gmail.com wrote: honestly I dont know where could be problem with compiling disis wiimote, on my system it builds. I just tried example disis_wiimote-help.pd and the object is not available. In console are errors: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote ... couldn't create /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote 00:19:1D:BE:6A:66 ... couldn't create /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote ... couldn't create /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: /usr/lib/pd-l2ork/extra/disis_wiimote.pd_linux: undefined symbol: cwiid_toggle_passthrough_mode disis_wiimote 00:19:1D:BE:6A:66 ... couldn't create ??? fk. On the l2ork website it states that there is a specific build of cwiid needed that is downloadable from the site. Ivica mentioned something about this in an earlier email as well, so I suspect it is the cause of the issue. -- Fero Kiraly www.cluster-ensemble.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gimbal lock solution?
I have 3 axis accelerometer and 3 axis orientation sensor in my device. So i can get 0 - 360 deg on X, Y and Z. When I draw in GEM a rectangle, I am able to rotate it with each of 3 axes, but only separately. When I try it with all three axes together it has strange movements, so I guess it has something with gimbal lock. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gimbal lock solution?
hello, rotateXYZ is doing : rotation X then rotation Y then rotation Z this is not the same than : rotation Z rotation Y rotation X So, depending on how works your orientation sensors, you could have to change the rotation order. you can try, using 3 rotateXYZ object. cheers c Le 09/02/2013 14:45, Fero Kiraly a écrit : I have 3 axis accelerometer and 3 axis orientation sensor in my device. So i can get 0 - 360 deg on X, Y and Z. When I draw in GEM a rectangle, I am able to rotate it with each of 3 axes, but only separately. When I try it with all three axes together it has strange movements, so I guess it has something with gimbal lock. ___ 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] gimbal lock solution?
I believe it is (unfortunately) not as simple as that. When you rotate with [rotateXYZ], the three axis are not always perpendicular to each other. For instance, if you set Y to 90, the X and the Z rotate around the same axis. However, the gyroscope (at least the one from Wiimote MotionPlus and most likely also the one from your phone) consists of three separate sensor which are perpendicular to each other at any time. If I understand Fero correctly, he would like to use the sensors so he can control an object in Gem that follows exactly the orientation of his phone. I also tried that once with a Wiimote and Gem but I couldn't wrap my head around the two concepts of [rotateXYZ] and the gyro sensors. Anyone enlightened might be able to shed some light on this confusion? Roman On Sam, 2013-02-09 at 15:18 +0100, Cyrille Henry wrote: hello, rotateXYZ is doing : rotation X then rotation Y then rotation Z this is not the same than : rotation Z rotation Y rotation X So, depending on how works your orientation sensors, you could have to change the rotation order. you can try, using 3 rotateXYZ object. cheers c Le 09/02/2013 14:45, Fero Kiraly a écrit : I have 3 axis accelerometer and 3 axis orientation sensor in my device. So i can get 0 - 360 deg on X, Y and Z. When I draw in GEM a rectangle, I am able to rotate it with each of 3 axes, but only separately. When I try it with all three axes together it has strange movements, so I guess it has something with gimbal lock. ___ 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] gimbal lock solution?
Roman, thank you, that is exactly what I mean. Google said to me that it has something with: kalman or complementary filter, gimbal lock, quaternions arithmetic with matrixes ( there I can use iemmatrix library) my input data are: accX, accY, accZ, pitch yaw, roll (from HTC desire) how to get this together ? fk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gimbal lock solution?
Le 09/02/2013 15:49, Fero Kiraly a écrit : Roman, thank you, that is exactly what I mean. Google said to me that it has something with: kalman or complementary filter, gimbal lock, quaternions arithmetic with matrixes ( there I can use iemmatrix library) translate/rotate/scale/shear are matrix operation! my input data are: accX, accY, accZ, pitch yaw, roll (from HTC desire) how to get this together ? use pitch, yaw, roll in 3 rotateXYZ and connect the 3 rotate object in the correct order. (not X, Y, Z, since it did not work) cheers c fk. ___ 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] gimbal lock solution?
Le 09/02/2013 15:39, Roman Haefeli a écrit : I believe it is (unfortunately) not as simple as that. When you rotate with [rotateXYZ], the three axis are not always perpendicular to each other. For instance, if you set Y to 90, the X and the Z rotate around the same axis. every rotation keep the 3 axes perpendicular. but rotateXYZ do 3 rotations, X, Y and Z, in this order. if you rotate 90° in Y, Z axe became what use to be the X axe. so rotation in Z after a 90° rotation in Y is the same than a rotation in X before the Y rotation. that's the gimbal lock. but after the Y rotation, a X rotation is not the same than a Z rotation. if you don't believe me, you can try : gemhead rotate X 0 Z rotate 0 90 0 cube X and Z are still (and will always be) perpendicular. However, the gyroscope (at least the one from Wiimote MotionPlus and most likely also the one from your phone) consists of three separate sensor which are perpendicular to each other at any time. If I understand Fero correctly, he would like to use the sensors so he can control an object in Gem that follows exactly the orientation of his phone. I also tried that once with a Wiimote and Gem but I couldn't wrap my head around the two concepts of [rotateXYZ] and the gyro sensors. gyro sensors give rotation speed. not absolute rotation. in theory (with infinite acurate sensors, no drift etc), you have to do a feedback loop (using gemlist_info), so that the current rotation is modify by the sensors value. (rotation did not sums up) cheers c Anyone enlightened might be able to shed some light on this confusion? Roman On Sam, 2013-02-09 at 15:18 +0100, Cyrille Henry wrote: hello, rotateXYZ is doing : rotation X then rotation Y then rotation Z this is not the same than : rotation Z rotation Y rotation X So, depending on how works your orientation sensors, you could have to change the rotation order. you can try, using 3 rotateXYZ object. cheers c Le 09/02/2013 14:45, Fero Kiraly a écrit : I have 3 axis accelerometer and 3 axis orientation sensor in my device. So i can get 0 - 360 deg on X, Y and Z. When I draw in GEM a rectangle, I am able to rotate it with each of 3 axes, but only separately. When I try it with all three axes together it has strange movements, so I guess it has something with gimbal lock. ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
GPUs are not made for very low latency processing of tiny chunks of data. Trying to run the GPU at 5k to 100k FPS on 256 bytes of data is not going to work well at all. Processing a few seconds of audio at once would show massive gains though. Just ask yourself - how many professional DAWs use the GPU to process their audio? Even the one sold by the company with full access to every part of the GPUs they put in their own computers? Also, I don't get the obsession with the Pi. There are now lots and lots of under $100 ARMv7 dual core (!) boards that run Linux and have way more I/O options. Why not get something not totally out of date to begin with? On Sat, Feb 9, 2013 at 7:51 AM, Pierre Massat pimas...@gmail.com wrote: Hi again Katja, I just read through it. Couldn't find anything about having the GPU process some audio. It's really mostly about why it's a bad (or good) thing to keep the GPU closed-source (at least that's what I understand [?]). So I guess there isn't must we can do on our own to access the GPU. But then, what can Eben and his team do about it ? I'd like to know what answer we can give him. If he says just waiting for an application like this I am assuming that it must have aroused his interest somehow. And I believe that it would be great if people in the Pd community got involved. All I can provide is some testing, but others could contribute more (if i'm not mistaken, Miller Puckette did a great job fixing the analog out for instance). I think we should try and play a part in the development of the Pi. And if we're lucky we'll finally have that Pd box people have been dreaming about for years. Cheers, Pierre. 2013/2/9 katja katjavet...@gmail.com Hi Pierre, There has been intensive discussion about GPU processing on RPI: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33t=6188 Did you read it? In the light of this discussion, I wonder what Eben means when writing We have a bunch of GPU compute available on the device just waiting for an application like this. Anyway it's great they have put your project on RPi blog. You will be famous, Pi Massat! Congrats again. Katja On Fri, Feb 8, 2013 at 10:51 AM, Pierre Massat pimas...@gmail.comwrote: Dear all, Please read below the message I received from Eben Upton, the boss of Raspberry Pi foundation. It looks like he was impressed by the video I made, and he says that there's a possibility of letting the GPU do some DSP computation. I guess you'll all agree that this is awesome news. I have no idea how we can proceed now. I think i'm absolutely incapable of doing anything useful in this field, so i told him that i would transfer this message to you, hoping that Miller, HC, Katja (and others) would know what needs to be done. We should probably ask him if you guys could work directly with their developers. Let me know what you think. Cheers! Pierre. -- Forwarded message -- From: Eben Upton e...@raspberrypi.org Date: 2013/2/8 Subject: Re: RPi as multi-effects for guitar To: Pierre Massat pimas...@gmail.com Hi Pierre Awesome stuff - I think Liz is preparing a blog post about this as we speak. I'd be very interested in knowing a bit more about the DSP code that runs this stuff. We have a bunch of GPU compute available on the device just waiting for an application like this. Cheers Eben On Thu, Feb 7, 2013 at 2:29 AM, Pierre Massat pimas...@gmail.com wrote: Hi, I write a blog about how to make guitar effects with computers running Pure Data in real-time. When I first heard about the Raspberry Pi I thought it would be great if I could use it for the same purpose. It would only be much cheaper, and much smaller than my current laptop, and could fit in my hand-made stompbox. Recent improvements in Raspbian have finally made this possible, and this makes me very happy ! The Raspberry Pi is now actually capable of running rather demanding Pure Data patches in (quasi-) real-time (at least with a latency that's low enough to play live with it). I quickly assembled a small patch to test it and make a video to demonstrate that it actually works very well. It is obviously not the use the RPi was originally intended for, but to me (and I'm sure to other musicians as well), this sounds like a revolution. I'm currently documenting my setup on my blog : - video : http://guitarextended.wordpress.com/2013/01/27/real-time-guitar-effects-with-raspberry-pi-pd-and-arduino/ - blog post about hardware : http://guitarextended.wordpress.com/2013/01/31/raspberry-pi-multi-effects-overview-of-the-setup/ There's no trick, the Pi really IS doing all the DSP work. A reader posted a comment to ask where the computer was :) I take this opportunity to thank the RPi foundation for all the good work you put in this amazing tiny thing. I see that the cam should be out in a few months, this is all very
Re: [PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
Just a comment on Chris's last point: Also, I don't get the obsession with the Pi. There are now lots and lots of under $100 ARMv7 dual core (!) boards that run Linux and have way more I/O options. Why not get something not totally out of date to begin with? My personal reasons for being attracted to the Pi are, 1, that it's vastly better engineered and supported than other linux+ARM solutions I've seen; and 2, although I'm not sure about this, it seems to dissipate much less power than ARMV7 soutions making it easier to make standalone gadgets with it. cheers Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
hi, the only realtime audio tool which use GPU I knew is the one from LiquidSonic http://www.liquidsonics.com it uses CUDA to compute reverb with convolution This is the only application I found when I was interested in 3 years ago for my master thesis but it was the very first steps of CUDA, maybe more audio applications are available now, but I didn't heart and this tool works with a NVIDIA Geforce 8, far from RPi's GPU... cheers a -- do it yourself http://antoine.villeret.free.fr 2013/2/9 chris clepper cgclep...@gmail.com GPUs are not made for very low latency processing of tiny chunks of data. Trying to run the GPU at 5k to 100k FPS on 256 bytes of data is not going to work well at all. Processing a few seconds of audio at once would show massive gains though. Just ask yourself - how many professional DAWs use the GPU to process their audio? Even the one sold by the company with full access to every part of the GPUs they put in their own computers? Also, I don't get the obsession with the Pi. There are now lots and lots of under $100 ARMv7 dual core (!) boards that run Linux and have way more I/O options. Why not get something not totally out of date to begin with? On Sat, Feb 9, 2013 at 7:51 AM, Pierre Massat pimas...@gmail.com wrote: Hi again Katja, I just read through it. Couldn't find anything about having the GPU process some audio. It's really mostly about why it's a bad (or good) thing to keep the GPU closed-source (at least that's what I understand [?]). So I guess there isn't must we can do on our own to access the GPU. But then, what can Eben and his team do about it ? I'd like to know what answer we can give him. If he says just waiting for an application like this I am assuming that it must have aroused his interest somehow. And I believe that it would be great if people in the Pd community got involved. All I can provide is some testing, but others could contribute more (if i'm not mistaken, Miller Puckette did a great job fixing the analog out for instance). I think we should try and play a part in the development of the Pi. And if we're lucky we'll finally have that Pd box people have been dreaming about for years. Cheers, Pierre. 2013/2/9 katja katjavet...@gmail.com Hi Pierre, There has been intensive discussion about GPU processing on RPI: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33t=6188 Did you read it? In the light of this discussion, I wonder what Eben means when writing We have a bunch of GPU compute available on the device just waiting for an application like this. Anyway it's great they have put your project on RPi blog. You will be famous, Pi Massat! Congrats again. Katja On Fri, Feb 8, 2013 at 10:51 AM, Pierre Massat pimas...@gmail.comwrote: Dear all, Please read below the message I received from Eben Upton, the boss of Raspberry Pi foundation. It looks like he was impressed by the video I made, and he says that there's a possibility of letting the GPU do some DSP computation. I guess you'll all agree that this is awesome news. I have no idea how we can proceed now. I think i'm absolutely incapable of doing anything useful in this field, so i told him that i would transfer this message to you, hoping that Miller, HC, Katja (and others) would know what needs to be done. We should probably ask him if you guys could work directly with their developers. Let me know what you think. Cheers! Pierre. -- Forwarded message -- From: Eben Upton e...@raspberrypi.org Date: 2013/2/8 Subject: Re: RPi as multi-effects for guitar To: Pierre Massat pimas...@gmail.com Hi Pierre Awesome stuff - I think Liz is preparing a blog post about this as we speak. I'd be very interested in knowing a bit more about the DSP code that runs this stuff. We have a bunch of GPU compute available on the device just waiting for an application like this. Cheers Eben On Thu, Feb 7, 2013 at 2:29 AM, Pierre Massat pimas...@gmail.com wrote: Hi, I write a blog about how to make guitar effects with computers running Pure Data in real-time. When I first heard about the Raspberry Pi I thought it would be great if I could use it for the same purpose. It would only be much cheaper, and much smaller than my current laptop, and could fit in my hand-made stompbox. Recent improvements in Raspbian have finally made this possible, and this makes me very happy ! The Raspberry Pi is now actually capable of running rather demanding Pure Data patches in (quasi-) real-time (at least with a latency that's low enough to play live with it). I quickly assembled a small patch to test it and make a video to demonstrate that it actually works very well. It is obviously not the use the RPi was originally intended for, but to me (and I'm sure to other musicians as well), this sounds like a revolution. I'm currently documenting my setup on my blog : - video :
Re: [PD] New 0.43-4--Pd-extended GEM Error
Le 08/02/2013 22:05, Pagano, Patrick a écrit : When Running Gem in 0.43.4-extended on Windows 7 64 bit I gets L: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant How do I remedy this? Patrick Pagano, B.S, M.F.A Assistant in Digital Arts and Science Digital Media Projection and Audio Design Digital Worlds Institute University of Florida, USA (352)294-2020 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Hello Patrick, I guess you opened a patch with Gem content inside ? Is it possible to get it on this list ? This message can come from different problem on different system/driver. ++ Jack ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
Just as a side-note, and although this does not seem feasible on the RPi (at least yet), anybody generally interested in audio DSP on GPUs may want to have a look at: Savoija, Lauri, Vesa Valimaki, and Julius O. Smith. Audio Signal Processing Using Graphics Processing Units. *Journal of the Audio Engineering Society* 59.1-2 (2011): 3-19. In my experience, doing scientific computations by tricking a GPU into thinking that it's processing graphics (e.g. by using OpenGL), is quite painful. So in the absence of an official framework like OpenCL or CUDA, which provides a relatively simple means of abusing a GPU, chasing this one on the RPi would be a nightmare... Cheers, Jon. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
From: Jonathan Sheaffer j...@jonsh.net To: pd-list@iem.at Sent: Saturday, February 9, 2013 12:55 PM Subject: [PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !) [...] In my experience, doing scientific computations by tricking a GPU into thinking that it's processing graphics (e.g. by using OpenGL), is quite painful. https://en.bitcoin.it/wiki/Mining_rig -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
Le 09/02/2013 18:55, Jonathan Sheaffer a écrit : Just as a side-note, and although this does not seem feasible on the RPi (at least yet), anybody generally interested in audio DSP on GPUs may want to have a look at: Savoija, Lauri, Vesa Valimaki, and Julius O. Smith. Audio Signal Processing Using Graphics Processing Units. /Journal of the Audio Engineering Society/ 59.1-2 (2011): 3-19. In my experience, doing scientific computations by tricking a GPU into thinking that it's processing graphics (e.g. by using OpenGL), is quite painful. So in the absence of an official framework like OpenCL or CUDA, which provides a relatively simple means of abusing a GPU, chasing this one on the RPi would be a nightmare... if your application can profit from parallel processing, and if you can run shaders, then GPGPU is not so complex. one can also have a look at Gem example : 10.glsl/10.GPGPU this will however not run on the pi. cheers c Cheers, Jon. ___ 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] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
- Original Message - From: Miller Puckette m...@ucsd.edu To: chris clepper cgclep...@gmail.com Cc: pd-list pd-list@iem.at Sent: Saturday, February 9, 2013 11:51 AM Subject: Re: [PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !) Just a comment on Chris's last point: Also, I don't get the obsession with the Pi. There are now lots and lots of under $100 ARMv7 dual core (!) boards that run Linux and have way more I/O options. Why not get something not totally out of date to begin with? My personal reasons for being attracted to the Pi are, 1, that it's vastly better engineered and supported than other linux+ARM solutions I've seen; and 2, although I'm not sure about this, it seems to dissipate much less power than ARMV7 soutions making it easier to make standalone gadgets with it. So are there low-cost battery packs made to go with it that are plug and go? From what I read it sounds really tricky. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Message from the boss of Raspberry Pi Foundation ! (Jon)
i read that whole discussion thread on the RPi board, and based on that it certainly sounds murky at best that GPU processing is going to become a reality on the RPi anytime soon, without Broadcom's support/permission. JamesH, one of their main hardware dev guys, seems pretty determined you can't reverse engineer video code, and everyone else seems to have stars in their eyes about it. agreed, the idea that Eben might be working on some pathways to doing this by getting Broadcom to agree to opening up certain pathways to processing via the GPU is a very tantalizing prospect. someone should press on him a bit regarding this... scott On Sat, Feb 9, 2013 at 4:57 AM, Pierre Massat pimas...@gmail.com wrote: Hi Jon, Thank you for your insight, and welcome in the list ! I personnally think that for most real-time application (like the guitar effects processor i'm using), a latency equal à below 10 to 8 ms is definitely acceptable (especially considering the price). I could imagine many applications for other instruments that would work just fine with such a latency. Pd currently works fine with no GUI at 10 ms, with simple patches. One has to increase the latency to 16 ms (maybe more for very heavy patches) if one needs to do some fft or other demanding stuff (i used a phase vocoder in my video). So if using the GPU for DSP doesn't reduce latency, but allows for bigger patches, it's already great news. Cheers, Pierre. 2013/2/9 Jonathan Sheaffer j...@jonsh.net Hi All, I've been a silent observer for some time now, but since GPU processing is 'close to my heart', I thought I'd jump in... So there goes my first post in the pd-list... In general, GPUs are really beneficial for parallelisable algorithms involving heavy-computations, such as FFTs, fast convolution, BLAS with huge matrices, finite difference modelling etc... To maximise performance, the GPU kernel needs to unanimously operate over a large enough data set which needs to be copied into the device's memory, as GPUs generally can't access the host memory. This would mean large buffers -- increased latency. So doing 'real-time' DSP on a GPU would probably make more sense for stuff like physical modelling, complex additive synthesis etc..., rather than to 'generally reduce the system latency'. *However*, if the SoC platform physically shares memory between the GPU and the CPU, then this could, in theory, help reduce the inherent latency (as no memory transfers would be required), but without having detailed documentation, this would be difficult to assess. Cheers, Jon. www.jonsh.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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] xensynth9.01.7
http://www.geocities.ws/billy_stiltner/music/pd/xensynth9.01.7.zip it ought to load and play with the builtin virtual keyboard on windows without having midi routed. done some stuff with the delay and other stuff i don't remember at the moment. recording done today testing out microphone to velocity on a real noisy soundcard https://soundcloud.com/andromedapulley/bpe3r2u the microphone to velocity is not connected in the dwnload you can figure it out ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
I/O options. Why not get something not totally out of date to begin with? My personal reasons for being attracted to the Pi are, 1, that it's vastly better engineered and supported than other linux+ARM solutions I've seen; and 2, although I'm not sure about this, it seems to dissipate much less power than ARMV7 soutions making it easier to make standalone gadgets with it. So are there low-cost battery packs made to go with it that are plug and go? From what I read it sounds really tricky. -Jonathan I don't know what specifically people are doig, just that there are projects popping up all the time in which people use Pis in autonomous devices that fly or drive around. I'm actually planneng to give this a first try myself tomorrow at Crashspace in LA (http://blog.crashspace.org/ - second posting down) - but I'll be borrowing a battery pack from Joe Deken of New Blankets who's helping instigate the event. cheers Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gimbal lock solution?
On Sam, 2013-02-09 at 16:41 +0100, Cyrille Henry wrote: Le 09/02/2013 15:39, Roman Haefeli a écrit : I believe it is (unfortunately) not as simple as that. When you rotate with [rotateXYZ], the three axis are not always perpendicular to each other. For instance, if you set Y to 90, the X and the Z rotate around the same axis. every rotation keep the 3 axes perpendicular. but rotateXYZ do 3 rotations, X, Y and Z, in this order. if you rotate 90° in Y, Z axe became what use to be the X axe. so rotation in Z after a 90° rotation in Y is the same than a rotation in X before the Y rotation. that's the gimbal lock. but after the Y rotation, a X rotation is not the same than a Z rotation. if you don't believe me, you can try : gemhead rotate X 0 Z rotate 0 90 0 cube X and Z are still (and will always be) perpendicular. Ok, this makes sense to me now. Thanks. However, the gyroscope (at least the one from Wiimote MotionPlus and most likely also the one from your phone) consists of three separate sensor which are perpendicular to each other at any time. If I understand Fero correctly, he would like to use the sensors so he can control an object in Gem that follows exactly the orientation of his phone. I also tried that once with a Wiimote and Gem but I couldn't wrap my head around the two concepts of [rotateXYZ] and the gyro sensors. gyro sensors give rotation speed. not absolute rotation. Yeah, right. But you can add the values up to get rotation (of course, it's always rotation relative to itself, which will obviously drift from reality over time). in theory (with infinite acurate sensors, no drift etc), you have to do a feedback loop (using gemlist_info), so that the current rotation is modify by the sensors value. (rotation did not sums up) ...parsing solution beep.. stack overflow (in my head)! You mean you add each increment (gyro measurement) to the rotation separately, then get the orientation with gem_list info, add the next increment to the orientation, get orientation again, add increment etc? Can you cast that into a little Gem example patch, if it is not too much trouble? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] New 0.43-4--Pd-extended GEM Error
It's every Gem patch. Sent from my iPhone On Feb 9, 2013, at 12:27 PM, Jack j...@rybn.orgmailto:j...@rybn.org wrote: Le 08/02/2013 22:05, Pagano, Patrick a écrit : When Running Gem in 0.43.4-extended on Windows 7 64 bit I gets L: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant GL: invalid enumerant How do I remedy this? Patrick Pagano, B.S, M.F.A Assistant in Digital Arts and Science Digital Media Projection and Audio Design Digital Worlds Institute University of Florida, USA (352)294-2020 ___ Pd-list@iem.atmailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Hello Patrick, I guess you opened a patch with Gem content inside ? Is it possible to get it on this list ? This message can come from different problem on different system/driver. ++ Jack ___ Pd-list@iem.atmailto: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] Message from the boss of Raspberry Pi Foundation !
Dear all I know 2 works on GPU and PD. André developed something with PD and GPU. http://www.ime.usp.br/~ajb/wiki/artigos/article-icmc2012-ajb-mqz.pdf Chuck (Charles Henry) also developed something and he helped Andre to develop his code. http://www.uni-weimar.de/medien/wiki/PDCON:Conference/GPU_audio_signals_processing_in_Pd,_and_PDCUDA,_an_implementation_with_the_CUDA_runtime_API AFAIK, there is a lib that allows you to copy the processing functions to GPU pipeline and the data to be processed. This lib can identify if there is a GPU available in the system and present the information about it. I think that it really would be a good thing to DSP processing on RPI. Bests F Schiavoni @Hardoff : the patch i'm using in the video requires 16 ms of latency, because it uses phase vocoding. You can drop to 10 ms without it, and I guess even lower would be possible. I use the very first version of the Pi, with half the RAM the new model has. If we can get the GPU to compute the audio i hope that we'll be able to get to really reasonable latencies (to me 6 to 8 ms is really enough to play live). Also, i use the regular Pd fro the debian repos. I can't tell you whether Miller's or Katja's version work better. Cheers, Piere. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: absolute vs relative filepath on oggread~
On 02/08/2013 05:32 PM, Jonathan Wilkes wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: 'Hans-Christoph Steiner' h...@at.or.at; pd-list@iem.at Cc: Sent: Friday, February 8, 2013 4:18 PM Subject: Re: [PD] Fwd: absolute vs relative filepath on oggread~ But it doesn't give you the name of the patch itself (which could be useful for auto-naming files associated with the patch, e.g. soundfiles). L2ORk's patch_name does everything getdir does (optional argument traverses structure upwards to provide you with info of patches/abstractions above it) plus gives you the patch name. So does canvasinfo: http://article.gmane.org/gmane.comp.multimedia.puredata.devel/11601/match=classinfo with a bang method that prints all the canvas attributes to the console for quick reference. Way easier for the user since each attribute is a method within a single object, with a standard interface (and if more attributes are needed it's trivial to add them without breaking anything). Also easier to develop, as adding another attribute is as simple as adding a method (as opposed to copy/pasting yet another external class, which is the equivalent of copy/pasting subpatches instead of learning to use abstractions in Pd). -Jonathan This has been added to pd-l2ork git... -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio 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] japanese language and text3d
Hello I hav a big problem : I have read thread about the integration of language in text3d but it does not work I try to use [number I [string( I [text3d] but I have no result in the other languages than english or french. I try to use japanese and no result too ? I m in OSX 10.7.5 and 43.4 for pd-extended Do you know where is the problem ? philippe ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Message from the boss of Raspberry Pi Foundation !
On Fri, Feb 8, 2013 at 5:38 AM, Marco Donnarumma de...@thesaddj.com wrote: That's awesome Pierre! Charles (Henry) was working on GPU related computation with Pd. Some pretty cool stuff. It would be relevant to see how his work developed so far, and whether it might be useful in this context. My priorities have been sliding around. The development stopped at inlets and outlets dsp perform and resampling functions, but that's the last big hurdle. Good thing is that it's relatively trivial to make a external that transfers data to the GPU, performs some processing, and transfers data back. If you've already got GPU code and just want to pack it inside an external, that's no problem to do. Chuck ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
