Re: [PD] Max's [rate~] implementation...
On 06/12/12 14:57, Alexandros Drymonitis wrote: copy this patch http://www.youtube.com/watch?v=6P4Ezz9aWa8feature=plcp If I may suggest... I would try to observe and _listen_ to what the patch produces, and then try to re-produce it not necessarily making an exact copy, but your own personalised version which you think sounds great :) Ciao, Lorenzo. On Thu, Dec 6, 2012 at 3:55 PM, Simon Iten itensi...@gmail.com mailto:itensi...@gmail.com wrote: What are you trying to accomplish? On Dec 6, 2012 2:48 PM, Alexandros Drymonitis adr...@gmail.com mailto:adr...@gmail.com wrote: How can one implement Max's [rate~] in Pd? [rate~] takes a signal from a [phasor~] and according to its argument it scales the frequency (roughly speaking). So [phasor~ 1] | [rate~ 1.5] will actually give a [phasor~ 1.5]. I thought of [wrap] but that won't do the trick with non-integers. Any ideas? ___ Pd-list@iem.at mailto: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] Pd on the Pi : Miller's version
Hi Miller, Thank for your reply. This is the thread that made me ask for an update here. Cheers, Pierre. 2012/12/6 Miller Puckette m...@ucsd.edu Hi all - Here's the thread: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66t=19155p=218405#p218405 ... and the upshot is you have to slow USB down to 1.1 (instead of the default 2.0) to get correct audio input. The version of Pd I've uploaded (http://crca.ucsd.edu/~msp/software.html) is much newer than the stock one that apt-get installs; OTOH the apt-get one is Pd extended and mine is only vanilla. cheers Miller On Thu, Dec 06, 2012 at 10:28:33AM -0500, me.grimm wrote: I came upon a thread where he talks about his attempt to get audio in working, wheres the thread? I would also like to know if anybody has some feedback to give about audio in, it still sounds like shit on my end. what hardware are you using? i see there has been some improvements on the USB drivers recently. maybe that will be fixed soon and the issues with audio in will improve? i would also like to know if anyone has it working well... been a while since these pi threads were started on this list a few months back. maybe someone has made head way... m On Thu, Dec 6, 2012 at 6:06 AM, Pierre Massat pimas...@gmail.com wrote: Dear list, I know that Miller Puckette has been working on improving Pd on the RPi lately, and I came upon a thread where he talks about his attempt to get audio in working, and mentioned his version of Pd compiled for the RPi. I would like to know in which respects it is different from the vanilla version one can grab from the Raspbian repository. I would also like to know if anybody has some feedback to give about audio in, and specially about the latency that can be achieved (and whether there is room for improvement or not). In short : an update on Pd on the Pi ? Cheers, Pierre. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ 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] Max's [rate~] implementation...
On 06/12/12 15:31, Hans-Christoph Steiner wrote: Leaving out [rate~] should use less CPU since [rate~] doesn't have to do the analysis part, if I understand it correctly. If I understand correctly what rate~ does, the argument is actually a factor, so I thnk the frequency for the phasor~ has to be 1 / factor... So for example [rate~ 1.5] is [phasor~ 0.67] Lorenzo. .hc On Dec 6, 2012, at 9:24 AM, Alexandros Drymonitis wrote: Don't think I really follow. Each [rate~] actually outputs a [phasor~] with a different frequency (different frequency ratio), all driven by the same [phasor~]. How can you send a value from one number box to all [phasor~]s? On Thu, Dec 6, 2012 at 4:18 PM, Hans-Christoph Steiner h...@at.or.at mailto:h...@at.or.at wrote: Why not just use a phasor~ per rate~ and then have the frequency of all them controlled by the same number box? .hc On Dec 6, 2012, at 8:57 AM, Alexandros Drymonitis wrote: copy this patch http://www.youtube.com/watch?v=6P4Ezz9aWa8feature=plcp On Thu, Dec 6, 2012 at 3:55 PM, Simon Iten itensi...@gmail.com mailto:itensi...@gmail.com wrote: What are you trying to accomplish? On Dec 6, 2012 2:48 PM, Alexandros Drymonitis adr...@gmail.com mailto:adr...@gmail.com wrote: How can one implement Max's [rate~] in Pd? [rate~] takes a signal from a [phasor~] and according to its argument it scales the frequency (roughly speaking). So [phasor~ 1] | [rate~ 1.5] will actually give a [phasor~ 1.5]. I thought of [wrap] but that won't do the trick with non-integers. Any ideas? ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailto: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] Max's [rate~] implementation...
On Fri, Dec 7, 2012 at 2:12 PM, Lorenzo Sutton lorenzofsut...@gmail.comwrote: On 06/12/12 15:31, Hans-Christoph Steiner wrote: Leaving out [rate~] should use less CPU since [rate~] doesn't have to do the analysis part, if I understand it correctly. If I understand correctly what rate~ does, the argument is actually a factor, so I thnk the frequency for the phasor~ has to be 1 / factor... So for example [rate~ 1.5] is [phasor~ 0.67] Lorenzo. rate~ accepts an input signal from a phasor~ and time scales it by a multiplier received as a float in its right inlet. This is what the help patch says. Although, in the oscilloscope of the patch it looks like it is divided indeed. Dunno.. .hc On Dec 6, 2012, at 9:24 AM, Alexandros Drymonitis wrote: Don't think I really follow. Each [rate~] actually outputs a [phasor~] with a different frequency (different frequency ratio), all driven by the same [phasor~]. How can you send a value from one number box to all [phasor~]s? On Thu, Dec 6, 2012 at 4:18 PM, Hans-Christoph Steiner h...@at.or.atmailto: h...@at.or.at wrote: Why not just use a phasor~ per rate~ and then have the frequency of all them controlled by the same number box? .hc On Dec 6, 2012, at 8:57 AM, Alexandros Drymonitis wrote: copy this patch http://www.youtube.com/watch?**v=6P4Ezz9aWa8feature=plcphttp://www.youtube.com/watch?v=6P4Ezz9aWa8feature=plcp On Thu, Dec 6, 2012 at 3:55 PM, Simon Iten itensi...@gmail.com mailto:itensi...@gmail.com wrote: What are you trying to accomplish? On Dec 6, 2012 2:48 PM, Alexandros Drymonitis adr...@gmail.com mailto:adr...@gmail.com wrote: How can one implement Max's [rate~] in Pd? [rate~] takes a signal from a [phasor~] and according to its argument it scales the frequency (roughly speaking). So [phasor~ 1] | [rate~ 1.5] will actually give a [phasor~ 1.5]. I thought of [wrap] but that won't do the trick with non-integers. Any ideas? __**_ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list __**_ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list 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://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] Max's [rate~] implementation...
multiplying by 0.5 is the same as dividing by 2 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max's [rate~] implementation...
Yes, but 1 * 1.5 should give 1.5 and not 0.67. As you suggest, [rate~ 1.5] should give [phasor~ 0.67], which in the case of multiplication shouldn't be true. But still, that how it looks like in the oscilloscope... On Fri, Dec 7, 2012 at 3:42 PM, i go bananas hard@gmail.com wrote: multiplying by 0.5 is the same as dividing by 2 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd on the Pi : Miller's version
... and I just tried to do the USB slowdown trick again with a newer install and it... fails to upen any USB devices at all! So we're not out of the woods yet after all. cheers M On Fri, Dec 07, 2012 at 11:37:06AM +0100, Pierre Massat wrote: Hi Miller, Thank for your reply. This is the thread that made me ask for an update here. Cheers, Pierre. 2012/12/6 Miller Puckette m...@ucsd.edu Hi all - Here's the thread: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66t=19155p=218405#p218405 ... and the upshot is you have to slow USB down to 1.1 (instead of the default 2.0) to get correct audio input. The version of Pd I've uploaded (http://crca.ucsd.edu/~msp/software.html) is much newer than the stock one that apt-get installs; OTOH the apt-get one is Pd extended and mine is only vanilla. cheers Miller On Thu, Dec 06, 2012 at 10:28:33AM -0500, me.grimm wrote: I came upon a thread where he talks about his attempt to get audio in working, wheres the thread? I would also like to know if anybody has some feedback to give about audio in, it still sounds like shit on my end. what hardware are you using? i see there has been some improvements on the USB drivers recently. maybe that will be fixed soon and the issues with audio in will improve? i would also like to know if anyone has it working well... been a while since these pi threads were started on this list a few months back. maybe someone has made head way... m On Thu, Dec 6, 2012 at 6:06 AM, Pierre Massat pimas...@gmail.com wrote: Dear list, I know that Miller Puckette has been working on improving Pd on the RPi lately, and I came upon a thread where he talks about his attempt to get audio in working, and mentioned his version of Pd compiled for the RPi. I would like to know in which respects it is different from the vanilla version one can grab from the Raspbian repository. I would also like to know if anybody has some feedback to give about audio in, and specially about the latency that can be achieved (and whether there is room for improvement or not). In short : an update on Pd on the Pi ? Cheers, Pierre. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ 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] Pd on the Pi : Miller's version
yeah i was having the same trouble the couple times i tried this a month or so ago. no USB devices. did you have it work for you miller on prior raspbian image? i remember having to mount the sd card on m laptop to remove that cmdtxt line to get my keyboard/mouse back but then gave up on the whole usb 1.1 speed thing. m On Fri, Dec 7, 2012 at 12:33 PM, Miller Puckette m...@ucsd.edu wrote: ... and I just tried to do the USB slowdown trick again with a newer install and it... fails to upen any USB devices at all! So we're not out of the woods yet after all. cheers M On Fri, Dec 07, 2012 at 11:37:06AM +0100, Pierre Massat wrote: Hi Miller, Thank for your reply. This is the thread that made me ask for an update here. Cheers, Pierre. 2012/12/6 Miller Puckette m...@ucsd.edu Hi all - Here's the thread: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66t=19155p=218405#p218405 ... and the upshot is you have to slow USB down to 1.1 (instead of the default 2.0) to get correct audio input. The version of Pd I've uploaded ( http://crca.ucsd.edu/~msp/software.html) is much newer than the stock one that apt-get installs; OTOH the apt-get one is Pd extended and mine is only vanilla. cheers Miller On Thu, Dec 06, 2012 at 10:28:33AM -0500, me.grimm wrote: I came upon a thread where he talks about his attempt to get audio in working, wheres the thread? I would also like to know if anybody has some feedback to give about audio in, it still sounds like shit on my end. what hardware are you using? i see there has been some improvements on the USB drivers recently. maybe that will be fixed soon and the issues with audio in will improve? i would also like to know if anyone has it working well... been a while since these pi threads were started on this list a few months back. maybe someone has made head way... m On Thu, Dec 6, 2012 at 6:06 AM, Pierre Massat pimas...@gmail.com wrote: Dear list, I know that Miller Puckette has been working on improving Pd on the RPi lately, and I came upon a thread where he talks about his attempt to get audio in working, and mentioned his version of Pd compiled for the RPi. I would like to know in which respects it is different from the vanilla version one can grab from the Raspbian repository. I would also like to know if anybody has some feedback to give about audio in, and specially about the latency that can be achieved (and whether there is room for improvement or not). In short : an update on Pd on the Pi ? Cheers, Pierre. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Patch bugged on pd-extended 0.43.4
Hum.. I'm using 0.42.5 installed version, and when I try to use 0.43.4
portable version, 0.42.5 stop to load libraries... When I try to use the
pd-settings to fix the library load, I don't have sucess.
Now I only can open my patchs with 0.42.5 running in administrator mode...
:(...
Some suggestion to fix that?? Delete manually with regedit pd-something??
2012/12/7 Hans-Christoph Steiner h...@at.or.at
If you download the zip build, then you can run it without installing it
at all by double-clicking the 'pd-extended.bat file thats included there.
.hc
On Dec 6, 2012, at 8:36 PM, Esteban Viveros wrote:
Pd libraries can't be loaded... I tried tge pd-settings.reg , but I only
can run pd 0.42.5 with libraries on administrator mode.. :/
2012/12/6 Hans-Christoph Steiner h...@at.or.at
Ok, one more fix, this time I think I found the problem with your patch.
There is an [image] that has no file or image name in it. It used to be
invisible and create that error sometimes. I now made [image] throw an
error and use a filler image when no image is specified.
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16650
.hc
On Dec 5, 2012, at 6:42 PM, Esteban Viveros wrote:
hc. , I have the same error.. I tried Pd-0.43.4-extended-20121205
version, on Linux and on Windows 7 Home Premium x64...
2012/12/5 Hans-Christoph Steiner h...@at.or.at
And back to the original problem. I am pretty sure I fixed the image
UNHANDLED ERROR problem with these commits:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16648
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16649
try tomorrow's build and let me know.
.hc
On Dec 4, 2012, at 3:59 PM, Esteban Viveros wrote:
I tried the zip version... And it don't work yet.. I have the message:
(Tcl) UNHANDLED ERROR: couldn't open
C:/Users/Esteban/Desktop/Square/: permission denied
while executing
image create photo img1eb1948 -file
{C:/Users/Esteban/Desktop/Square/}
(uplevel body line 189)
invoked from within
uplevel #0 $cmds_from_pd
And now I have another mather... Pd-extended 0.42.5 can't load the pd
extended library... :/
On 0.42.5 I have when I start it:
[import] $Revision: 1.2 $
[import] is still in development, the interface could change!
compiled against Pd version 0.42.5
GEM: Graphics Environment for Multimedia
GEM: ver: 0.92.3
GEM: compiled: Mar 15 2010
GEM: maintained by IOhannes m zmoelnig
GEM: Authors : Mark Danks (original version)
GEM: Chris Clepper
GEM: Cyrille Henry
GEM: IOhannes m zmoelnig
GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle,
Hans-Christop Steiner, et al.
GEM: found a bug? miss a feature? please report it:
GEM: homepage http://gem.iem.at/
GEM: bug-tracker http://sourceforge.net/projects/pd-gem/
GEM: mailing-list http://lists.puredata.info/listinfo/gem-dev/
GEM: compiled for SIMD architecture: SSE2 MMX
GEM: using SSE2 optimization
Gem Man: QT init OK
cyclone: can't load library
zexy: can't load library
creb: can't load library
cxc: can't load library
iemlib: can't load library
list-abs: can't load library
mapping: can't load library
markex: can't load library
maxlib: can't load library
mjlib: can't load library
motex: can't load library
oscx: can't load library
pddp: can't load library
pdogg: can't load library
pmpd: can't load library
sigpack: can't load library
smlib: can't load library
unauthorized: can't load library
pan: can't load library
hcs: can't load library
jmmmp: can't load library
ext13: can't load library
ggee: can't load library
iem_anything: can't load library
ekext: can't load library
flatgui: can't load library
chaos: can't load library
2012/12/4 Hans-Christoph Steiner h...@at.or.at
I think I fixed that recently, try today's build:
http://puredata.info/downloads/pd-extended/releases/0.43.4
.hc
On Dec 4, 2012, at 2:39 AM, Esteban Viveros wrote:
I tried to open this patch on pd-extended 0.43.4 but they open very
bugged... No cords..
On pd-extended 0.42.5 they are working well..
Something to do??
--
Esteban Viveros
(27) 8815 7170
(27) 3066 0359
(11) 95761 4125
(11) 2738 7868
www.bandpage.com/estebanviveros
https://www.facebook.com/estebanviveros.art
http://www.papodecompositor-es.blogspot.com.br/
http://expurgacao.art.br/
quadrada_e_pulso.pd___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
--
Esteban Viveros
(27) 8815 7170
(27) 3066 0359
(11) 95761 4125
(11) 2738 7868
www.bandpage.com/estebanviveros
https://www.facebook.com/estebanviveros.art
[PD] graph on parent problem?
I have an array in a subpatch, when I applied graph-on-parent property to the subpatch (to view the array which holds sound so could be fairly large) Pd didn't like that. With dsp off it worked fine but when I turn dsp on Pd becames unusably slow to react (sliders, etc.). I was able to solve the problem by removing the graph-on-parent option. So it seems there is something in the interaction of graph-on-parent and the sound engine. this is on a planetCCRMA system: FC17 PD0.42-5extended Anyone else encounter such a problem? Any solution (beside moving things outside subpatches)? Thanks Oded ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] graph on parent problem?
If I understood your problem correctly, this might be because pd redraws array contents very inefficiently, so if you are constantly changing array contents that can prove quite cpu intensive. Similarly, moving such gop patch requires complete redraw of all its contents. Pd-l2ork fixes latter problem by moving such structures via tag, rather than redrawing everything (so in pd-l2ork moving such gop structure would be one instead of potentially thousands of commands), but the former problem is something that can be only solved by rewriting or getting rid of the networked gui-dsp communication protocol. On Dec 7, 2012 3:43 PM, Oded Ben-Tal o...@ccrma.stanford.edu wrote: I have an array in a subpatch, when I applied graph-on-parent property to the subpatch (to view the array which holds sound so could be fairly large) Pd didn't like that. With dsp off it worked fine but when I turn dsp on Pd becames unusably slow to react (sliders, etc.). I was able to solve the problem by removing the graph-on-parent option. So it seems there is something in the interaction of graph-on-parent and the sound engine. this is on a planetCCRMA system: FC17 PD0.42-5extended Anyone else encounter such a problem? Any solution (beside moving things outside subpatches)? Thanks Oded __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list 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] Patch bugged on pd-extended 0.43.4
You can delete the registry settings for Pd-extended in:
HKEY_LOCAL_MACHINE SOFTWARE Pd-extended
The portable version might still write to the registry if you change the
preferences.
.hc
On Dec 7, 2012, at 3:14 PM, Esteban Viveros wrote:
Hum.. I'm using 0.42.5 installed version, and when I try to use 0.43.4
portable version, 0.42.5 stop to load libraries... When I try to use the
pd-settings to fix the library load, I don't have sucess.
Now I only can open my patchs with 0.42.5 running in administrator mode...
:(...
Some suggestion to fix that?? Delete manually with regedit pd-something??
2012/12/7 Hans-Christoph Steiner h...@at.or.at
If you download the zip build, then you can run it without installing it at
all by double-clicking the 'pd-extended.bat file thats included there.
.hc
On Dec 6, 2012, at 8:36 PM, Esteban Viveros wrote:
Pd libraries can't be loaded... I tried tge pd-settings.reg , but I only can
run pd 0.42.5 with libraries on administrator mode.. :/
2012/12/6 Hans-Christoph Steiner h...@at.or.at
Ok, one more fix, this time I think I found the problem with your patch.
There is an [image] that has no file or image name in it. It used to be
invisible and create that error sometimes. I now made [image] throw an
error and use a filler image when no image is specified.
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16650
.hc
On Dec 5, 2012, at 6:42 PM, Esteban Viveros wrote:
hc. , I have the same error.. I tried Pd-0.43.4-extended-20121205 version,
on Linux and on Windows 7 Home Premium x64...
2012/12/5 Hans-Christoph Steiner h...@at.or.at
And back to the original problem. I am pretty sure I fixed the image
UNHANDLED ERROR problem with these commits:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16648
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16649
try tomorrow's build and let me know.
.hc
On Dec 4, 2012, at 3:59 PM, Esteban Viveros wrote:
I tried the zip version... And it don't work yet.. I have the message:
(Tcl) UNHANDLED ERROR: couldn't open C:/Users/Esteban/Desktop/Square/:
permission denied
while executing
image create photo img1eb1948 -file {C:/Users/Esteban/Desktop/Square/}
(uplevel body line 189)
invoked from within
uplevel #0 $cmds_from_pd
And now I have another mather... Pd-extended 0.42.5 can't load the pd
extended library... :/
On 0.42.5 I have when I start it:
[import] $Revision: 1.2 $
[import] is still in development, the interface could change!
compiled against Pd version 0.42.5
GEM: Graphics Environment for Multimedia
GEM: ver: 0.92.3
GEM: compiled: Mar 15 2010
GEM: maintained by IOhannes m zmoelnig
GEM: Authors : Mark Danks (original version)
GEM: Chris Clepper
GEM: Cyrille Henry
GEM: IOhannes m zmoelnig
GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle,
Hans-Christop Steiner, et al.
GEM: found a bug? miss a feature? please report it:
GEM: homepage http://gem.iem.at/
GEM: bug-tracker http://sourceforge.net/projects/pd-gem/
GEM: mailing-list http://lists.puredata.info/listinfo/gem-dev/
GEM: compiled for SIMD architecture: SSE2 MMX
GEM: using SSE2 optimization
Gem Man: QT init OK
cyclone: can't load library
zexy: can't load library
creb: can't load library
cxc: can't load library
iemlib: can't load library
list-abs: can't load library
mapping: can't load library
markex: can't load library
maxlib: can't load library
mjlib: can't load library
motex: can't load library
oscx: can't load library
pddp: can't load library
pdogg: can't load library
pmpd: can't load library
sigpack: can't load library
smlib: can't load library
unauthorized: can't load library
pan: can't load library
hcs: can't load library
jmmmp: can't load library
ext13: can't load library
ggee: can't load library
iem_anything: can't load library
ekext: can't load library
flatgui: can't load library
chaos: can't load library
2012/12/4 Hans-Christoph Steiner h...@at.or.at
I think I fixed that recently, try today's build:
http://puredata.info/downloads/pd-extended/releases/0.43.4
.hc
On Dec 4, 2012, at 2:39 AM, Esteban Viveros wrote:
I tried to open this patch on pd-extended 0.43.4 but they open very
bugged... No cords..
On pd-extended 0.42.5 they are working well..
Something to do??
--
Esteban Viveros
(27) 8815 7170
(27) 3066 0359
(11) 95761 4125
(11) 2738 7868
www.bandpage.com/estebanviveros
https://www.facebook.com/estebanviveros.art
http://www.papodecompositor-es.blogspot.com.br/
http://expurgacao.art.br/
quadrada_e_pulso.pd___
Pd-list@iem.at mailing list
UNSUBSCRIBE
Re: [PD] what makes Pd-extended 0.43 so CPU-hungry?
Finally I have some clue what's wrong with Pd-E 0.43 for GNU/Linux, or for Debian Squeeze at least. Sorry that it took me so long to sit down and sort it out. The problem is still there, with version 0.43.4: my live performance setups run with almost double CPU load, when compared to 0.42. Now I also tested with some comprehensive patches which are known to be pure vanilla, like Martin Brinkmann's 'chaosmonster'. Remarkably, these patches do not show an increased CPU load. Therefore I guessed that it must be in external classes. I tried using callgrind and kcachegrind (thanks for the hint Jamie). Though callgrind makes Pd choke completely (while recording the complete call history of a process instead of taking samples), the output gave a clue. Freeverb~ was shown to make a couple hundred function calls within the perform loop. Functions which are written as 'inline' in the C file. An isolated freeverb~ instance turned out to do 10% CPU load. Admittedly, this computer (1.8 GHz core duo 2006) is not the latest. But freeverb~ normally does some 1% per instance. So, freeverb~ is the messenger; without it I might not have noticed any problem. But what is the message? Is Pd-E 0.43 compiled without optimization? I searched for more inline functions in external libs, and found one in bsaylor/svf~. In this case again, the executable implements it as a call. The core code however is almost certainly compiled with properly inlined functions. There's one frequently called inline function in the API (PD_BIGORSMALL, which used to be a macro in the past). If this would be compiled as a call, a patch like 'chaosmonster' would definitely show performance loss. Note that I'm talking about debian binaries so far, more precisely Pd-E 0.43.4 for debian squeeze, as downloaded from puredata.info downloads page. In contrast, I checked freeverb~ in the distribution for OSX i386, and here the inlining was done properly. Another difference between those distributions: SSE instructions are used for OSX, not for debian. Simple operations like addition and multiplication of floats are done on the FPU in debian, while xmm registers are used with OSX. This also means that things like abs() and ifnan() are function calls for debian, while they could be simple instructions on the xmm registers. (Instructions can be viewed by dissassembling executables with command objdump -d file.) My conclusion from these observations: at least some Pd 0.43 externals for debian squeeze are compiled with -0O for some reason (don't know about other Linuxes). How come? The template makefile (also used for freeverb~) has optimization -O6. The root makefile for the packages have certain optimization flags as well. Are they somehow conflicting, producing an undefined result? Not for OSX, apparently. But for debian something goes wrong. The build system stuff is really over my head, hopefully someone else has better overview to find the exact cause. Katja On 5/6/12, Jamie Bullock jamie.b.bull...@gmail.com wrote: Hi Katja, On 5 May 2012, at 20:43, katja katjavet...@gmail.com wrote: I've tried to use Oprofile on Debian, but this gives me a kernel failure soon as I start sampling. Does anyone know of a fine performance profiler for GNU/Linux? Katja You might want to try callgrind + kcachegrind... http://www.slac.stanford.edu/BFROOT/www/Computing/Optimization/genprof.html best, Jamie -- http://www.jamiebullock.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] graph on parent problem?
wel... I've been reporting similar issues, and it's getting worse with 043 versions. Definetly something worth debugging. cheers I have an array in a subpatch, when I applied graph-on-parent property to the subpatch (to view the array which holds sound so could be fairly large) Pd didn't like that. With dsp off it worked fine but when I turn dsp on Pd becames unusably slow to react (sliders, etc.). I was able to solve the problem by removing the graph-on-parent option. So it seems there is something in the interaction of graph-on-parent and the sound engine. this is on a planetCCRMA system: FC17 PD0.42-5extended Anyone else encounter such a problem? Any solution (beside moving things outside subpatches)? Thanks Oded ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] what makes Pd-extended 0.43 so CPU-hungry?
Thanks for this write-up and all that testing, its definitely very helpful. So in the end, you're talking about Pd-extended on debian only? It sounds like your tests show that 0.43 was not slower on Mac OS X. It does look like the Debian-i386 builds don't have optimization turned on, you can look at the build log to see exactly how it was built: http://autobuild.puredata.info/auto-build/2012-12-07/logs/2012-12-07_06.27.52_linux_debian-squeeze-i386_pd-extended.txt cc -I/home/pd/auto-build/pd-extended/pd/include/pd -DPD -DVERSION='1.2.1' -fPIC -DPD -DHAVE_G_CANVAS_H -I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/externals/Gem -I/home/pd/auto-build/pd-extended/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC -g -fno-inline-functions -fno-omit-frame-pointer -DDEBUG_SOUNDFILE -Wstrict-aliasing=2 -o freeverb~.o -c freeverb~.c If you want to mess with the flags, try adding things to OPT_CFLAGS in packages/linux_make/Makefile, that should affect the almost all of the build. If you just want to test freeverb, you can do this: cd externals/freeverb make OPT_CFLAGS=-O6 -msse -msse2 -mfpmath=sse -ftree-vectorize -ftree-vectorizer-verbose=1 Or things like that... I'd be very interested to hear about profiling results of using these flags. I only did a little profiling when I stuck those in. .hc On Dec 7, 2012, at 4:36 PM, katja wrote: Finally I have some clue what's wrong with Pd-E 0.43 for GNU/Linux, or for Debian Squeeze at least. Sorry that it took me so long to sit down and sort it out. The problem is still there, with version 0.43.4: my live performance setups run with almost double CPU load, when compared to 0.42. Now I also tested with some comprehensive patches which are known to be pure vanilla, like Martin Brinkmann's 'chaosmonster'. Remarkably, these patches do not show an increased CPU load. Therefore I guessed that it must be in external classes. I tried using callgrind and kcachegrind (thanks for the hint Jamie). Though callgrind makes Pd choke completely (while recording the complete call history of a process instead of taking samples), the output gave a clue. Freeverb~ was shown to make a couple hundred function calls within the perform loop. Functions which are written as 'inline' in the C file. An isolated freeverb~ instance turned out to do 10% CPU load. Admittedly, this computer (1.8 GHz core duo 2006) is not the latest. But freeverb~ normally does some 1% per instance. So, freeverb~ is the messenger; without it I might not have noticed any problem. But what is the message? Is Pd-E 0.43 compiled without optimization? I searched for more inline functions in external libs, and found one in bsaylor/svf~. In this case again, the executable implements it as a call. The core code however is almost certainly compiled with properly inlined functions. There's one frequently called inline function in the API (PD_BIGORSMALL, which used to be a macro in the past). If this would be compiled as a call, a patch like 'chaosmonster' would definitely show performance loss. Note that I'm talking about debian binaries so far, more precisely Pd-E 0.43.4 for debian squeeze, as downloaded from puredata.info downloads page. In contrast, I checked freeverb~ in the distribution for OSX i386, and here the inlining was done properly. Another difference between those distributions: SSE instructions are used for OSX, not for debian. Simple operations like addition and multiplication of floats are done on the FPU in debian, while xmm registers are used with OSX. This also means that things like abs() and ifnan() are function calls for debian, while they could be simple instructions on the xmm registers. (Instructions can be viewed by dissassembling executables with command objdump -d file.) My conclusion from these observations: at least some Pd 0.43 externals for debian squeeze are compiled with -0O for some reason (don't know about other Linuxes). How come? The template makefile (also used for freeverb~) has optimization -O6. The root makefile for the packages have certain optimization flags as well. Are they somehow conflicting, producing an undefined result? Not for OSX, apparently. But for debian something goes wrong. The build system stuff is really over my head, hopefully someone else has better overview to find the exact cause. Katja On 5/6/12, Jamie Bullock jamie.b.bull...@gmail.com wrote: Hi Katja, On 5 May 2012, at 20:43, katja katjavet...@gmail.com wrote: I've tried to use Oprofile on Debian, but this gives me a kernel failure soon as I start sampling. Does anyone know of a fine performance profiler for GNU/Linux? Katja You might want to try callgrind + kcachegrind... http://www.slac.stanford.edu/BFROOT/www/Computing/Optimization/genprof.html best, Jamie -- http://www.jamiebullock.com
Re: [PD] Pd on the Pi : Miller's version
Yeah... I don't remember what date my system had been updated to, but I had it working fine. Then, spontaneously a few days ago, that system stopped booting. I just threw on a new image, but now I'm getting total USB failure when set to 1.1 (and still audio input not working when in USB 2.0). I might end up deciding to try to get the old image patched up somehow... but am working on Pd bugs right now so will need to put that off till 0.44 comes out. cheers Miller On Fri, Dec 07, 2012 at 01:23:21PM -0500, me.grimm wrote: yeah i was having the same trouble the couple times i tried this a month or so ago. no USB devices. did you have it work for you miller on prior raspbian image? i remember having to mount the sd card on m laptop to remove that cmdtxt line to get my keyboard/mouse back but then gave up on the whole usb 1.1 speed thing. m On Fri, Dec 7, 2012 at 12:33 PM, Miller Puckette m...@ucsd.edu wrote: ... and I just tried to do the USB slowdown trick again with a newer install and it... fails to upen any USB devices at all! So we're not out of the woods yet after all. cheers M On Fri, Dec 07, 2012 at 11:37:06AM +0100, Pierre Massat wrote: Hi Miller, Thank for your reply. This is the thread that made me ask for an update here. Cheers, Pierre. 2012/12/6 Miller Puckette m...@ucsd.edu Hi all - Here's the thread: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66t=19155p=218405#p218405 ... and the upshot is you have to slow USB down to 1.1 (instead of the default 2.0) to get correct audio input. The version of Pd I've uploaded ( http://crca.ucsd.edu/~msp/software.html) is much newer than the stock one that apt-get installs; OTOH the apt-get one is Pd extended and mine is only vanilla. cheers Miller On Thu, Dec 06, 2012 at 10:28:33AM -0500, me.grimm wrote: I came upon a thread where he talks about his attempt to get audio in working, wheres the thread? I would also like to know if anybody has some feedback to give about audio in, it still sounds like shit on my end. what hardware are you using? i see there has been some improvements on the USB drivers recently. maybe that will be fixed soon and the issues with audio in will improve? i would also like to know if anyone has it working well... been a while since these pi threads were started on this list a few months back. maybe someone has made head way... m On Thu, Dec 6, 2012 at 6:06 AM, Pierre Massat pimas...@gmail.com wrote: Dear list, I know that Miller Puckette has been working on improving Pd on the RPi lately, and I came upon a thread where he talks about his attempt to get audio in working, and mentioned his version of Pd compiled for the RPi. I would like to know in which respects it is different from the vanilla version one can grab from the Raspbian repository. I would also like to know if anybody has some feedback to give about audio in, and specially about the latency that can be achieved (and whether there is room for improvement or not). In short : an update on Pd on the Pi ? Cheers, Pierre. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ 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 use extensions .l_i386 and .l_ia64 for Linux externals
Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them. I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way. .hc On Dec 7, 2012, at 6:50 PM, katja wrote: Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux. I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd? Thanks, Katja ___ 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] graph on parent problem?
Hey Porres, Have you tried a recent build? I fixed some the issues from your patch, so LPVoc-help.pd now works. I'm still looking at the Brane-e issue where the array doesn't draw while recording in 0.43. .hc On Dec 7, 2012, at 5:20 PM, Alexandre Torres Porres wrote: wel... I've been reporting similar issues, and it's getting worse with 043 versions. Definetly something worth debugging. cheers I have an array in a subpatch, when I applied graph-on-parent property to the subpatch (to view the array which holds sound so could be fairly large) Pd didn't like that. With dsp off it worked fine but when I turn dsp on Pd becames unusably slow to react (sliders, etc.). I was able to solve the problem by removing the graph-on-parent option. So it seems there is something in the interaction of graph-on-parent and the sound engine. this is on a planetCCRMA system: FC17 PD0.42-5extended Anyone else encounter such a problem? Any solution (beside moving things outside subpatches)? Thanks Oded ___ 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 use extensions .l_i386 and .l_ia64 for Linux externals
On 08/12/12 07:50, katja wrote: Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux. it would be better to use .pd_li386 or something like that, since it is good to be able to search for name.pd* in your filesystem to find the file for [name] without knowing if it is an abstraction or external. Given the way pd/extra is organised this is important, it is not at all obvious where to look. For example here on debian if I am missing an object in a patch I can find the packages that could supply it, and where they would put it ... $ apt-file search uzi.pd pd-cyclone: /usr/lib/pd/extra/cyclone/uzi.pd_linux pd-pmpd: /usr/lib/pd/extra/pmpd/examples/ch_uzi.pd pd-purepd: /usr/lib/pd/extra/purepd/uzi.pd .. or I could search locally in my files system to find which library the file is in. But this would not find uzi.l_ia64 and just searching for uzi finds 60 mostly irrelevant files which happen to have uzi somewhere in the name. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] graph on parent problem?
well, I hadn't, but yeah!! Thanks :D let me know when you nail the remaining issue please 2012/12/8 Hans-Christoph Steiner h...@at.or.at Hey Porres, Have you tried a recent build? I fixed some the issues from your patch, so LPVoc-help.pd now works. I'm still looking at the Brane-e issue where the array doesn't draw while recording in 0.43. .hc On Dec 7, 2012, at 5:20 PM, Alexandre Torres Porres wrote: wel... I've been reporting similar issues, and it's getting worse with 043 versions. Definetly something worth debugging. cheers I have an array in a subpatch, when I applied graph-on-parent property to the subpatch (to view the array which holds sound so could be fairly large) Pd didn't like that. With dsp off it worked fine but when I turn dsp on Pd becames unusably slow to react (sliders, etc.). I was able to solve the problem by removing the graph-on-parent option. So it seems there is something in the interaction of graph-on-parent and the sound engine. this is on a planetCCRMA system: FC17 PD0.42-5extended Anyone else encounter such a problem? Any solution (beside moving things outside subpatches)? Thanks Oded ___ 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] mac os annoyingly oppening previously openned patch
hey mac users, this has been bugging me for a while. Is it only me or since Lion (I'm using 10.7.5) it annoyingly oppens the previously openned patch everytime you open Pd? How to get rid of this thing? thanks ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd~ for MAX/MSP - is it for real?
Hello, how's it going? Recently I thought this computer music course and told MAX users they could open Pd in it with the [pd~] object for MAX. We just couldn't make it happen. I don't have MAX, but I had tried a while ago without success either, thinking I might have been doing something wrong. Well, this time I was trying this with a few MAX users and it turns out the object doesn't really instantiate. I wonder if anyone has ever successfuly used this. I ask if it doesn't work on version 6 only. Anyway, it seems to me no one is actually tweaking and playing with Pd inside MAX. Bummer. cheers ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
