[PD] analog PD+GEM
Hehe https://www.youtube.com/watch?v=63ay74S34XI Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udoo board sound issues
Ah cool thanks! This is actually the same issue I saw when I briefly tried the hard float image. I'll pick up another sd card and try again ... On Mar 24, 2014, at 5:01 PM, Simon Iten itensi...@gmail.com wrote: nevermind, found the solution. here it is.. http://lists.puredata.info/pipermail/pd-list/2012-09/097892.html cheers On Mon, Mar 24, 2014 at 2:43 PM, Simon Iten itensi...@gmail.com wrote: hey dan and list, i gave pd on the debian hardfloat image a try and can not run it. it compiles just fine. this is what i get on the console... debian@udoo-debian-hfp:~$ pd -verbose Pd-0.45.4 () compiled 14:17:43 Mar 24 2014 port 5400 TCL_LIBRARY=/usr/local/lib/pd/lib/tcl/library TK_LIBRARY=/usr/local/lib/pd/lib/tk/library wish /usr/local/lib/pd/tcl//pd-gui.tcl 5400 Waiting for connection request... /usr/local/lib/pd/bin/pd-watchdog watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... then a watchdog-signaling loop... this also happens with the version installed via synaptic. any thoughts? cheers On Sat, Mar 15, 2014 at 4:50 PM, Dan Wilcox danomat...@gmail.com wrote: Yeah, I wanted to use the hard float image but I was under time pressure and more things seemed to work out of the box with the Linaro one. I'll have more time to revisit it later. On Mar 15, 2014, at 12:46 PM, Simon Iten itensi...@gmail.com wrote: hmm, well to me 12ms is way to much. but then again i play a lot of fast attack notes in up-tempo pieces :-) thanks for your notes anyway, they helped a lot! and write back when you tried with the debian hardfloat image. i tried it for a short time and it was not very stable with pd. but then again i did not try a lot of things to fix this. cheers On 15 Mar 2014, at 13:10, Dan Wilcox danomat...@gmail.com wrote: Check this page: http://www.michalkaszczyszyn.com/en/tutorials/latency.html#acceptable I was wrong, the guitar to amp latency at 1 meter away is roughly 3 ms. The accumulation of a monitors and an effect or two gets you to 8ms. Acceptable latency is 12 ms. Again, I haven't measured my rig or the latency of my old wearable rig, both both were responsive to me, so they must e at least around 12 ms. Sorry for being unscientific about it. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Mar 15, 2014, at 5:49 AM, Simon Iten itensi...@gmail.com wrote: dan, no 15 ms is in no way tolerable for live use (if you have effects that should react in realtime) it is of course ok for delay and reverb stuff. the latency from an amp because of cable length and stuff is totally different, since your ear actually hears where the sound comes from and can adapt. but for studio use for example, 15 ms on a headphone is really two attacks for evey attack. heck even 10ms is evil :-) of course your/anyones mileage may vary. but i only wanted the box to output delay and reverb soundscape stuff away, so i might be good. i will add analog circuitry that mixes the dry and effect part of the signal, so i get no (very very little) latency on the unaffected part of the signal. no worries as far as the script goes. i had no problems at all to follow it. but i worked with linux a lot before. i was just suggesting, that the typical ubuntu user would not get some of the steps in between your steps :-) On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote: I haven't run any latency tests, so that might be what I'm getting. If so, it's acceptable for what I do. From what I've read, guitar - effects - amp latencies are already closer to 20ms. Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc off of it yet. I'm trying to get a few things done before I head out of town for work the next 2 weeks. I might be abel to get to it Sunday, but no promises. On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote: hi dan, tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i start to get clicks here and there… your script has some “errors” (missing instructions a novice would not understand how to deal with). do you want me to post them, or do you overdo it anyway? thanks again simon On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote: Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13
Re: [PD] friendly reminder that osx pd-extended is still badly flawed
He's on 10.6, so it's not this: http://puredata.info/docs/faq/help-pd-crashes-on-startup-on-mac-osx-10-7 On Mar 17, 2014, at 1:26 AM, pd-list-requ...@iem.at wrote: From: Alexandre Torres Porres por...@gmail.com Subject: Re: [PD] friendly reminder that osx pd-extended is still badly flawed Date: March 17, 2014 at 1:26:06 AM EDT To: i go bananas hard@gmail.com Cc: PD List pd-list@iem.at it's an OS thing, you can set it somewhere so it doenst open the latest files, someone showed how to do it here, cant remeber though :P Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] friendly reminder that osx pd-extended is still badly flawed
He's on 10.6, so it's not this: http://puredata.info/docs/faq/help-pd-crashes-on-startup-on-mac-osx-10-7 From: Alexandre Torres Porres por...@gmail.com it's an OS thing, you can set it somewhere so it doenst open the latest files, someone showed how to do it here, cant remeber though :P Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Raspberry Pi Wolfson Audio Card
Mm well the kernel does it as far as I could tell by watching htop. I think the latently is mainly due to the Linaro image not being hard float ... enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Mar 17, 2014, at 12:41 PM, Simon Iten itensi...@gmail.com wrote: hey dan, do you have to tell pd to use it’s own core on udoo, or does it so automagically? has this something to do with the cpu group from your script (it did not exist on my system) cheers On 13 Mar 2014, at 15:46, Dan Wilcox danomat...@gmail.com wrote: I don't know the latency. I can try testing that at let you know, but it's definitely good enough for what I need. It is at least lower than 20ms. Acceptable latency for guitar is 12ms, and I think I got around 16ms out of my old setup running on the Pentium III 500Mhz wearable. The main deal with the UDOO, is that it's multiple cores (2 or 4 depending on the board you buy). This way, the kernel has a core, pd has a core, and there are 2 cores left over for other things (my HID-OSC device daemon, etc). On Thu, Mar 13, 2014 at 4:32 AM, Pierre Massat pimas...@gmail.com wrote: Hey Dan, Looks like the UDOO is much better indeed from what you recently posted here. Could you tell us what latency you're achieving ? And which version you're using (with or w/o wifi) ? Cheers, Pierre. 2014-03-13 0:49 GMT+01:00 Dan Wilcox danomat...@gmail.com: Ok for small projects, but you're not going to interface a real stage mic or guitar easily. Would be much better if the next pi version comes with an onboard usb controller, which is the main problem for usb audio on the current pi. For now, the UDOO is where it's at for that. On Mar 12, 2014, at 7:10 PM, pd-list-requ...@iem.at wrote: From: me.grimm megr...@gmail.com Subject: [PD] [OT] Raspberry Pi Wolfson Audio Card Date: March 12, 2014 at 6:38:43 PM EDT To: pd_list Listserve pd-list@iem.at You all see this? http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/wolfson_pi what do you think? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Dan Wilcox danomatika.com robotcowboy.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] udoo board sound issues
I guess I don't get that since I've been playing that relative latency for years. How is 10-15 ms not real time? It's not even really perceivable unless you're doing lots of high rate short attack decay stuff. At least as far as I can tell. I must be slow. :D Then again, I might be wrong. I'll probably try the hard float Debian UDOO image next. That might give us some room. Also, I know my notes would not be easy to follow for a beginner ... I only wrote them for myself and haven't edited them. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Mar 15, 2014, at 5:49 AM, Simon Iten itensi...@gmail.com wrote: dan, no 15 ms is in no way tolerable for live use (if you have effects that should react in realtime) it is of course ok for delay and reverb stuff. the latency from an amp because of cable length and stuff is totally different, since your ear actually hears where the sound comes from and can adapt. but for studio use for example, 15 ms on a headphone is really two attacks for evey attack. heck even 10ms is evil :-) of course your/anyones mileage may vary. but i only wanted the box to output delay and reverb soundscape stuff away, so i might be good. i will add analog circuitry that mixes the dry and effect part of the signal, so i get no (very very little) latency on the unaffected part of the signal. no worries as far as the script goes. i had no problems at all to follow it. but i worked with linux a lot before. i was just suggesting, that the typical ubuntu user would not get some of the steps in between your steps :-) On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote: I haven't run any latency tests, so that might be what I'm getting. If so, it's acceptable for what I do. From what I've read, guitar - effects - amp latencies are already closer to 20ms. Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc off of it yet. I'm trying to get a few things done before I head out of town for work the next 2 weeks. I might be abel to get to it Sunday, but no promises. On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote: hi dan, tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i start to get clicks here and there… your script has some “errors” (missing instructions a novice would not understand how to deal with). do you want me to post them, or do you overdo it anyway? thanks again simon On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote: Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote: FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https://vimeo.com/86670103 (not my video, I'll put out a different edit soon) On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote: I will do that later tonight when I boot the udoo and pull my run scripts off of it. I'll post everything to GitHub so we can share resources. On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote: Hi Dan, Thanks for sharing these notes. They arrived in my inbox to coincide nicely with the delivery of my quad Udoo this morning! It would be great to see a full writeup of your Udoo setup at some point as I think many people will want to be doing a similar thing. All best, Jamie On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote: Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf' sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf' I disable pulseaudio. Make sure pulseaudio does not respawn itself (from http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio): echo autospawn=no ~/.pulse/client.conf Also add the following to ~/.bash_login to kill pulse audio if it's running on login: # kill pulse audio if it was spawned pulseaudio -k I'm not looking at the udoo run script, but I'm pretty sure I'm using the following with the US-25EX USB soudcard: pd -rt
Re: [PD] udoo board sound issues
Check this page: http://www.michalkaszczyszyn.com/en/tutorials/latency.html#acceptable I was wrong, the guitar to amp latency at 1 meter away is roughly 3 ms. The accumulation of a monitors and an effect or two gets you to 8ms. Acceptable latency is 12 ms. Again, I haven't measured my rig or the latency of my old wearable rig, both both were responsive to me, so they must e at least around 12 ms. Sorry for being unscientific about it. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Mar 15, 2014, at 5:49 AM, Simon Iten itensi...@gmail.com wrote: dan, no 15 ms is in no way tolerable for live use (if you have effects that should react in realtime) it is of course ok for delay and reverb stuff. the latency from an amp because of cable length and stuff is totally different, since your ear actually hears where the sound comes from and can adapt. but for studio use for example, 15 ms on a headphone is really two attacks for evey attack. heck even 10ms is evil :-) of course your/anyones mileage may vary. but i only wanted the box to output delay and reverb soundscape stuff away, so i might be good. i will add analog circuitry that mixes the dry and effect part of the signal, so i get no (very very little) latency on the unaffected part of the signal. no worries as far as the script goes. i had no problems at all to follow it. but i worked with linux a lot before. i was just suggesting, that the typical ubuntu user would not get some of the steps in between your steps :-) On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote: I haven't run any latency tests, so that might be what I'm getting. If so, it's acceptable for what I do. From what I've read, guitar - effects - amp latencies are already closer to 20ms. Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc off of it yet. I'm trying to get a few things done before I head out of town for work the next 2 weeks. I might be abel to get to it Sunday, but no promises. On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote: hi dan, tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i start to get clicks here and there… your script has some “errors” (missing instructions a novice would not understand how to deal with). do you want me to post them, or do you overdo it anyway? thanks again simon On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote: Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote: FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https://vimeo.com/86670103 (not my video, I'll put out a different edit soon) On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote: I will do that later tonight when I boot the udoo and pull my run scripts off of it. I'll post everything to GitHub so we can share resources. On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote: Hi Dan, Thanks for sharing these notes. They arrived in my inbox to coincide nicely with the delivery of my quad Udoo this morning! It would be great to see a full writeup of your Udoo setup at some point as I think many people will want to be doing a similar thing. All best, Jamie On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote: Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf' sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf' I disable pulseaudio. Make sure pulseaudio does not respawn itself (from http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio): echo autospawn=no ~/.pulse/client.conf Also add the following to ~/.bash_login to kill pulse audio if it's running on login: # kill pulse audio if it was spawned pulseaudio -k I'm not looking at the udoo run script, but I'm pretty sure I'm using the following with the US-25EX USB soudcard: pd -rt -nogui -alsa -audiodev 5 Use pd -listdev to get the device
Re: [PD] udoo board sound issues
Yeah, I wanted to use the hard float image but I was under time pressure and more things seemed to work out of the box with the Linaro one. I'll have more time to revisit it later. On Mar 15, 2014, at 12:46 PM, Simon Iten itensi...@gmail.com wrote: hmm, well to me 12ms is way to much. but then again i play a lot of fast attack notes in up-tempo pieces :-) thanks for your notes anyway, they helped a lot! and write back when you tried with the debian hardfloat image. i tried it for a short time and it was not very stable with pd. but then again i did not try a lot of things to fix this. cheers On 15 Mar 2014, at 13:10, Dan Wilcox danomat...@gmail.com wrote: Check this page: http://www.michalkaszczyszyn.com/en/tutorials/latency.html#acceptable I was wrong, the guitar to amp latency at 1 meter away is roughly 3 ms. The accumulation of a monitors and an effect or two gets you to 8ms. Acceptable latency is 12 ms. Again, I haven't measured my rig or the latency of my old wearable rig, both both were responsive to me, so they must e at least around 12 ms. Sorry for being unscientific about it. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Mar 15, 2014, at 5:49 AM, Simon Iten itensi...@gmail.com wrote: dan, no 15 ms is in no way tolerable for live use (if you have effects that should react in realtime) it is of course ok for delay and reverb stuff. the latency from an amp because of cable length and stuff is totally different, since your ear actually hears where the sound comes from and can adapt. but for studio use for example, 15 ms on a headphone is really two attacks for evey attack. heck even 10ms is evil :-) of course your/anyones mileage may vary. but i only wanted the box to output delay and reverb soundscape stuff away, so i might be good. i will add analog circuitry that mixes the dry and effect part of the signal, so i get no (very very little) latency on the unaffected part of the signal. no worries as far as the script goes. i had no problems at all to follow it. but i worked with linux a lot before. i was just suggesting, that the typical ubuntu user would not get some of the steps in between your steps :-) On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote: I haven't run any latency tests, so that might be what I'm getting. If so, it's acceptable for what I do. From what I've read, guitar - effects - amp latencies are already closer to 20ms. Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc off of it yet. I'm trying to get a few things done before I head out of town for work the next 2 weeks. I might be abel to get to it Sunday, but no promises. On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote: hi dan, tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i start to get clicks here and there… your script has some “errors” (missing instructions a novice would not understand how to deal with). do you want me to post them, or do you overdo it anyway? thanks again simon On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote: Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote: FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https://vimeo.com/86670103 (not my video, I'll put out a different edit soon) On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote: I will do that later tonight when I boot the udoo and pull my run scripts off of it. I'll post everything to GitHub so we can share resources. On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote: Hi Dan, Thanks for sharing these notes. They arrived in my inbox to coincide nicely with the delivery of my quad Udoo this morning! It would be great to see a full writeup of your Udoo setup at some point as I think many people will want to be doing a similar thing. All best, Jamie On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote: Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf
[PD] Arp emulation?
You have an Arp emulation patch? Can I get a copy? I have a MiniMoog emulation in pd, but I've been sitting on it for years ... just haven't been abel to add the finishing touches. I recently brought in the bandlimited oscillators in rjlib and it sounds really good now. It's not a perfect emualtion, but more in the same spirit with the same controls. I have the code for an ARP Odyssey that still works and it even has midi working. So it might be a nice starter project, especially if i can export it to a ipad/iphone. I guess i am just looking for some more in-depth examples to digest before i get cracking thanks! pp -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] using pd live (sans computer/laptop/raspberry pi)
Without a computer, no. Without a desktop or laptop computer, yes. An embedded computer (rpi or UDOO, for instance) can totally do this and that's what some of us have used them for. Simplest case is to setup the system, install pd with your patch, and write a script that is launched when the machine boots that connects to the sound card and starts pd. This way it starts immediately when you turn on the power, no interaction required. All of this can be built into a box of some sort, giving you an in/out effects setup. It's what I've done with several systems, although they are not as small as a real pedal. Any regular USB sound card will work. I recommend the Roland Edirol UA-25 o/ UA-25EX as it's a simple USB 1 sound device that will work with anything that speaks USB audio without a driver. You get instrument jack/XLR preamps in and stereo out. You could also get this setup with my Pd iOs app PdPartyhttps://github.com/danomatika/PdParty/blob/master/doc/PdParty_User_Guide.mdof Chris McCormick's PdDroidParty http://droidparty.net/ and a sound interface to your mobile device. For instance, I have an Alesis iODock for my iPad which gives me the equivalent of a UA-25. I've also had success using a UA-25 with a powered USB hub connected to the iPad via the camera connection kit usb adapter. Let me know if you want to beta test PdParty as it's currently not released on the App Store. Subject: Re: [PD] using pd live (sans computer/laptop/raspberry pi) I'll take this a bit further into newb-question territory. Are there any soundcards that output instrument level signals? This would allow one to use PD into a computer and then out of a computer similar to how one uses an effects pedal, no? On Fri, Mar 14, 2014 at 10:00 AM, Aaron L. elmaster...@gmail.com wrote: List. Total newb question Is there any way to encapsulate(?) a pd patch into some sort of hardware (pedal? something else?) allowing for no computers (e.g. no bootup, no load times, etc.) on stage? I can't imagine that there is but, hey, I have no shame. Thanks. -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] using pd live (sans computer/laptop/raspberry pi)
See this also :D http://danomatika.com/media/projects/s2007/thesis/dwilcox_thesis_arttech_07.pdf On Fri, Mar 14, 2014 at 4:07 PM, Aaron L. elmaster...@gmail.com wrote: Wow. Many thanks, Dan. I'll look into these options and get back to you then. On Fri, Mar 14, 2014 at 12:44 PM, Dan Wilcox danomat...@gmail.com wrote: Without a computer, no. Without a desktop or laptop computer, yes. An embedded computer (rpi or UDOO, for instance) can totally do this and that's what some of us have used them for. Simplest case is to setup the system, install pd with your patch, and write a script that is launched when the machine boots that connects to the sound card and starts pd. This way it starts immediately when you turn on the power, no interaction required. All of this can be built into a box of some sort, giving you an in/out effects setup. It's what I've done with several systems, although they are not as small as a real pedal. Any regular USB sound card will work. I recommend the Roland Edirol UA-25 o/ UA-25EX as it's a simple USB 1 sound device that will work with anything that speaks USB audio without a driver. You get instrument jack/XLR preamps in and stereo out. You could also get this setup with my Pd iOs app PdPartyhttps://github.com/danomatika/PdParty/blob/master/doc/PdParty_User_Guide.mdof Chris McCormick's PdDroidParty http://droidparty.net/ and a sound interface to your mobile device. For instance, I have an Alesis iODock for my iPad which gives me the equivalent of a UA-25. I've also had success using a UA-25 with a powered USB hub connected to the iPad via the camera connection kit usb adapter. Let me know if you want to beta test PdParty as it's currently not released on the App Store. Subject: Re: [PD] using pd live (sans computer/laptop/raspberry pi) I'll take this a bit further into newb-question territory. Are there any soundcards that output instrument level signals? This would allow one to use PD into a computer and then out of a computer similar to how one uses an effects pedal, no? On Fri, Mar 14, 2014 at 10:00 AM, Aaron L. elmaster...@gmail.comwrote: List. Total newb question Is there any way to encapsulate(?) a pd patch into some sort of hardware (pedal? something else?) allowing for no computers (e.g. no bootup, no load times, etc.) on stage? I can't imagine that there is but, hey, I have no shame. Thanks. -- Dan Wilcox danomatika.com robotcowboy.com -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] using pd live (sans computer/laptop/raspberry pi)
On Mar 14, 2014, at 6:04 PM, Aaron L. elmaster...@gmail.com wrote: Wow. That pdf is beyond awesome, Dan. On many different levels. Thanks :D Question about this part though: An attached direct box converts high-impedance signals to microphone level for connection to a stage mixing and amplification systems The DI box is for being able to plug into the house mains via XLR which, as you probably know, is balanced so you can send it alot further. This is especially useful when I generally ask for 2 50 foot XLRs so I can roam around the crowd. I want to take line-level (which is low-level impedance, correct?) back to instrument-level so as to use the guitar amp. Well, this is why don't want to use the dinky 1/8 inch audio jacks on an onboard sound card and use a USB sound card with built in preamps which handle the impedance issues. Any better sound card will have balanced 1/4 inch jacks out, which is what my UA-25 has (or at least is what the block diagram on the top says). I've run these into regular guitar amps many times. So how does one get one's guitar out of the UDOO and back into the guitar amp? guitar -- soundcard neutrik 1/4+XLR combo jack -- stereo 1/4 balanced jacks out -- 1 channel into guitar amp Obviously you'll want to adjust the levels accordingly. I'd suggest getting a USB soundcard with hardware incoming preamp and outgoing volume controls. This is another reason why I've been using UA-25s. On Fri, Mar 14, 2014 at 2:53 PM, Dan Wilcox danomat...@gmail.com wrote: See this also :D http://danomatika.com/media/projects/s2007/thesis/dwilcox_thesis_arttech_07.pdf On Fri, Mar 14, 2014 at 4:07 PM, Aaron L. elmaster...@gmail.com wrote: Wow. Many thanks, Dan. I'll look into these options and get back to you then. On Fri, Mar 14, 2014 at 12:44 PM, Dan Wilcox danomat...@gmail.com wrote: Without a computer, no. Without a desktop or laptop computer, yes. An embedded computer (rpi or UDOO, for instance) can totally do this and that's what some of us have used them for. Simplest case is to setup the system, install pd with your patch, and write a script that is launched when the machine boots that connects to the sound card and starts pd. This way it starts immediately when you turn on the power, no interaction required. All of this can be built into a box of some sort, giving you an in/out effects setup. It's what I've done with several systems, although they are not as small as a real pedal. Any regular USB sound card will work. I recommend the Roland Edirol UA-25 o/ UA-25EX as it's a simple USB 1 sound device that will work with anything that speaks USB audio without a driver. You get instrument jack/XLR preamps in and stereo out. You could also get this setup with my Pd iOs app PdParty of Chris McCormick's PdDroidParty and a sound interface to your mobile device. For instance, I have an Alesis iODock for my iPad which gives me the equivalent of a UA-25. I've also had success using a UA-25 with a powered USB hub connected to the iPad via the camera connection kit usb adapter. Let me know if you want to beta test PdParty as it's currently not released on the App Store. Subject: Re: [PD] using pd live (sans computer/laptop/raspberry pi) I'll take this a bit further into newb-question territory. Are there any soundcards that output instrument level signals? This would allow one to use PD into a computer and then out of a computer similar to how one uses an effects pedal, no? On Fri, Mar 14, 2014 at 10:00 AM, Aaron L. elmaster...@gmail.com wrote: List. Total newb question Is there any way to encapsulate(?) a pd patch into some sort of hardware (pedal? something else?) allowing for no computers (e.g. no bootup, no load times, etc.) on stage? I can't imagine that there is but, hey, I have no shame. Thanks. -- Dan Wilcox danomatika.com robotcowboy.com -- Dan Wilcox danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udoo board sound issues
I haven't run any latency tests, so that might be what I'm getting. If so, it's acceptable for what I do. From what I've read, guitar - effects - amp latencies are already closer to 20ms. Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc off of it yet. I'm trying to get a few things done before I head out of town for work the next 2 weeks. I might be abel to get to it Sunday, but no promises. On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote: hi dan, tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i start to get clicks here and there… your script has some “errors” (missing instructions a novice would not understand how to deal with). do you want me to post them, or do you overdo it anyway? thanks again simon On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote: Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote: FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https://vimeo.com/86670103 (not my video, I'll put out a different edit soon) On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote: I will do that later tonight when I boot the udoo and pull my run scripts off of it. I'll post everything to GitHub so we can share resources. On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote: Hi Dan, Thanks for sharing these notes. They arrived in my inbox to coincide nicely with the delivery of my quad Udoo this morning! It would be great to see a full writeup of your Udoo setup at some point as I think many people will want to be doing a similar thing. All best, Jamie On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote: Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf' sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf' I disable pulseaudio. Make sure pulseaudio does not respawn itself (from http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio): echo autospawn=no ~/.pulse/client.conf Also add the following to ~/.bash_login to kill pulse audio if it's running on login: # kill pulse audio if it was spawned pulseaudio -k I'm not looking at the udoo run script, but I'm pretty sure I'm using the following with the US-25EX USB soudcard: pd -rt -nogui -alsa -audiodev 5 Use pd -listdev to get the device list from alsa. I chose 5 as the first 4 (from memory) are 1-2 (built in hardware plugin) 2-3 (HDMI audio hardware plugin). 5 is the USB hardware alsa dev. On Mar 11, 2014, at 4:05 AM, Simon Iten itensi...@gmail.com wrote: without jack i should add... On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote: hey dan, unfortunately i’m in switzerland :-) would be great if you could post your setup somewhere or send the infos! i compiled pd from source as well. i start it from console (with -rt) and it works without problems with the builtin sound card. maybe the cheap card from dx.com just does not work properly with udoo. but please post your setup. thanks On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote: I've tried my both Roland Edirol UA-25 UA-25EX and both work great. The dedicated USB controller makes these guys work as compared to an RPI where I can't get full duplex without tons of dropouts. I'm using a Linaro install which boots to the console and runs the PD through scripting. The speed is great as compared to my old wearable computer. 4 cores makes a difference. I had to recompile my kernel to add midi support, but that's working great. It's not too bad, actually. I also built Pd-vanilal from source which was pretty easy using ./configure + make. I also have a script which fetches externals and builds/installs the agains vanilla so I have the few externals I need. As with my previous experience running Pd + embedded Ubuntu, I get great performance with RT permissions, the -rt startup flag, and ALSA. Jack is needless
Re: [PD] [OT] Raspberry Pi Wolfson Audio Card
I don't know the latency. I can try testing that at let you know, but it's definitely good enough for what I need. It is at least lower than 20ms. Acceptable latency for guitar is 12ms, and I think I got around 16ms out of my old setup running on the Pentium III 500Mhz wearable. The main deal with the UDOO, is that it's multiple cores (2 or 4 depending on the board you buy). This way, the kernel has a core, pd has a core, and there are 2 cores left over for other things (my HID-OSC device daemon, etc). On Thu, Mar 13, 2014 at 4:32 AM, Pierre Massat pimas...@gmail.com wrote: Hey Dan, Looks like the UDOO is much better indeed from what you recently posted here. Could you tell us what latency you're achieving ? And which version you're using (with or w/o wifi) ? Cheers, Pierre. 2014-03-13 0:49 GMT+01:00 Dan Wilcox danomat...@gmail.com: Ok for small projects, but you're not going to interface a real stage mic or guitar easily. Would be much better if the next pi version comes with an onboard usb controller, which is the main problem for usb audio on the current pi. For now, the UDOO is where it's at for that. On Mar 12, 2014, at 7:10 PM, pd-list-requ...@iem.at wrote: *From: *me.grimm megr...@gmail.com *Subject: **[PD] [OT] Raspberry Pi Wolfson Audio Card* *Date: *March 12, 2014 at 6:38:43 PM EDT *To: *pd_list Listserve pd-list@iem.at You all see this? http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/wolfson_pi what do you think? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udoo board sound issues
I will do that later tonight when I boot the udoo and pull my run scripts off of it. I'll post everything to GitHub so we can share resources. On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote: Hi Dan, Thanks for sharing these notes. They arrived in my inbox to coincide nicely with the delivery of my quad Udoo this morning! It would be great to see a full writeup of your Udoo setup at some point as I think many people will want to be doing a similar thing. All best, Jamie On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote: Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf' sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf' I disable pulseaudio. Make sure pulseaudio does not respawn itself (from http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio): echo autospawn=no ~/.pulse/client.conf Also add the following to ~/.bash_login to kill pulse audio if it's running on login: # kill pulse audio if it was spawned pulseaudio -k I'm not looking at the udoo run script, but I'm pretty sure I'm using the following with the US-25EX USB soudcard: pd -rt -nogui -alsa -audiodev 5 Use pd -listdev to get the device list from alsa. I chose 5 as the first 4 (from memory) are 1-2 (built in hardware plugin) 2-3 (HDMI audio hardware plugin). 5 is the USB hardware alsa dev. On Mar 11, 2014, at 4:05 AM, Simon Iten itensi...@gmail.com wrote: without jack i should add... On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote: hey dan, unfortunately i’m in switzerland :-) would be great if you could post your setup somewhere or send the infos! i compiled pd from source as well. i start it from console (with -rt) and it works without problems with the builtin sound card. maybe the cheap card from dx.com just does not work properly with udoo. but please post your setup. thanks On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote: I've tried my both Roland Edirol UA-25 UA-25EX and both work great. The dedicated USB controller makes these guys work as compared to an RPI where I can't get full duplex without tons of dropouts. I'm using a Linaro install which boots to the console and runs the PD through scripting. The speed is great as compared to my old wearable computer. 4 cores makes a difference. I had to recompile my kernel to add midi support, but that's working great. It's not too bad, actually. I also built Pd-vanilal from source which was pretty easy using ./configure + make. I also have a script which fetches externals and builds/installs the agains vanilla so I have the few externals I need. As with my previous experience running Pd + embedded Ubuntu, I get great performance with RT permissions, the -rt startup flag, and ALSA. Jack is needless overheard unless you want to work with other Jack-enabeld apps. Same with X windows, although my setup was running great in X with pd + ALSA in testing. From your description, it sounds like your main issue is jack pd are probably not running in realtime. I can sent you my install notes if you want (or put them online, as I've been meaning to). Also, are based in the NE within driving distance to Pittsburgh? We could do a patching circle/UDOO setup afternoon :D On Mar 9, 2014, at 5:14 PM, pd-list-requ...@iem.at wrote: From: Miller Puckette m...@ucsd.edu Subject: Re: [PD] udoo board sound issues Date: March 9, 2014 at 5:07:54 PM EDT To: Simon Iten itensi...@gmail.com Cc: PD list pd-list@iem.at H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should be able to do some tests when I get back, assuming nobody else has figured this out first. cheers Miller On Sun, Mar 09, 2014 at 09:57:45PM +0100, Simon Iten wrote: hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) cheers. ___ Pd-list@iem.at
Re: [PD] Pd-list Digest, Vol 108, Issue 47
*sigh* Pitch to midi guitar systems have been around since the mid 80s. If the OP only needs control data, there's no need to bring a dedicated computer and multiple channel sound card into the equation. I use a Shadow SH-075 which was built in W. Germany (!) in the late 80's I bought off of eBay and it's tracking speed is definitely acceptable, at least for what I do. There is a new guy on the block, the Fishman Tripleplay which I'd like to upgrade to as it's standard USB midi so will work with PdParty and my iPad. Both of these are relatively small as compared the Roland's rack mount and stomp box offerings (why don't they shrink the GR stuff by now?). Just saying that not every nail needs the PD hammer. Forgive me if my understanding of the original question was wrong. On Mar 12, 2014, at 10:28 AM, pd-list-requ...@iem.at wrote: From: Rafael Vega email.r...@gmail.com Subject: Re: [PD] midi question Date: March 12, 2014 at 9:00:47 AM EDT To: Aaron L. elmaster...@gmail.com Cc: pd-list pd-list@iem.at Reply-To: email.r...@gmail.com You could also get a sound card with 6 analog inputs and connect each output of the microphone to an individual channel. This way you can do 6 at a time. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-list Digest, Vol 108, Issue 47
Sorry, that *sigh* is condescending. Not my intention. I was thinking more about all the times we try to make things ourselves when an available solution already exists. I myself am guilty of this as much as anyone. A good mantra, at least in my media art circles, is be lazy like a fox. :D On Mar 12, 2014, at 10:41 AM, Dan Wilcox danomat...@gmail.com wrote: *sigh* Pitch to midi guitar systems have been around since the mid 80s. If the OP only needs control data, there's no need to bring a dedicated computer and multiple channel sound card into the equation. I use a Shadow SH-075 which was built in W. Germany (!) in the late 80's I bought off of eBay and it's tracking speed is definitely acceptable, at least for what I do. There is a new guy on the block, the Fishman Tripleplay which I'd like to upgrade to as it's standard USB midi so will work with PdParty and my iPad. Both of these are relatively small as compared the Roland's rack mount and stomp box offerings (why don't they shrink the GR stuff by now?). Just saying that not every nail needs the PD hammer. Forgive me if my understanding of the original question was wrong. On Mar 12, 2014, at 10:28 AM, pd-list-requ...@iem.at wrote: From: Rafael Vega email.r...@gmail.com Subject: Re: [PD] midi question Date: March 12, 2014 at 9:00:47 AM EDT To: Aaron L. elmaster...@gmail.com Cc: pd-list pd-list@iem.at Reply-To: email.r...@gmail.com You could also get a sound card with 6 analog inputs and connect each output of the microphone to an individual channel. This way you can do 6 at a time. Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-list Digest, Vol 108, Issue 47
Those devices I mentioned are not merely pickups, they are little embedded computers that calculate the pitch tracking for you and send midi note and ctl change data. They were originally designed so that you could play a midi synth with your guitar. They only output midi, no audio. You use the regular guitar jack for audio. Nowadays, you can simply send the midi data into your computer and receive it in PD. This is what I do. Again, I'm talking *only* about midi data. This has nothing to do with 6 channel audio. My use case is to send the guitar in as 1 channel (using the normal guitar jack output) and then control synths, effects processing, etc with the tracked note data for each string coming from the guitar pitch to midi converter. If you want 6 individual audio channels, 1 for each string in addition to the tracked note value for said strings then by all means do as Rafael suggests. However, if all you need is the tracked note values, but *do not* need the individual audio channels, then I'm suggesting one of these off the shelf pitch to midi boxes that already does this. On Mar 12, 2014, at 2:21 PM, Aaron L. elmaster...@gmail.com wrote: Dan. Thanks for the info. I'm relatively new to this stuff and my use-case ain't exactly conventional so forgive the 3rd degree.. But if I understand you correctly, you're saying that instead of having 6 dedicated/discrete outputs from a hexaphonic pickup, the pickups referenced in your email (the Shadow SH-075 and the Fishman Tripleplay) will essentially do the routing on the fly? Based on pitch? Are they smart enough to determine 440hz on a 5th-fretted low-E string vs an open A string? Also, wouldn't both the hardware (i.e the pickup used) as well as PD have to be smart enough to do this? Thanks. On Wed, Mar 12, 2014 at 8:29 AM, Dan Wilcox danomat...@gmail.com wrote: Sorry, that *sigh* is condescending. Not my intention. I was thinking more about all the times we try to make things ourselves when an available solution already exists. I myself am guilty of this as much as anyone. A good mantra, at least in my media art circles, is be lazy like a fox. :D On Mar 12, 2014, at 10:41 AM, Dan Wilcox danomat...@gmail.com wrote: *sigh* Pitch to midi guitar systems have been around since the mid 80s. If the OP only needs control data, there's no need to bring a dedicated computer and multiple channel sound card into the equation. I use a Shadow SH-075 which was built in W. Germany (!) in the late 80's I bought off of eBay and it's tracking speed is definitely acceptable, at least for what I do. There is a new guy on the block, the Fishman Tripleplay which I'd like to upgrade to as it's standard USB midi so will work with PdParty and my iPad. Both of these are relatively small as compared the Roland's rack mount and stomp box offerings (why don't they shrink the GR stuff by now?). Just saying that not every nail needs the PD hammer. Forgive me if my understanding of the original question was wrong. On Mar 12, 2014, at 10:28 AM, pd-list-requ...@iem.at wrote: From: Rafael Vega email.r...@gmail.com Subject: Re: [PD] midi question Date: March 12, 2014 at 9:00:47 AM EDT To: Aaron L. elmaster...@gmail.com Cc: pd-list pd-list@iem.at Reply-To: email.r...@gmail.com You could also get a sound card with 6 analog inputs and connect each output of the microphone to an individual channel. This way you can do 6 at a time. Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] midi question
(Woops. Fixed wrong subject line.) Here's an old demo, an example of my use case, 1 guitar audio channel + guitar midi note data: MyLungsWereAchingForYou The guitar in this case is a Casio DG-20 digital guitar (essentially a Casio keyboard with a guitar fretboard interface). I have an analog (regular) guitar + the guitar-midi converter box which functions equivalently, although the DG-20 midi pitch tracking is faster. * 1 channel guitar into pd * 1 channel mic into pd * guitar midi output into pd All processing is done live in pd, then mixed down into stereo. The bass line root note is chosen based on the midi note data coming from the guitar. No matter what key I play in, the bass line matches it. The drums are tracked and generated lie in pd, using super simple drum synths. The samples are triggered by the song tracking. On Mar 12, 2014, at 3:02 PM, Dan Wilcox danomat...@gmail.com wrote: Those devices I mentioned are not merely pickups, they are little embedded computers that calculate the pitch tracking for you and send midi note and ctl change data. They were originally designed so that you could play a midi synth with your guitar. They only output midi, no audio. You use the regular guitar jack for audio. Nowadays, you can simply send the midi data into your computer and receive it in PD. This is what I do. Again, I'm talking *only* about midi data. This has nothing to do with 6 channel audio. My use case is to send the guitar in as 1 channel (using the normal guitar jack output) and then control synths, effects processing, etc with the tracked note data for each string coming from the guitar pitch to midi converter. If you want 6 individual audio channels, 1 for each string in addition to the tracked note value for said strings then by all means do as Rafael suggests. However, if all you need is the tracked note values, but *do not* need the individual audio channels, then I'm suggesting one of these off the shelf pitch to midi boxes that already does this. On Mar 12, 2014, at 2:21 PM, Aaron L. elmaster...@gmail.com wrote: Dan. Thanks for the info. I'm relatively new to this stuff and my use-case ain't exactly conventional so forgive the 3rd degree.. But if I understand you correctly, you're saying that instead of having 6 dedicated/discrete outputs from a hexaphonic pickup, the pickups referenced in your email (the Shadow SH-075 and the Fishman Tripleplay) will essentially do the routing on the fly? Based on pitch? Are they smart enough to determine 440hz on a 5th-fretted low-E string vs an open A string? Also, wouldn't both the hardware (i.e the pickup used) as well as PD have to be smart enough to do this? Thanks. On Wed, Mar 12, 2014 at 8:29 AM, Dan Wilcox danomat...@gmail.com wrote: Sorry, that *sigh* is condescending. Not my intention. I was thinking more about all the times we try to make things ourselves when an available solution already exists. I myself am guilty of this as much as anyone. A good mantra, at least in my media art circles, is be lazy like a fox. :D On Mar 12, 2014, at 10:41 AM, Dan Wilcox danomat...@gmail.com wrote: *sigh* Pitch to midi guitar systems have been around since the mid 80s. If the OP only needs control data, there's no need to bring a dedicated computer and multiple channel sound card into the equation. I use a Shadow SH-075 which was built in W. Germany (!) in the late 80's I bought off of eBay and it's tracking speed is definitely acceptable, at least for what I do. There is a new guy on the block, the Fishman Tripleplay which I'd like to upgrade to as it's standard USB midi so will work with PdParty and my iPad. Both of these are relatively small as compared the Roland's rack mount and stomp box offerings (why don't they shrink the GR stuff by now?). Just saying that not every nail needs the PD hammer. Forgive me if my understanding of the original question was wrong. On Mar 12, 2014, at 10:28 AM, pd-list-requ...@iem.at wrote: From: Rafael Vega email.r...@gmail.com Subject: Re: [PD] midi question Date: March 12, 2014 at 9:00:47 AM EDT To: Aaron L. elmaster...@gmail.com Cc: pd-list pd-list@iem.at Reply-To: email.r...@gmail.com You could also get a sound card with 6 analog inputs and connect each output of the microphone to an individual channel. This way you can do 6 at a time. Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] midi question
Yeah. 2 channel in, mixed stereo out. It's the same setup I now have with the UDOO and, to some extent, my iPad running PdParty. On Mar 12, 2014, at 3:23 PM, Aaron L. elmaster...@gmail.com wrote: Cool stuff. What's the mic into pd for? Vocals? On Wed, Mar 12, 2014 at 12:15 PM, Dan Wilcox danomat...@gmail.com wrote: (Woops. Fixed wrong subject line.) Here's an old demo, an example of my use case, 1 guitar audio channel + guitar midi note data: MyLungsWereAchingForYou The guitar in this case is a Casio DG-20 digital guitar (essentially a Casio keyboard with a guitar fretboard interface). I have an analog (regular) guitar + the guitar-midi converter box which functions equivalently, although the DG-20 midi pitch tracking is faster. * 1 channel guitar into pd * 1 channel mic into pd * guitar midi output into pd All processing is done live in pd, then mixed down into stereo. The bass line root note is chosen based on the midi note data coming from the guitar. No matter what key I play in, the bass line matches it. The drums are tracked and generated lie in pd, using super simple drum synths. The samples are triggered by the song tracking. On Mar 12, 2014, at 3:02 PM, Dan Wilcox danomat...@gmail.com wrote: Those devices I mentioned are not merely pickups, they are little embedded computers that calculate the pitch tracking for you and send midi note and ctl change data. They were originally designed so that you could play a midi synth with your guitar. They only output midi, no audio. You use the regular guitar jack for audio. Nowadays, you can simply send the midi data into your computer and receive it in PD. This is what I do. Again, I'm talking *only* about midi data. This has nothing to do with 6 channel audio. My use case is to send the guitar in as 1 channel (using the normal guitar jack output) and then control synths, effects processing, etc with the tracked note data for each string coming from the guitar pitch to midi converter. If you want 6 individual audio channels, 1 for each string in addition to the tracked note value for said strings then by all means do as Rafael suggests. However, if all you need is the tracked note values, but *do not* need the individual audio channels, then I'm suggesting one of these off the shelf pitch to midi boxes that already does this. On Mar 12, 2014, at 2:21 PM, Aaron L. elmaster...@gmail.com wrote: Dan. Thanks for the info. I'm relatively new to this stuff and my use-case ain't exactly conventional so forgive the 3rd degree.. But if I understand you correctly, you're saying that instead of having 6 dedicated/discrete outputs from a hexaphonic pickup, the pickups referenced in your email (the Shadow SH-075 and the Fishman Tripleplay) will essentially do the routing on the fly? Based on pitch? Are they smart enough to determine 440hz on a 5th-fretted low-E string vs an open A string? Also, wouldn't both the hardware (i.e the pickup used) as well as PD have to be smart enough to do this? Thanks. On Wed, Mar 12, 2014 at 8:29 AM, Dan Wilcox danomat...@gmail.com wrote: Sorry, that *sigh* is condescending. Not my intention. I was thinking more about all the times we try to make things ourselves when an available solution already exists. I myself am guilty of this as much as anyone. A good mantra, at least in my media art circles, is be lazy like a fox. :D On Mar 12, 2014, at 10:41 AM, Dan Wilcox danomat...@gmail.com wrote: *sigh* Pitch to midi guitar systems have been around since the mid 80s. If the OP only needs control data, there's no need to bring a dedicated computer and multiple channel sound card into the equation. I use a Shadow SH-075 which was built in W. Germany (!) in the late 80's I bought off of eBay and it's tracking speed is definitely acceptable, at least for what I do. There is a new guy on the block, the Fishman Tripleplay which I'd like to upgrade to as it's standard USB midi so will work with PdParty and my iPad. Both of these are relatively small as compared the Roland's rack mount and stomp box offerings (why don't they shrink the GR stuff by now?). Just saying that not every nail needs the PD hammer. Forgive me if my understanding of the original question was wrong. On Mar 12, 2014, at 10:28 AM, pd-list-requ...@iem.at wrote: From: Rafael Vega email.r...@gmail.com Subject: Re: [PD] midi question Date: March 12, 2014 at 9:00:47 AM EDT To: Aaron L. elmaster...@gmail.com Cc: pd-list pd-list@iem.at Reply-To: email.r...@gmail.com You could also get a sound card with 6 analog inputs and connect each output of the microphone to an individual channel. This way you can do 6 at a time. Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan
Re: [PD] [OT] Raspberry Pi Wolfson Audio Card
Ok for small projects, but you're not going to interface a real stage mic or guitar easily. Would be much better if the next pi version comes with an onboard usb controller, which is the main problem for usb audio on the current pi. For now, the UDOO is where it's at for that. On Mar 12, 2014, at 7:10 PM, pd-list-requ...@iem.at wrote: From: me.grimm megr...@gmail.com Subject: [PD] [OT] Raspberry Pi Wolfson Audio Card Date: March 12, 2014 at 6:38:43 PM EDT To: pd_list Listserve pd-list@iem.at You all see this? http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/wolfson_pi what do you think? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udoo board sound issues
FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https://vimeo.com/86670103 (not my video, I'll put out a different edit soon) On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote: I will do that later tonight when I boot the udoo and pull my run scripts off of it. I'll post everything to GitHub so we can share resources. On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote: Hi Dan, Thanks for sharing these notes. They arrived in my inbox to coincide nicely with the delivery of my quad Udoo this morning! It would be great to see a full writeup of your Udoo setup at some point as I think many people will want to be doing a similar thing. All best, Jamie On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote: Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf' sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf' I disable pulseaudio. Make sure pulseaudio does not respawn itself (from http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio): echo autospawn=no ~/.pulse/client.conf Also add the following to ~/.bash_login to kill pulse audio if it's running on login: # kill pulse audio if it was spawned pulseaudio -k I'm not looking at the udoo run script, but I'm pretty sure I'm using the following with the US-25EX USB soudcard: pd -rt -nogui -alsa -audiodev 5 Use pd -listdev to get the device list from alsa. I chose 5 as the first 4 (from memory) are 1-2 (built in hardware plugin) 2-3 (HDMI audio hardware plugin). 5 is the USB hardware alsa dev. On Mar 11, 2014, at 4:05 AM, Simon Iten itensi...@gmail.com wrote: without jack i should add... On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote: hey dan, unfortunately i’m in switzerland :-) would be great if you could post your setup somewhere or send the infos! i compiled pd from source as well. i start it from console (with -rt) and it works without problems with the builtin sound card. maybe the cheap card from dx.com just does not work properly with udoo. but please post your setup. thanks On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote: I've tried my both Roland Edirol UA-25 UA-25EX and both work great. The dedicated USB controller makes these guys work as compared to an RPI where I can't get full duplex without tons of dropouts. I'm using a Linaro install which boots to the console and runs the PD through scripting. The speed is great as compared to my old wearable computer. 4 cores makes a difference. I had to recompile my kernel to add midi support, but that's working great. It's not too bad, actually. I also built Pd-vanilal from source which was pretty easy using ./configure + make. I also have a script which fetches externals and builds/installs the agains vanilla so I have the few externals I need. As with my previous experience running Pd + embedded Ubuntu, I get great performance with RT permissions, the -rt startup flag, and ALSA. Jack is needless overheard unless you want to work with other Jack-enabeld apps. Same with X windows, although my setup was running great in X with pd + ALSA in testing. From your description, it sounds like your main issue is jack pd are probably not running in realtime. I can sent you my install notes if you want (or put them online, as I've been meaning to). Also, are based in the NE within driving distance to Pittsburgh? We could do a patching circle/UDOO setup afternoon :D On Mar 9, 2014, at 5:14 PM, pd-list-requ...@iem.at wrote: From: Miller Puckette m...@ucsd.edu Subject: Re: [PD] udoo board sound issues Date: March 9, 2014 at 5:07:54 PM EDT To: Simon Iten itensi...@gmail.com Cc: PD list pd-list@iem.at H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should be able to do some tests when I get back, assuming nobody else has figured this out first. cheers Miller On Sun, Mar 09, 2014 at 09:57:45PM +0100, Simon Iten wrote: hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1
Re: [PD] udoo board sound issues
Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote: FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https://vimeo.com/86670103 (not my video, I'll put out a different edit soon) On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote: I will do that later tonight when I boot the udoo and pull my run scripts off of it. I'll post everything to GitHub so we can share resources. On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote: Hi Dan, Thanks for sharing these notes. They arrived in my inbox to coincide nicely with the delivery of my quad Udoo this morning! It would be great to see a full writeup of your Udoo setup at some point as I think many people will want to be doing a similar thing. All best, Jamie On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote: Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf' sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf' I disable pulseaudio. Make sure pulseaudio does not respawn itself (from http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio): echo autospawn=no ~/.pulse/client.conf Also add the following to ~/.bash_login to kill pulse audio if it's running on login: # kill pulse audio if it was spawned pulseaudio -k I'm not looking at the udoo run script, but I'm pretty sure I'm using the following with the US-25EX USB soudcard: pd -rt -nogui -alsa -audiodev 5 Use pd -listdev to get the device list from alsa. I chose 5 as the first 4 (from memory) are 1-2 (built in hardware plugin) 2-3 (HDMI audio hardware plugin). 5 is the USB hardware alsa dev. On Mar 11, 2014, at 4:05 AM, Simon Iten itensi...@gmail.com wrote: without jack i should add... On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote: hey dan, unfortunately i’m in switzerland :-) would be great if you could post your setup somewhere or send the infos! i compiled pd from source as well. i start it from console (with -rt) and it works without problems with the builtin sound card. maybe the cheap card from dx.com just does not work properly with udoo. but please post your setup. thanks On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote: I've tried my both Roland Edirol UA-25 UA-25EX and both work great. The dedicated USB controller makes these guys work as compared to an RPI where I can't get full duplex without tons of dropouts. I'm using a Linaro install which boots to the console and runs the PD through scripting. The speed is great as compared to my old wearable computer. 4 cores makes a difference. I had to recompile my kernel to add midi support, but that's working great. It's not too bad, actually. I also built Pd-vanilal from source which was pretty easy using ./configure + make. I also have a script which fetches externals and builds/installs the agains vanilla so I have the few externals I need. As with my previous experience running Pd + embedded Ubuntu, I get great performance with RT permissions, the -rt startup flag, and ALSA. Jack is needless overheard unless you want to work with other Jack-enabeld apps. Same with X windows, although my setup was running great in X with pd + ALSA in testing. From your description, it sounds like your main issue is jack pd are probably not running in realtime. I can sent you my install notes if you want (or put them online, as I've been meaning to). Also, are based in the NE within driving distance to Pittsburgh? We could do a patching circle/UDOO setup afternoon :D On Mar 9, 2014, at 5:14 PM, pd-list-requ...@iem.at wrote: From: Miller Puckette m...@ucsd.edu Subject: Re: [PD] udoo board sound issues Date: March 9, 2014 at 5:07:54 PM EDT To: Simon Iten itensi...@gmail.com Cc: PD list pd-list@iem.at H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should
Re: [PD] udoo board sound issues
Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf' sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf' I disable pulseaudio. Make sure pulseaudio does not respawn itself (from http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio): echo autospawn=no ~/.pulse/client.conf Also add the following to ~/.bash_login to kill pulse audio if it's running on login: # kill pulse audio if it was spawned pulseaudio -k I'm not looking at the udoo run script, but I'm pretty sure I'm using the following with the US-25EX USB soudcard: pd -rt -nogui -alsa -audiodev 5 Use pd -listdev to get the device list from alsa. I chose 5 as the first 4 (from memory) are 1-2 (built in hardware plugin) 2-3 (HDMI audio hardware plugin). 5 is the USB hardware alsa dev. On Mar 11, 2014, at 4:05 AM, Simon Iten itensi...@gmail.com wrote: without jack i should add... On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote: hey dan, unfortunately i’m in switzerland :-) would be great if you could post your setup somewhere or send the infos! i compiled pd from source as well. i start it from console (with -rt) and it works without problems with the builtin sound card. maybe the cheap card from dx.com just does not work properly with udoo. but please post your setup. thanks On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote: I've tried my both Roland Edirol UA-25 UA-25EX and both work great. The dedicated USB controller makes these guys work as compared to an RPI where I can't get full duplex without tons of dropouts. I'm using a Linaro install which boots to the console and runs the PD through scripting. The speed is great as compared to my old wearable computer. 4 cores makes a difference. I had to recompile my kernel to add midi support, but that's working great. It's not too bad, actually. I also built Pd-vanilal from source which was pretty easy using ./configure + make. I also have a script which fetches externals and builds/installs the agains vanilla so I have the few externals I need. As with my previous experience running Pd + embedded Ubuntu, I get great performance with RT permissions, the -rt startup flag, and ALSA. Jack is needless overheard unless you want to work with other Jack-enabeld apps. Same with X windows, although my setup was running great in X with pd + ALSA in testing. From your description, it sounds like your main issue is jack pd are probably not running in realtime. I can sent you my install notes if you want (or put them online, as I've been meaning to). Also, are based in the NE within driving distance to Pittsburgh? We could do a patching circle/UDOO setup afternoon :D On Mar 9, 2014, at 5:14 PM, pd-list-requ...@iem.at wrote: From: Miller Puckette m...@ucsd.edu Subject: Re: [PD] udoo board sound issues Date: March 9, 2014 at 5:07:54 PM EDT To: Simon Iten itensi...@gmail.com Cc: PD list pd-list@iem.at H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should be able to do some tests when I get back, assuming nobody else has figured this out first. cheers Miller On Sun, Mar 09, 2014 at 09:57:45PM +0100, Simon Iten wrote: hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) cheers. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 100k lines of code (was libpd separating gui from core)
Heaven forbid we add the 50 odd lines of totally manageable code in getdir.c that have largely been working since it was released in 2005. Nobody needs to get the current canvas dir, except for the recurring request for exactly this every 6 months or so on pd-list! With that argument, the iemguis would be badly spent lines of code. After all we don't *need* them to use pd ... On Mar 10, 2014, at 7:00 AM, pd-list-requ...@iem.at wrote: On 2014-03-09 14:29, me.grimm wrote: Hi Miller, I know you probably have more pressing problems but it would be nice to get something like [getdir] in vanilla before you hit those 100k lines of code OR 50 years are up :) that's probably badly spent lines of code. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 100k lines of code (was libpd separating gui from core)
It doesn't have to be a direct include, could be done with any sort of mechanism. I do agree that [getdir] is one of the few essential externals I still need after I ported my patch lib to vanilla ... that and [stripdir] / [splitfilename] but the latter will be possible with the new [list tosymbol] / [list fromsymbol] mechanism. On Mar 10, 2014, at 11:10 AM, i go bananas hard@gmail.com wrote: I'd also like to see [getdir] made vanilla. There is literally no way to do that without the external. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udoo board sound issues
I've tried my both Roland Edirol UA-25 UA-25EX and both work great. The dedicated USB controller makes these guys work as compared to an RPI where I can't get full duplex without tons of dropouts. I'm using a Linaro install which boots to the console and runs the PD through scripting. The speed is great as compared to my old wearable computer. 4 cores makes a difference. I had to recompile my kernel to add midi support, but that's working great. It's not too bad, actually. I also built Pd-vanilal from source which was pretty easy using ./configure + make. I also have a script which fetches externals and builds/installs the agains vanilla so I have the few externals I need. As with my previous experience running Pd + embedded Ubuntu, I get great performance with RT permissions, the -rt startup flag, and ALSA. Jack is needless overheard unless you want to work with other Jack-enabeld apps. Same with X windows, although my setup was running great in X with pd + ALSA in testing. From your description, it sounds like your main issue is jack pd are probably not running in realtime. I can sent you my install notes if you want (or put them online, as I've been meaning to). Also, are based in the NE within driving distance to Pittsburgh? We could do a patching circle/UDOO setup afternoon :D On Mar 9, 2014, at 5:14 PM, pd-list-requ...@iem.at wrote: From: Miller Puckette m...@ucsd.edu Subject: Re: [PD] udoo board sound issues Date: March 9, 2014 at 5:07:54 PM EDT To: Simon Iten itensi...@gmail.com Cc: PD list pd-list@iem.at H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should be able to do some tests when I get back, assuming nobody else has figured this out first. cheers Miller On Sun, Mar 09, 2014 at 09:57:45PM +0100, Simon Iten wrote: hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) cheers. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Data structures and click event
On Mar 8, 2014, at 5:59 AM, pd-list-requ...@iem.at wrote: No. It requires a toolkit that has modern 2d features like affine transformations and opacity, etc. Pd-l2ork leverages Tkpath, a tcl/tk library. Other modern toolkits like Qt have their own 2d interfaces with the same features and could be used, but tcl/tk on its own does not. for the non-unix users out there? For OSX, one of the tcl/tk libraries-- Tkpath needs to be ported from Carbon to Cocoa. I have this about halfway done. I finally found the old QuickTime Carbon headers so I could port the old school font creation to CoreText. All of the old Quick Draw stuff is no longer on the Apple Developer docs, so it was a bit confusing at first. It will take a little while though since I dip into it now and then among everything else. I haven't investigated a Windows port yet but it's probably mostly a matter of setting up the proper compile environment more than anything else. Granted one would probably need to tweak pd.tk and L2ork's build script, but getting set up in Windows seems to be where most of the work is. (At least in my experience so far.) It shouldn't require too much beyond the current steps to build vanilla or extended on Windows: a mingw + msys enviornent. Tkpath uses an autoconf build system so it should be fine on Windows as long as you point it to the tcl/tk headers. The issue with OSX is that it simple hasn't been updated in a while but I imagine it's fine on Windows since MS moves very very slowly as far as moving to new APIs is concerned. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd and Unity
Are you using the libpd master branch? Can you use the pd_045-4 branch as that will become the new master soon. The change is that I added hook setter functions and updated all of the wrappers. I wasn't able to test the csharp wrapper, so if that's what you're using on Windows it would be nice to double check that it's working. On Mar 5, 2014, at 10:35 PM, pd-list-requ...@iem.at wrote: From: Varun Nair nothingtok...@gmail.com Subject: [PD] libpd and Unity Date: March 5, 2014 at 6:16:05 PM EST To: pd-list@iem.at Hi all, I extended Patrick Sebastien's work in libpd-4-unity on Windows and now have it working on OSX and Android. iOS is pending but will happen soon. The whole API hasn't been tested, but basic functionality is in place and works. More info here. Feedback and bug reports are welcome! Best, Varun Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RjDj/ScenePlayer for iOS?
Thanks Dan, Chris, and a few others who sent something. Yesterday was one of those bad days + I was sick :( I guess I've just been a bit disappointed with what I perceived as a lack of interest, but then again that would probably change once it's out on the App Store. I started with a need that transformed into an open tool for everyone so I've probably spent alot more effort to get it to that quality then if I only needed it for a few personal projects. I will be happy when I get video and patches back from people using it in performance ... not to mention myself getting away from coding and doing the same! Again, if anyone wants to join the beta, let me know. I'm going to probably have 1 or two more releases as I add some things I think are needed for an app store release. On Mar 7, 2014, at 9:37 AM, pd-list-requ...@iem.at wrote: From: Dan Nigrin d...@defectiverecords.com Subject: Re: [PD] RjDj/ScenePlayer for iOS? Date: March 7, 2014 at 7:00:07 AM EST To: PD List pd-list@iem.at Dan, FWIW I very much appreciate the work you've done on PdParty, and though as you know my testing was very brief and limited primarily to MIDI-related support, it worked well in the simple test case I programmed. Perhaps more importantly, and as has been discussed a bit in here in recent weeks, as a purely Max-based person till now, I began to explore Pd for the sole reason that it offered more iOS and Android support than what's currently available for Max. Things like PdParty are what brought me this way... Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RjDj/ScenePlayer for iOS?
Yes, Iohannes, RjDj scenes work in PdParty. I have tested all of the scenes I have from years ago, including interactive ones which use the accelerometer like the bouncy scene. I do not support scenes generated by the now defunct rjc1000 elper app nor do I support the scene paging feature used in the rjdj intro scene, but AFAIK that's the only scene that used it. I would hope that other libpd based apps would adopt the same rjdj messaging standard so patches would work, at least, between PdParty PdDroidParty. -- The following is not aimed at you, IOhannes, but at noone in particular… begin rant PdParty has been in beta since September 2013 and I've been talking loudly about it since spring of last year. Back then I said it would support RjDj scenes and even posted about my intentions when RjDj was removed from the app store in 2011. With the beta, I wrote a very detailed user guide that clearly states that it not only support RjDj scenes but also has all of the same rj objects and events ([#touch], [#accelerate], etc). At this point, it is clearly beyond a port of PdDroidParty as I have reimplemented *all* of the Pd-vanilla/iem guis in Obj-C CoreGraphics. In fact, you can animate and change their color, etc on the fly like in the regular pd gui. My long term dream would be to add patch creation/editing but that's really contingent on getting some sort of gui helper layer into libpd as I have no desire to reverse engineer parts of the existing gui framework. I have put out beta calls more than once and have only had perhaps middling interest, with a few people saying they installed it, but far less people have signed up than I would have thought. (A thank you to those that have and bigger thank you to those that have provided feedback.) I recently was told that having to sign up for a beta testing service was far too difficult and I should just put it on the app store. I imagine those same people would complain on the app store when something that could have been tested in beta didn't work. The whole point of a beta is to get help finding bugs in a private manner from people who would know what to look for, not the general public or students trying to use it in a class. It's supposed to be a community effort to HELP ME put out a new platform app for FREE. Once on the app store, it should basically *just work* otherwise it will be uninstalled more quickly than the time it took to install it. Also, I was hoping that people would also help me make cool demo scenes patches, but that hasn't happened either. All of this is after I've spent probably 2 months of full time unpaid solo work on PdParty in 2013. I could expect that people would in the very least show interest in this project and help me work on it for when I will basically put it out for free on the App Store. end rant -- Forwarded message -- From: Joe White white.j...@gmail.com To: Chris McCormick ch...@mccormick.cx Cc: pd-list pd-list@iem.at, IOhannes m zmölnig zmoel...@iem.at Date: Mon, 3 Mar 2014 10:02:26 + Subject: Re: [PD] RjDj/ScenePlayer for iOS? Hi IOhannes, Sorry I can't link directly to the right place but the user guide I linked to previously mentions there is support for what you're looking for. Search for #touch on this page https://github.com/danomatika/PdParty/blob/master/doc/PdParty_User_Guide.md Cheers, Joe On 3 March 2014 02:16, Chris McCormick ch...@mccormick.cx wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi IOhannes, On 03/03/14 02:20, IOhannes m zmölnig wrote: On 02/28/2014 02:41 PM, Chris McCormick wrote: PdDroidParty supports multitouch thanks to Muddu Kishan. i think i was unclear here: i know that PdDroidParty has multi-touch support (as shown in the demo). but what i really meant was: raw access to (multiple) pointer(s), like the #touch message in RdDj, No, PdDroidParty does not do that. Would be minimal to implement. If someone submitted a patch to add that I would definitely merge it. Cheers, Chris. -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] PdParty: name change ideas?
Howdy all, I will begin the process for releasing PdParty on the iOS App Store pretty soon. I was thinking that if I ever want to change the name, I need to do it now. When I started, PdParty was mainly a port of PdDroidParty. Now, it's become something more and I'm thinking of a new name for a different identity. Don't get me wrong, PdParty is already a pretty good name and I may keep it, but I'd like to brainstorm anyway. Any suggestions? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
Well, you're not using any tcl/tk if you're using libpd in ofxPd. The blame falls elsewhere. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Feb 28, 2014, at 3:13 AM, Billy Stiltner billy.stilt...@gmail.com wrote: it's the overhead of the os that gets in the way, i started to try ofxpd but found ofxui to be slow as all getout with my old machine. what would be nice is someone fixing tcltk On Thu, Feb 27, 2014 at 4:00 PM, Ivica Ico Bukvic i...@vt.edu wrote: For instance, it seems like there are two main concerns floating around: a) multiple instances of pd b) separating GUI from core I would add a c) here which is what pd-l2ork has been doing, namely getting rid of all known bugs and streamlining experience until it reaches a level of stability where issues are a rare occurrence. My take is that refactoring becomes a lot easier at that point because one will have a much better idea what components should look like. Otherwise, fixing things post-refactor will net in even more headaches where two parts may end-up being potentially out of sync with each other, resulting in a broken app. There are other suggestions like platform-specific vectorization and multi-threaded support, but if you try to do these at the same time, you reduce the chance of ever getting the code back into vanilla. They can be taken on after. IMO, the best thing to do going forward for a) would be to sync up with Miller and what he netted out with last time this was discussed ( see thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html). It seemed like he was proposing to take a hefty chunk of the work on, or maybe if he is confident in merely the approach, someone else can have a go at it. Having been on this list for quite a few years, I know of only one person who was allowed to significantly contribute/alter the core and that was Hans. And even that amounted to mainly cleaning up tk code to make it more legible (yes, this is a gross oversimplification, there was internationalization, console verbosity, and many other little things, but in general the brunt of the work was lateral in nature). ___ 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] libpd separating gui from core
On Wed, Feb 26, 2014 at 2:58 PM, Rafael Vega email.r...@gmail.com wrote: It's been fascinating for me to see what has happened with OpenFrameworks and their Do it with others philosophy. It would be great if the Pd community would migrate into something similar. What's interesting to me is that we had a similar issue in OpenFrameworks a couple of years ago. As the community grew, more and more people wanted to contribute but there was a lack of focus and the priorities of the project were hidden by the core devs. We've had a couple of developer conferences/meetups where decisions were made on how to best handle the needs of the core people who started the project while opening up overall development to capitalize on the experience of others outside of the core group. I must admit there were times where I wanted to fork OF or split off development in some other way, but instead I decided to knuckle down and see if we could work things out. I think it's worth a try in Pd. Even if it takes a bunch of work up front, it will be worth it in the long run. It's been an involved social process but, overall, we are moving ahead quite well. There is a public roadmap, community action leaders (audio, 3d, graphics, linux, etc), a robust forum, etc. GitHub has been amazing helpful in this area is probably one of the main tools that makes this collaboration possible. There have been missteps and there are still issues to resolve, but we're getting there. For instance, there will be a Documentation sprint at CMU in a few weeks. -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Myo armband and Pd?
They have an SDK, so I imagine you can get the data out and send it over OSC. At least thats my plan when I get my dev Myo … :D From: Richie Cyngler glitch...@gmail.com Ha! Excellent point, I guess it's the pirate me interested in their tech but refusing to accept their terms. The original Kinect was packaged similarly and cracked within what weeks if not days? Although granted that was I think unique technology at the time. On Sun, Feb 23, 2014 at 4:05 PM, Simon Wise simonzw...@gmail.com wrote: On 23/02/14 10:47, Richie Cyngler wrote: https://www.thalmic.com/en/myo/ Is anyone working with this? Unfortunately it's closed source and their locking down the data stream from what I've read. I actually can't find what sort of data it does put out other than a set of predetermined gestures. Anyone else curious or have more info about this device? if they are saying go away! that loudly why would you be interested? Simon -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote: On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward? I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison. I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this. I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way. That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up. Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals. I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I don't want to build a bunch of patches around new functionality that just won't work on a mobile phone and would be harder to debug. If the reality is as you say, then I'm not really interested in spending my time hacking on our little island. And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward. That remake was hasty of mine and short sighted. My background is in engineering and I hate seeing effort split up and duplicated on things that we all want/need. If we all respect Miller, maybe we can also respect that we could find a middle ground with both his goals and ours. -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
Exactly. If we can build a list of things that should/could be in the core, then we have a starting place to see if there is a way to work into into either vanilla or a wrapper like libpd. As we do in OpenFrameworks, I've started a PiratePad for general ideas/requirements. Feel free to add to this: http://piratepad.net/PureData-middle-ground-ideas On Mon, Feb 24, 2014 at 2:44 PM, Jonathan Wilkes jancs...@yahoo.com wrote: So let's just take a concrete example: $@ syntax. It is a dollarsign variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands to the incoming arguments. In an object box this expands to the arguments of the parent. The code for this feature affects Pd's message parser, which is in the core. This is just an example-- there is a whole category of features which require changes to core code like this one. If you have a description of a democratic development process that can implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how it works, and if it's maintainable I'll help you implement it. -Jonathan On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic i...@vt.edu wrote: *From:* Dan Wilcox [mailto:danomat...@gmail.com] *Sent:* Monday, February 24, 2014 11:34 AM *To:* Ivica Bukvic *Cc:* Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann *Subject:* Re: [PD] libpd separating gui from core On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote: On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward? I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison. But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd) I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this. I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way. I am all ears :-) That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up. Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need
Re: [PD] libpd separating gui from core
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
Also, to be honest, at this point if Cycling 74 came out with Max runtimes for iOS and Linux, I would probably switch. I don't say that because I don't like PD, but more from a pragmatic point of view where I consider which project is currently progressing in the long term. For instance, on PD-dev, we're talking about updating GEM so it will work with the new Apple APIS aka in 64bit on any Mac OSX 10.7+. The writing has been on the wall for that transition FOR YEARS but there has been no work on that front. I must admit that I'm volunteering to make this update not because I use GEM, but because I fear PD losing out to Max when GEM doesn't work in computer labs running new Macs. Again, this is from personal experience at a major teaching institution where I was trying to push teaching PD but, frankly, it just wouldn't cut it for course requirements and taste of the professors involved. And I take that as a personal failure. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Feb 23, 2014, at 7:37 AM, Dan Wilcox danomat...@gmail.com wrote: On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Feb 23, 2014, at 12:14 PM, Max abonneme...@revolwear.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ok, Dan, i can feel you there. but let's not mix up the GUI-core separation with the GEM on OS X question. As much as their consequences are similar, they are fundamentally different in their implementation, no? Max, Forgive me as I'm not going to answer specifically regarding GEM :D That was just a recently re-opened wound so it made a pointed example. I think what bothers me is that this comes up again and again and still the main response is: what we have now is fine. That, after plenty of effort and previous code implementations that died on the vine and it feels already like trying to push libpd in that direction will yield the same result. I'm not trying to single out specific people, but just my general feeling in the project. Maybe I'm off base, but I feel that pd needs real modernization or it will get less and less adoption. Sure it will be around, but you wont see as many beginners starting with it. At this point a continued debate over whether the gui should be multithreaded or not seems moot to me. That comes in contrast to my involvement with the OpenFrameworks community which is growing via leaps and bounds. Sure, it's a younger project, but we've already had a number of developer conferences, developed a concerted development roadmap, delegated community leaders, etc. We work together. There have been a number of residencies sponsoring further development. I would really like to see that with this community as I really love working with PD but, again, why bother trying to push forward such an agenda on my own? I could probably rebuild my entire setup using Super Collider but I simply like patching audio better. I'm not trying to weigh blame on anyone, just explain the situation as I see it. I suppose from a different perspective, I'm an outsider coming in and trying to needlessly shake up things that are already working, proposing premature optimizations, etc. Questions that comes to my mind when I see the GUI-core separation discussion is this: Let's assume - totally hypothetically spoken - there is a company or individual who would sponsor this effort. 1. Is there someone capable of completing the task? I can probably do it if I wrap my head around the pd core. Peter Brinkmann and Jonathan W are probably better suited with their core familiarity and, obviously, Miller knows it through and through. The problem, of course, is that I or whoever would do this would need to be able to sit down, focus, and crank it out. I can't answer who could help sponsor that. My initial idea would have been STEIM, but do to NL budget cuts, they now have to rent the studios so the previous no stings attached residencies I had before are sadly no longer available. Another answer would Universities, but so far, I haven't seen much movement on this from previous discussions. The last option would be how I've funded my most recent project: freelance work and dedicating time off to work on my own projects. I could probably manage that, if needed, but I would *really really really* hate to spend a month on something that may not be adopted o go anywhere. I'd like to have the decisions made before I go out on a limb on my own dime. Open source is all about sharing, but that doesn't mean we write code for everyone else for free. 2. Would the result of this work be accepted by Miller and become vanilla? As history has shown, the chances are limited. Again, there is probably a good way to do it where you could choose whether to use a single or multithreaded core but the real stakeholders are absent from the discussion. 3. How long would that take? Dunno. A few full time weeks for one person, probably (at least from my estimate). I imagine that could be shorter if there is a core developer meeting and overall architectural decisions could be hashed out and a roadmap developed. Sadly, this would be perfect for Google Summer of Code. m. Am 2014년 02월 23일 21:37, schrieb Dan Wilcox: On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc
Re: [PD] libpd separating gui from core
Well, then I'm simply out of the loop and mostly-off base. Woops, sorry. I'll go there and see if we can keep it going. Looks like we're talking about both multi-threading and multi-instances which would be a big move towards solving some fundamental problems. Also, it's not really a discussion any more, I turned it into a rant. :P In any case, I'd rather let my frustration be known and apologize later than sit by and *hope* for updates. In any case, if I can be helpful I'm more than willing to pitch in and get things done. On Feb 23, 2014, at 2:33 PM, Miller Puckette m...@ucsd.edu wrote: Hi all - just a short note since this discussion is much too wode-ranging to address in full... 2. Would the result of this work be accepted by Miller and become vanilla? As history has shown, the chances are limited. Again, there is probably a good way to do it where you could choose whether to use a single or multithreaded core but the real stakeholders are absent from the discussion. I think the main stakeholders are Pd users :) Anyhow, there's a useful discussion thread about pdlib instancing here: http://lists.puredata.info/pipermail/pd-dev/2013-12/019693.html and there's a wonderful series of talks underway at IRCAM about the problems of real-time media computing in general: http://repmus.ircam.fr/mutant/rtmseminars cheers Miller Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 02/23/2014 07:37 AM, Dan Wilcox wrote: On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. This is probably naive, but wouldn't it suffice to have an object that does automatically what the user is forced to do manually atm? I'm not saying there should be some mechanism to separate this object from that ... only that the gui should be on it's own thread, audio in the audio callback thread, and something like GEM running opengl in it's own thread. This is how modern applications work and also how using libpd inside OpenFrameworks works, same for iOS. Manual -- user opens a Pd instance for GEM and a separate Pd instance for audio Auto -- user creates an object [foo-audio-magic somepatch.pd] which automatically fires up a separate instance-- _not_ a child of the first-- for the audio. Or it *just works*, like Jitter in Max. Whether we split hairs about *how* it should work, the fact remains that to most people I introduce to Pd to, Max is more attractive as things like audio video *just work* together. If the stakeholders of Pd are truly the users of Pd, then the complaints and requests for solving these kinds of issues should be obvious from the last 5-7 years ... Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. How do you know that's due to Pd's single-threadedness, and not some CPU-hogging object, or a poorly optimized object chain, or Pd doing GUI calculations in the core thread as well as tk's thread? It can happen when opening patches in libpd, including those without CPU-hogging objects. This is obviously *without* the gui. Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc That particular problem is due directly to *_getrect calls in a patch with lots of objects (and possibly a bunch of *_click calls if hovering over an object that does a lot of computation in such a function). It's not super easy to solve, but it's approachable because the Pd-GUI already exists. But that's a completely separate issue from getting something like GEM to run in its own thread. Yeah, stuff like that we should be able to solve. I'm not for ditching the Tcl/Tk gui at all. The work you and Ivica have been doing seems to be going a long way to fix this. Great! I just really hope this goes back into vanilla somehow or can be split up into between libpd and a gui implementation, etc. Otherwise, I fear a return to DD. Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. It's not acceptable, but if you want to move forward _and_ do work that will be in sync with or accepted into Pd vanilla I don't see a way forward. I can't even get help docs into Pd vanilla, and they were written to the PDDP spec that this community came up with and approved. And as you know, there's a publicly viewable list of the same exact frustrations from all kinds of developers with various styles of communication. This is what I'm worried about and if that's truly the case, why bother really? At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Did you use any of the Pd-l2ork versions before it moved to Tkpath? It didn't solve the *_getrect problem I mentioned above, but it solved a whole lot of the problems that cause dropouts while editing, mainly by shooting way fewer messages across the socket. True, but will that be integrated back into vanilla? It's the same problem again ... Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
Coming back on topic: On Feb 23, 2014, at 8:15 PM, Ivica Bukvic i...@vt.edu wrote: If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire. Except I see there being a third middle, ground via libpd. IMO Miller is best at the core and the community is the best at adding functionality around it and creating a modern GUI. My take on the future (and I believe Hans has brought this up as well): If we could find a way to abstract the gui interface as libpd already does for midi and messaging, I see Pd-vanilla keeping the existing gui and using a single threaded libpd as the core. Then the forks utilize libpd for the core and wrap it with their newer, updated whizz-bang accelerated guis using perhaps a multithreaded libpd as their core. We know the issues, if we can work out a way to solve what's needed for the gui abstraction and hopefully multi-threaded/multi-instance support added to the core then there's a way to have the best of both worlds. For instance, multi-threading support can and should be a compile time flag and it can simply be turned off in Pd-vanilla. It may involve some work and some pain, but I really think it must be possible. My fear is that, in the long run, the forks may diverge too much from the more slowly evolving vanilla and eventually lose integration with it completely. That splits the community for real, one that is perhaps already too splintered. Pd-L20rk is really exciting, but it would be sad if it eventually might split off from the prime mover you (and we all) are so indebted too. I guess what I'm saying in a nutshell is: I see libpd as the middle ground so Miller can focus on the pd core without the community and its forks having to muck up Pd-vanilla. It should be possible, I think we really just need to get all of the Pd devs in one room and hash out what that middle ground could be. Then we have a combined roadmap instead of hacking away in isolation. Does that make sense at all? It seems so obvious to me and is one of the reasons why I'm working on libpd. For me, it's a sustainable future. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Feb 23, 2014, at 10:46 PM, Ivica Bukvic i...@vt.edu wrote: libpd requires a lot of what pd-l2ork offers in order to be able to move forward (obeying stacking order for instance, that are a prerequisite for global system-wide presets as well as editing tools like undo/redo and tofront/back). Those sound like things that should/could be in the core. pd-l2ork also improves on pack, route, select, and trigger to make things easier for newcomers to understand and for professionals to get to their results faster. None of these are a part of the core and yet they very much belong to libpd... Those are objects and they can simply alias the existing objects on load, that or add an option to the core to not load existing objects / allow conditional calls the the object setup functions. I simply don't see fragmentation as a bad thing. Look at Linux--fragmentation galore. And yet we all get along just fine (well for the most part ;-) The kernel is fragmented? Your talking distros and I see things going more Linux BSD. If it will make it any easier for you, refer to pd-l2ork as anchovies and forget for a moment that it has any compatibility with pd whatsoever. This could ostensibly become a reality in not so distant future from now (well the compatibility part, not so sure about the name). I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... If the reality is as you say, then I'm not really interested in spending my time hacking on our little island. On Sun, Feb 23, 2014 at 9:40 PM, Dan Wilcox danomat...@gmail.com wrote: Coming back on topic: On Feb 23, 2014, at 8:15 PM, Ivica Bukvic i...@vt.edu wrote: If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire. Except I see there being a third middle, ground via libpd. IMO Miller is best at the core and the community is the best at adding functionality around it and creating a modern GUI. My take on the future (and I believe Hans has brought this up as well): If we could find a way to abstract the gui interface as libpd already does for midi and messaging, I see Pd-vanilla keeping the existing gui and using a single threaded libpd as the core. Then the forks utilize libpd for the core and wrap it with their newer, updated whizz-bang accelerated guis using perhaps a multithreaded libpd as their core. We know the issues, if we can work out a way to solve what's needed for the gui abstraction and hopefully multi-threaded/multi-instance support added to the core then there's a way to have the best of both worlds. For instance, multi-threading support can and should be a compile time flag and it can simply be turned off in Pd-vanilla. It may involve some work and some pain, but I really think it must be possible. My fear is that, in the long run, the forks may diverge too much from the more slowly evolving vanilla and eventually lose integration with it completely. That splits the community for real, one that is perhaps already too splintered. Pd-L20rk is really exciting, but it would be sad if it eventually might split off from
Re: [PD] Legal restrictions for apps
Short answer: yes, it's sufficient to provide the object files and static libs As far as my understanding of GPL LGPL goes, you do not need to publish your app sources when using LGPL libraries as the Lesser part of the LGPL allows for distribution and is not viral. From GPL vs LGPL: The GPL and LGPL prohibit covered software and all derivative work from having its source code hidden from the public. The GPL takes the strong stance, saying that all software that uses the GPL software must itself be released under the terms of the GPL. This is known as a reciprocal, share-alike, or viral license, and legally prohibits closed source software developers from using GPLed code. In contrast, LGPL provides an exception to the usage and distribution of the software, allowing for non-free products to include the LGPLed software. Also see Compatibility between the iPhone App Store and the LGPL: If you’re developing an iPhone application that you intend to submit to Apple’s App Store and you want to make use of a third-party’s software library that happens to be licensed under the GNU Lesser General Public License (LGPL), you have a couple of choices according to the license requirements: • You can open-source your app. Specifically, you provide to your users the source code of your entire application under the LGPL or GPL. That means for example all the .h and .m files. • You can keep your app closed-source, but you provide to your users all the object code of your application necessary to re-link your application. That means for example all the .o and .a files. Most people forget that this option is in fact available to iPhone app developers. Of course, if you modify the library itself, you have to provide these code changes in source form either way. On Feb 5, 2014, at 5:55 AM, Ed Kelly morph_2...@yahoo.co.uk wrote: Hi Dan, Miller et al. I'm still somewhat confused about the LGPL issues with regarding apps. Say I make an app that uses LibPd, and include an object or library that is licensed with an LGPL license. Would I have to include all source code for the app itself, or would it be sufficient to provide object files and source code for just the LGPL library I have used? Cheers, Ed Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ On Sunday, 26 January 2014, 19:29, Dan Wilcox danomat...@gmail.com wrote: Howdy Miller, Sorry to bring this up again. The license in the expr source code headers has been updated to LGPL, but I just noticed the post in vexp_if.c line 386 still reads: expr, expr~, fexpr~ version %s under GNU General Public License . On Oct 5, 2013, at 8:53 PM, Dan Wilcox danomat...@gmail.com wrote: Awesome, thank you. I'm glad we could figure it out. I remember checking a few times and we discussed this in libpd. I kept getting confused by the different licenses. On Oct 6, 2013, at 3:55 AM, Miller Puckette m...@ucsd.edu wrote: OK... done and pushed to git repo. cheers M On Sat, Oct 05, 2013 at 12:18:23PM -0700, Miller Puckette wrote: Hmm... Looking back in the git repo i saw: commit 42f3e5f8dbc60ad644e9f8a1c5b61d1847e19470 Author: Miller Puckette m...@ucsd.edu Date: Thu Nov 3 11:40:35 2011 -0700 change expr~ source to LGPL license (with IRCAMs permission :) I had quite forgotten about this (and still can't remember this ever having happened) but here's the e-mail I got from Shahrokh: On Tue, Oct 25, 2011 at 02:50:53AM -0700, Shahrokh Yadegari wrote: Dear Max and Miller, I got news from IRCAM that they are willing to release expr code on LGPL. Will that solve the current licensing problems? Max, could you communicate to the list and let me know what they think about this. I hope this helps. thanks, Shahrokh So I think we're in the clear (although I hope Shahrokh kept the mail from IRCAM authorizing this!) I'll go on and change the source over here so that it appears in the git repo. (This will take some time as I first want to merge my 0.45 fixes into 'master'.) cheers Miller Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Legal restrictions for apps
Ed, shortest answer: Don't use [expr] if your worried about this. They don't like it, but we can still *technically* use LGPL code like [expr] by providing the object files, which are of course useless to anyone who hasn't jailbroken their device or paid the $100 iOS dev tithe. Lots of apps use LGPL libs. This really all comes back to the fact that iOS apps must be statically linked and the distribution channel is controlled, which is why GPL code can't legally be used on the App Store. On Feb 5, 2014, at 8:37 AM, pd-list-requ...@iem.at wrote: Much of the discussion below was prompted by questions about using libraries with iOS and in particular compatibility with Apples stores. Apple hasn't allowed either GPL or LGPL software on their app stores, libPd avoided expr etc to conform with Apple's policies and hence be allowed on Apples app stores. Changing to LGPL won't change that, Apple does not like copyleft. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Multi-input USB audio into Raspberry Pi
FWIW forcing USB 1 mode works for some soundcards, but not for those that require asynchronous communication (my Roland UA-25). I'm glad it works for this device, but most of us are still out in the cold. The RPI has some inherent compromises for the goal of the project (cheap, general purpose computing) but I really wish they had added a dedicated USB controller! On Feb 3, 2014, at 2:50 AM, pd-list-requ...@iem.at wrote: From: Brian Fay ovaltinevor...@gmail.com Subject: Re: [PD] Multi-input USB audio into Raspberry Pi Date: February 3, 2014 at 2:49:54 AM EST To: Simon Wise simonzw...@gmail.com Cc: pd-list pd-list@iem.at In case anyone looks at this thread, I'd better mention that it seems that using CCRMA's distribution fixes my audio problems with the Behringer UCG102. I had been using the standard Raspbian distro when I wrote my comment. I believe that distribution uses a different kernel than Satellite CCRMA, which is optimized more for embedded audio projects. I had been unable to do duplex audio at 44100hz (had to switch to 32000), but now it seems to work fine (even when running pd with an X11-forwarded GUI). There's no noticeable dropouts at a latency of 10ms, at least in my initial testing! In order to get this to work, I simply had to change the text of /boot/cmdline.txt to the text politely included in /boot/cmdline-usb1.1-only.txt (thanks, Stanford guys!) Anyway, just hoping I haven't led anybody astray from the Pi with my earlier (somewhat misinformed) comment. I'd still be a little wary of using devices with more channels or without linux drivers. -Brian Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] job offer in Weimar
Howdy Max, Out of curiosity, why did you leave? Find a better job elsewhere? Wanted to get out of sleepy Weimar? Ich finde diese Job ein bisschen interessant, aber denke ich, das meine Frau mag nicht Weimar. Sie kommt aus Hamburg und vielleicht Weimar ist zu klein. :D On Jan 31, 2014, at 1:18 PM, pd-list-requ...@iem.at wrote: From: Max abonneme...@revolwear.com Subject: [PD] job offer in Weimar Date: January 31, 2014 at 8:22:36 AM EST To: pd-list@iem.at -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At the Bauhaus-Universität Weimar is another position open. Since understanding basic german is a requirement, the announcement follows in german. This position is more or less what I was doing there when I was employed there. Please also apply even if you don't fulfill the requirements completely. And let me know if you applied. M. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] job offer in Weimar
Woops. Sorry, I meant to repsond off list. :P On Jan 31, 2014, at 4:00 PM, pd-list-requ...@iem.at wrote: From: Dan Wilcox danomat...@gmail.com Subject: Re: [PD] job offer in Weimar Date: January 31, 2014 at 1:39:25 PM EST To: pd-list@iem.at List pd-list@iem.at Howdy Max, Out of curiosity, why did you leave? Find a better job elsewhere? Wanted to get out of sleepy Weimar? Ich finde diese Job ein bisschen interessant, aber denke ich, das meine Frau mag nicht Weimar. Sie kommt aus Hamburg und vielleicht Weimar ist zu klein. :D Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Face tracking
Is [pix_opencv_facetracker] threaded? If not, I'd suggest using FaceOSC to avoid the 30fps it's locked too when tracking and lower framerate when searching. On Jan 29, 2014, at 6:00 AM, pd-list-requ...@iem.at wrote: From: Antoine Villeret antoine.ville...@gmail.com Subject: Re: [PD] Face tracking Date: January 29, 2014 at 5:17:20 AM EST To: Jean-Marie Adrien j...@jeanmarie-adrien.net Cc: pd-list@iem.at List pd-list@iem.at Hello, there is [pix_opencv] around there : https://github.com/avilleret/pix_opencv This is a fork (a modified copy) of the main sourceforge external repository. This is not included in pd-extended but I've planned to release binaries for MacOSX, Windows and Linux in a not too far future... Concerning FaceOSC, it wroks great and it's now included in [pix_opencv_facetracker], it's pretty experimental since it has not been tested widely. Depending on what you need exactly, you can also use the [pix_opencv_haarcascade] external with some free data set or with your own trained model. Hope this helps. Antoine Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] relative paths with mrpeach [midifile] in abstraction
Thanks Yeah I was thinking of trying that, but I don't have the time atm. Thought I'd throw out the idea when I ran into the issue and needed to build a relative-absolute path symbol converter for now. On Jan 26, 2014, at 11:43 AM, Martin Peach martin.pe...@sympatico.ca wrote: On 2014-01-25 03:10, Dan Wilcox wrote: Is there some way to modify mrpeach [midifile] so that it will correctly handle relative paths while it's in an abstraction? I notice that soundfiler does this. I could probably do that by copying the way [soundfiler] does it. I need to look at the code. Martin Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Legal restrictions for apps
Howdy Miller, Sorry to bring this up again. The license in the expr source code headers has been updated to LGPL, but I just noticed the post in vexp_if.c line 386 still reads: expr, expr~, fexpr~ version %s under GNU General Public License . On Oct 5, 2013, at 8:53 PM, Dan Wilcox danomat...@gmail.com wrote: Awesome, thank you. I'm glad we could figure it out. I remember checking a few times and we discussed this in libpd. I kept getting confused by the different licenses. On Oct 6, 2013, at 3:55 AM, Miller Puckette m...@ucsd.edu wrote: OK... done and pushed to git repo. cheers M On Sat, Oct 05, 2013 at 12:18:23PM -0700, Miller Puckette wrote: Hmm... Looking back in the git repo i saw: commit 42f3e5f8dbc60ad644e9f8a1c5b61d1847e19470 Author: Miller Puckette m...@ucsd.edu Date: Thu Nov 3 11:40:35 2011 -0700 change expr~ source to LGPL license (with IRCAMs permission :) I had quite forgotten about this (and still can't remember this ever having happened) but here's the e-mail I got from Shahrokh: On Tue, Oct 25, 2011 at 02:50:53AM -0700, Shahrokh Yadegari wrote: Dear Max and Miller, I got news from IRCAM that they are willing to release expr code on LGPL. Will that solve the current licensing problems? Max, could you communicate to the list and let me know what they think about this. I hope this helps. thanks, Shahrokh So I think we're in the clear (although I hope Shahrokh kept the mail from IRCAM authorizing this!) I'll go on and change the source over here so that it appears in the git repo. (This will take some time as I first want to merge my 0.45 fixes into 'master'.) cheers Miller Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] relative paths with mrpeach [midifile] in abstraction
Is there some way to modify mrpeach [midifile] so that it will correctly handle relative paths while it's in an abstraction? I notice that soundfiler does this. Bascially, I have a wrapper around midifile but it assumes given relative paths are relative to the wrapper patch and not the parent patch. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] mrpeach [midifile] timing off in pd-ext, works with latest pd-vanilla
Howdy all, I've been putting some songs together using mrpeach [midifile] and I calculate the metro playback speed using the tempo time signature (as per an example by Martin on the last ~6 months ago). I noticed that on Pd-Extended 0.43 the playback is off, around 10-20 bpm too slow. The same patch midifile on Pd-Vanilla 0.45-4 plays back at the correct speed. This on the same system with the same audio settings, using the same compiled [midifile] external from the Pd-extended app bundle. Just letting y'all know in case you've run into a similar situation. Out of curiosity, what changed in PD 0.45-4 that fixes this? Soemthing with the metro timing? I must admit I went through the diffs when I updated the libpd core but I don't remember where that might have been ... in any case, I'm glad to see my workflow is saved as playback now works correctly again, with the target being a libpd app using 0.45-4. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gametrak question
Yes, but it has to be a Gametrak for PC. The Gametrak for PS2 *will not* show up as an HID device when plugged into a computer. On Jan 22, 2014, at 5:19 PM, pd-list-requ...@iem.at wrote: From: Peter P. p8...@aol.com Subject: Re: [PD] gametrak question Date: January 22, 2014 at 5:13:47 PM EST To: peiman khosravi peimankhosr...@gmail.com Cc: PD List pd-list@iem.at * peiman khosravi peimankhosr...@gmail.com [2014-01-22 23:05]: Does anyone know if there is a way of connecting the gametrak to pd without modifying the hardware itself? I use it with [hid] and it works well (mine have the usb connector) Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ALSA MIDI problem
Here's a portion of a startup script I use: echo rc_starts_pd: strating pd pd -rt -nogui -alsa -audiodev 4 -audiobuf 10 -alsamidi $PATCH # renice pd for much higher priority renice -10 $(pidof pd) # wait for pd to initialize KA=$(aconnect -i -o | grep Pure Data) while [ $KA = ] do sleep 1 echo rc_starts_pd: pd alsamidi not ready KA=$(aconnect -i -o | grep Pure Data) done echo rc_starts_pd: pd alsmidi is ready # connect the UA-25 midi to Pure Data echo rc_starts_pd: alsa midi connect 'UA-25' - 'Pure Data' aconnect 'UA-25' 'Pure Data' aconnect 'Pure Data':1 'UA-25':0 # connect the VIEWCON dongle midi to Pure Data echo rc_starts_pd: alsa midi connect 'VIEWCON..' - 'Pure Data' aconnect 'VIEWCON..' 'Pure Data' aconnect 'Pure Data':1 'VIEWCON..':0 -- It starts Pd, then waits until the PD midi device is registered with ALSA before trying to connect two Midi devices: UA-25 VIEWCON.. You could run the script from you ~/.bash_profile which would call it as soon as the user is logged in. I use this: - # do nothing if this is a ssh session if [ $SSH_CLIENT != ] ; then exit fi rc_starts_pd - It's important to ignore ssh sessions since, if you're like me, and you want to login to your (wearable) computer via SSH to check something, you don't want to launch a new instance of pd. On Jan 21, 2014, at 1:37 PM, pd-list-requ...@iem.at wrote: From: Jack j...@rybn.org Subject: Re: [PD] ALSA MIDI problem Date: January 21, 2014 at 8:20:27 AM EST To: pd-list@iem.at pd-list@iem.at Ok, I find a solution : $ aconnect -i client 0: 'System' [type=noyau] 0 'Timer ' 1 'Announce' client 14: 'Midi Through' [type=noyau] 0 'Midi Through Port-0' client 20: 'USB Uno MIDI Interface' [type=noyau] 0 'USB Uno MIDI Interface MIDI 1' client 128: 'Pure Data' [type=utilisateur] 1 'Pure Data Midi-Out 1' $ aconnect -o client 14: 'Midi Through' [type=noyau] 0 'Midi Through Port-0' client 20: 'USB Uno MIDI Interface' [type=noyau] 0 'USB Uno MIDI Interface MIDI 1' client 128: 'Pure Data' [type=utilisateur] 0 'Pure Data Midi-In 1' then : $ aconnect 128:1 20:0 Now, how can i keep this configuration each time i reboot my laptop ? ++ Jack Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ALSA MIDI problem
Oh woops. You want to call that in ~/.bash_login, not ~/bash_profile. On Jan 21, 2014, at 3:17 PM, Dan Wilcox danomat...@gmail.com wrote: Here's a portion of a startup script I use: echo rc_starts_pd: strating pd pd -rt -nogui -alsa -audiodev 4 -audiobuf 10 -alsamidi $PATCH # renice pd for much higher priority renice -10 $(pidof pd) # wait for pd to initialize KA=$(aconnect -i -o | grep Pure Data) while [ $KA = ] do sleep 1 echo rc_starts_pd: pd alsamidi not ready KA=$(aconnect -i -o | grep Pure Data) done echo rc_starts_pd: pd alsmidi is ready # connect the UA-25 midi to Pure Data echo rc_starts_pd: alsa midi connect 'UA-25' - 'Pure Data' aconnect 'UA-25' 'Pure Data' aconnect 'Pure Data':1 'UA-25':0 # connect the VIEWCON dongle midi to Pure Data echo rc_starts_pd: alsa midi connect 'VIEWCON..' - 'Pure Data' aconnect 'VIEWCON..' 'Pure Data' aconnect 'Pure Data':1 'VIEWCON..':0 -- It starts Pd, then waits until the PD midi device is registered with ALSA before trying to connect two Midi devices: UA-25 VIEWCON.. You could run the script from you ~/.bash_profile which would call it as soon as the user is logged in. I use this: - # do nothing if this is a ssh session if [ $SSH_CLIENT != ] ; then exit fi rc_starts_pd - It's important to ignore ssh sessions since, if you're like me, and you want to login to your (wearable) computer via SSH to check something, you don't want to launch a new instance of pd. On Jan 21, 2014, at 1:37 PM, pd-list-requ...@iem.at wrote: From: Jack j...@rybn.org Subject: Re: [PD] ALSA MIDI problem Date: January 21, 2014 at 8:20:27 AM EST To: pd-list@iem.at pd-list@iem.at Ok, I find a solution : $ aconnect -i client 0: 'System' [type=noyau] 0 'Timer ' 1 'Announce' client 14: 'Midi Through' [type=noyau] 0 'Midi Through Port-0' client 20: 'USB Uno MIDI Interface' [type=noyau] 0 'USB Uno MIDI Interface MIDI 1' client 128: 'Pure Data' [type=utilisateur] 1 'Pure Data Midi-Out 1' $ aconnect -o client 14: 'Midi Through' [type=noyau] 0 'Midi Through Port-0' client 20: 'USB Uno MIDI Interface' [type=noyau] 0 'USB Uno MIDI Interface MIDI 1' client 128: 'Pure Data' [type=utilisateur] 0 'Pure Data Midi-In 1' then : $ aconnect 128:1 20:0 Now, how can i keep this configuration each time i reboot my laptop ? ++ Jack Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] signal math explanation
Chances are Jonathan has already cleaned that up :D (Thanks for all the help file updates J!) On Jan 19, 2014, at 6:00 AM, pd-list-requ...@iem.at wrote: From: Pall Thayer pallt...@gmail.com Subject: Re: [PD] signal math explanation Date: January 18, 2014 at 2:48:04 PM EST To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at, IOhannes m zmölnig zmoel...@iem.at I don't know. I recall seeing it somewhere years ago. On Sat, Jan 18, 2014 at 2:32 PM, Jonathan Wilkes jancs...@yahoo.com wrote: Hi Pall, Which help patches? I haven't seen a single help patch that substitutes strings of [+~] to double the incoming signal where a simple multiplication would do. I have seen cascades of [+~] for additive synthesis, but that's not the same. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-list Digest, Vol 106, Issue 48
For information: libtool is a prerequisite for building lots of autotools projects, so it may not be surprising the info isn't in in INSTALL.txt. Of course that *assumes* everyone knows this, which is never the case :D On Jan 18, 2014, at 11:07 AM, pd-list-requ...@iem.at wrote: From: Max abonneme...@revolwear.com Subject: Re: [PD] compiling Pd 0.45 on Linux Date: January 18, 2014 at 10:43:09 AM EST To: Jack j...@rybn.org, pd-list@iem.at Hi Jack! allright, libtool was missing indeed, it works now. That info is missing in INSTALL.txt Thanks. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] rc-unitd, was pd gui: partial interface freeze
This may be related: Years ago, I wrote a separate app daemon which grabs hid joystick events and streams them over OSC into pd. This approach works very well, even on low resource machines or when you want to separate audio control machines. For my upcoming show, I'm using an RPi + Bluetooth to stream physically hacked PS3 controller-based input devices into PdParty running on an iPad. See https://github.com/danomatika/rc-unitd I use it on Linux OSX. Probably works on Win but haven't tried it. On Jan 18, 2014, at 12:36 PM, pd-list-requ...@iem.at wrote: From: Py Fave pyf...@gmail.com Subject: Re: [PD] pd gui: partial interface freeze Date: January 18, 2014 at 12:36:08 PM EST To: u...@xdv.org Cc: PDlist pd-list@iem.at usb/hid did this if i remember correctly. i solved it by usind a different build or another object: [joystick] but it was on windows i guess this is a known bug because [hid] is so useful perhaps someone has a better knowing of this .? or a workaround . Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Chocolate et Coffee
Well, backwards compatibility can have reasonable limitations and perhaps this is one. On Jan 13, 2014, at 6:18 AM, i go bananas hard@gmail.com wrote: i very much doubt miller will include stuff in vanilla that's not backwards compatible. seeing as how these objects don't even work with my (relatively) recent 0.42.5 version, i can't see how they'd pass. On Mon, Jan 13, 2014 at 6:00 PM, Pierre Guillot guillotpier...@gmail.com wrote: Hi, I may have been sensitive, I needed 2 days break, sorry. If we focus on the important facts, I received really constructive feedbacks and I've been able to improve the library for the next release. Joao suggestions : - The properties window will have a fixed size. - We can set (in the code) if we want a color picker, checkbox, menu or textfield for each property. - The id name becomes receive symbol and there's also an send symbol. IOhannes suggestions : - The c/tcl library is now named CicmWrapper (The repository name will change with the next release) - If it seems better to change the libray name, Chocolate can become CicmGUI ? About the right click during runmode, It's possible to change it but I don't really like it. Do you think that's really important ? To include in Pd-ext, it's possible to only include Chocolate, I just have to replace all the c.prepend and c.loadmess with prepend and init. I received mails and some users like c.patcherargs and the double click of the coffee objects but they can download and add the library manually. To include in Vanilla, you're right, the best is to ask to Miller. If we want to replace the vanilla GUIs, two suggestions for the moment : - We keep the the vanilla GUIs and we just replace the shortcut, we won't have any problem to load previous patchs and users will use the new GUI for their new patchs (Secure and easy to do, we can also have an option to replace or not the vanilla shortcuts). - We overwrite the vanilla classes then every objects will replaced but the users will lose the properties (size, font, color, etc...). Another idea is to add a menu option or to offer 2 libraries with one that overwrite classes. Cheers 2014/1/10 Jonathan Wilkes jancs...@yahoo.com On 01/10/2014 12:50 PM, Dan Wilcox wrote: I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ... I must have misunderstood-- the way you wrote that made it sound like there is a process by which the community gets things included into Pd Vanilla. If such a process existed wouldn't one of the dupes IOhannes cites already be included in Pd Vanilla after over a decade now? Instead, I think Pierre has taken the only sensible approach to making a library that works with both Pd-Vanilla and Pd-extended. You simply code up the stuff that's been missing forever-- some of it probably in less time than it takes to respond to questions about dupes. Then you ship the library, and it just works without users having to find other libraries. -Jonathan On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancs...@yahoo.com wrote: What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
As Hans has proposed for years, IMO this is really the only way to perhaps solve the PD gui development doesn't move fast enough problem in the long term. In this case, Miller would have the core (in libpd) the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way. On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancs...@yahoo.com wrote: #2 is hard. Where would you start and how would you proceed? I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL. In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc. Conceptually, I know the tcl/tk-ism for the canvas, object positions, etc are fully baked into how everything works and I don't see a reason to try and change that. Again, perhaps the easiest method would be formalize those conventions via function wrappers which work 1-1 within the existing tcl/tk gui but perhaps require some adaptation for other gui frameworks. In other words, trying to find the least intrusive way to do this as I believe Martin has already done with the existing work in libpd. I truly respect Miller's work with Pure Data and understand the need to move slowly to maintain the highest possible backwards compatibility with all existing computer music pieces made in Pure Data. So far libpd has proven we can abstract some of the Pd core functionality without affecting Pd-vanilla, so I think it's possible to look for the next steps. The recent point of not being able to run GEM an audio heavy patch on the same pd instance is really not a fault of the core but of the gui implementation. I have used libpd within OpenFrameworks for a number of computer vision + sound apps so I know it's definitely possible. Again, I'm only theorizing. I'm pretty familiar with how the iem guis are coded after emulating them in ObjC for PdParty, but I haven't delved into the nit and grit of the core yet. At least I can say now that the paradigms make more sense. As reference, last summer I updated some pretty hairy C code in RTCmix so that it would build as a library on Windows in MinGW: https://github.com/CreativeInquiry/RTcmix I have access to a triple boot machine to test code on Win/Mac/Linux which I regular use for OpenFrameworks work. So if I seriously gave this a shot, it wouldn't be a look, it works on my machine, but I haven't tried it on OS A, B, Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
Woops, forgot the reply-all. On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 01/13/2014 09:32 AM, Dan Wilcox wrote: As Hans has proposed for years, IMO this is really the only way to perhaps solve the PD gui development doesn't move fast enough problem in the long term. In this case, Miller would have the core (in libpd) the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way. Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core. I wasn't referring to anything in particular, only in general. On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancs...@yahoo.com wrote: #2 is hard. Where would you start and how would you proceed? I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL. I think by DSP core you're referring to: * DSP graph stuff * message dispatching system * various widgetbehaviors and data structures parentwidgetbehaviors * all the gui logic in g_editor.c * gui queuing stuff, array selection/manipulation logic, mouse motion callbacks, and probably other things I'm forgetting Is this correct? Yes, minus the widgets and gui queuing stuff, etc. I'm talking about finding a way to separate the strictly gui stuff from the DSP graph. I recognize that some of that is required, so I'm trying to think pragmatically. Obviously you're a better judge of that as you have more experience with the code in the area. In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc. I'm not clear on what libpd actually includes. For example, does all the logic from g_editor remain intact? Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 01/13/2014 03:11 PM, Dan Wilcox wrote: Woops, forgot the reply-all. On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote: Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core. I wasn't referring to anything in particular, only in general. Then what do you think of $@ or [initbang]? Are there good reasons for them not being in the core? What about infinite undo? Or symbols that don't cause memory leaks? Those would definitely be nice to have. I don't know what $@ refers to, is it the object arguments as a list? On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it. Hm... I didn't realize that. That being the case, you could certainly go ahead and figure out some interim way of sending and parsing tcl messages using whichever gui toolkit you prefer. However, it's worth understanding a bit about why Pd-l2ork has diverged somewhat from the code you'd be wrapping (in no particular order, and definitely not exhaustive): [snip] That's all good info to know, thanks. I'd imagine libpd would't need to handle *move functions though. Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right? On Jan 13, 2014, at 5:14 PM, Dan Wilcox danomat...@gmail.com wrote: Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be pdtk_canvas_sendkey name state key iso shift
It's not possible to overload the function? aka 1 that takes 5 args and another that takes 7? From what I can tell, the usual style within the pd core has been to add new args to the end so that backwards compatibility isn't sacrificed. Then again, I don't know the details in this case ... With libpd, so far, we've avoid trying to make any large, incompatible changes to the core. Mainly, at least IMO, because we do not want to end up diverging to the point to where we'll never be able to get said changes upstream. At this point, I'd love to sit down with a bunch of you and work out a proposed roadmap to separating gui pd core so that libpd could become the standard core between flavors. I haven't delved into the core enough to know if that is a foolish idea, but it really seems like a great idea to standardize some of the functionality ... On Jan 12, 2014, at 5:55 PM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be pdtk_canvas_sendkey name state key iso shift Date: January 12, 2014 at 5:54:49 PM EST To: pd-list@iem.at On 01/12/2014 10:55 AM, Ivica Ico Bukvic wrote: Hi, This is because pd-l2ork has recently introduced a way of filtering autorepeat keys so that [key], [keyup], and [keyname] objects only report real key presses (as they should) while other forms of key input (e.g. writing into an object box) still obey the autorepeat. This had to be done in a way that breaks pdtk_canvas_send_key by adding an additional variable and hence library like gridflow that hasn't kept up with pd-l2ork's updates is no longer functioning as it should. Adapting this to pd-l2ork should not take much of an effort--it is just a question of time and who will do it. But notice the error tells the user that the proc expects five args, and not seven args like your revision of pdtk_canvas_sendkey. This is because matju told Gridflow to steal the pdtk_canvas_sendkey proc and renamed it to pdtk_canvas_sendqui (which is pretty funny in itself), and then it sends tcl a brand new pdtk_canvas_sendkey proc with 5 args and code that presumably has to do with unicode support. I say that because you can find it in the Gridflow source file named unicorn.cxx (which is also funny in itself). So if you can figure out what it's doing, you can try to merging it into Pd-l2ork or at least make it compatible with it. But there are probably several other places where matju drilled into Pd's walls from the outside, and they probably conflict with Pd-l2ork's renovations. (Probably the widgetbehavior struct and comment struct conflict.) -Jonathan Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Chocolate et Coffee
I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ... On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancs...@yahoo.com wrote: What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Chocolate et Coffee
Poor IOhannes, everyone thinks you're yelling at them :D Pierre, nobody is mad at you. It's just a misunderstanding. Everyone is really impressed with your work and we've been thinking of ways to integrate it within a Pd distribution (vanilla, extended, etc). Part of doing that is to find and eliminate redundancy where it makes sense and the usage of the work dupes only refers to that. If anything, perhaps we can analyze the reasons why you needed to extend a few of the existing objects and see if we can't add the functionality to them ([canvas] etc). Also, nobody has been sarcastic with using the term fancy objects. At this point, we *all* want nicer objects and yours are pretty awesome. fancy only refers to a comparison with the iemguis which are admittedly utilitarian (but have their own charm). On Jan 3, 2014, at 10:35 AM, pd-list-requ...@iem.at wrote: From: Pierre Guillot guillotpier...@gmail.com Subject: Re: [PD] [PD-announce] Chocolate et Coffee Date: January 3, 2014 at 8:26:17 AM EST To: IOhannes m zmölnig zmoel...@iem.at Cc: PD List pd-list@iem.at I offers a library for Pd and not only on Pd-extented. It would have been annoying to put the iem's prepend in the distribution (I don't think that Thomas Musil would have be happy) and it would have strange to ask the user to download one external here and another here. I've made c.prepend and c.loadmess because I wanted to offer something with clean and simple and note that canvasarg don't have the same behavior, canvasinfo isn't my pd-extented distribution, listpak doesn't work. I know that most of the users use these obects and I don't want to replace them that why I put .c before everything. So I can't figure out what is your problem, why do you say fancy objects, for the dupes ? If I said something wrong, I'm sorry. Let's try to be cool please. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] headroom in Pd
I know. My response was tongue in cheek as I knew this ahead of time but, so far, it hasn't been a problem with the music that I make ... On Jan 1, 2014, at 2:08 AM, pd-list-requ...@iem.at wrote: From: Simon Wise simonzw...@gmail.com Subject: Re: [PD] headroom in Pd Date: January 1, 2014 at 12:50:55 AM GMT+1 To: pd-list@iem.at On 31/12/13 08:30, Dan Wilcox wrote: Ouch. I guess alot of us don't have serious projects :D (Out of curiosity, does Max do soft clipping also?) the point was that OSX was messing with the sound between the software, presumably any software, and the audio output ... which may perhaps be called a feature while listening to songs in iTunes but is a big worry if you are trying to use the system seriously as a musician. It is a problem that comes up on this list from time to time, I don't recall any reply saying it could be bypassed or turned off. Simon Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Mess with Pd installation on Linux
On Dec 31, 2013, at 10:12 AM, Alexandros Drymonitis adr...@gmail.com wrote: On Mon, Dec 30, 2013 at 11:24 PM, Dan Wilcox danomat...@gmail.com wrote: Did you see this in the PD FAQ?: http://puredata.info/docs/faq/how-can-i-run-pd-with-realtime-priority-in-gnu-linux This confuses me a bit as it slightly differs from this http://jackaudio.org/linux_rt_config Yeah, but both pages are doing the exactly same thing ... In the Pd FAQ it says that if /etc/security/limits.d/audio.conf exists you don't need to do anything, where in the other link it says that you need to create /etc/security/limits.d/99-realtime.conf and there you should write the following: @realtime - rtprio 99 @realtime - memlock unlimited In the Pd FAQ, it says that if /etc/security/limits.d/audio.conf doesn't exist, you should add the two lines above to /etc/security/limits.conf but instead of @realtime you should write @audio Anyway, I've followd the jack link and supposedly I've added realtime scheduling. Should I run Pd with '-rt' ? This is just a style difference. The system will read from whichever files are in that folder. Putting the realtime lines into limits.conf or 99-realtime.conf makes no difference. 99.realtime.conf is a good idea in that it won't be replaced if the main limits.conf if altered on a system update. Also, the groupname you use is arbitrary, audio or realtime will work either way (but don't mix them). There is lots of info out there but I think, perhaps, you're confusing yourself and/or somehow missing, conceptually, the point of all of this. I don't write that in a bad way as I went through the same thing when I switched to Linux. It's easy to start following articles and forums at first the tweak this and that ... but in the long run you just have to learn the *why* of what you're doing and not just the *how*. Let's look at Pd + Jack. From my experience with Linux, (some of this may have been updated by now, but I don't think so), there are 2 low level audio APIS: OSS ALSA. OSS was the original, but ALSA has the predominant interface for apps to connect to audio hardware. From a user point of view, it's main problem is that it does not do mixing of audio streams aka you can't open multiple audio programs and have them play sound together using only ALSA. You need something else to help out, enter ESD (Enlightenment Sound Daemon), Jack, Pulseaudio which are simply software daemons running on the background that take audio streams from apps and mix them before sending the result to ALSA. ESD Pulseaudio are focused on the day-to-day desktop environment while Jack is mainly for professional audio work aka *fast, low latency audio*. This is an important difference. ESD Pusleaudio are mainly just providing audio for your youtube video or music player, so you won't mind or notice that they buffer and run at a pretty long latency (say 1024 samples per buffer +, etc). A long latency means the cpu doesn't have to process that stream as quickly and the sound server (ESD/Pulse) doesn't need to run at a very high priority. Jack, on the other hand, is designed for *realtime* performance aka getting everything to process as fast as possible so you have the lowest latency possible, say a length of 128 or 64 samples per buffer. In order to allow Jackd to run as fast as possible, we have to tell the system that it should have the permissions to receive more resources and run faster than other apps, hence needing to unlock the realtime limits. Ok, if we can now run Jackd in realtime mode, we should try and run our audio apps as fast as possible as well, if they support it. Why? Because, they may not be able to deliver the samples as quickly as Jack wants, resulting in audio dropouts (clicks). For Pd, there is the -rt start flags which starts Pd with realtime priority. Again, needing this really depends on your system, but it's a good idea to run Jack Pd with -rt, in my experience. Years ago, I happily ran realtime audio with Jack and multitrackrecording from Pd to Ardour on a *single core* Pentium M with around 1.6 GHZ which was a beast compared to the early 2000s, but is a mouse by today's standards. I guess I'll have to read the manual. Aha. Well, welcome to Linux ... :D In the future, though, it would be helpful if you did that before trying to get the pd-list to help you step by step through the process. They coudl be doing other things, like improving pd :D On the other hand, perhaps there is not the *right* info out there now and perhaps we need to have a How To Jack + Pd added to the Pd FAQ? Also, I *really* hope you're using a GUI for Jackd like QJackCtl: https://en.wikipedia.org/wiki/Qjackctl On Dec 30, 2013, at 3:31 PM, pd-list-requ...@iem.at wrote: From: Alexandros Drymonitis adr...@gmail.com Subject: Re: [PD] Mess with Pd installation on Linux Date: December 30, 2013 at 3:30:47 PM GMT+1 To: yvan volochine yvan
Re: [PD] [PD-announce] Chocolate et Coffee
Holy shit. Can these eventually replace the vanilla objects??!! On Dec 31, 2013, at 12:00 PM, pd-list-requ...@iem.at wrote: From: Pierre Guillot guillotpier...@gmail.com Subject: [PD] [PD-announce] Chocolate et Coffee Date: December 31, 2013 at 11:46:54 AM GMT+1 To: pd-annou...@iem.at Reply-To: pd-list@iem.at Hi everybody, I'm pleased to share my new libraries : Chocolate Coffee. For the HOA project, I've developed a C library to facilitate the creation of graphical objects for Pure Data and to allow further interactions with the users. My experimentation objects were a VU-meter and a number box for signal. They appeared useful and ergonomic for me so I undertook to extend the list. Quickly : Chocolate is a set of GUIs sometimes already available in PD Vanilla, PD extented or Max with new features (like presets edition) that I hope, you'll enjoy. And it will be a part of a more complex project for the writting of events. Coffee is a set of objects to facilitate the patch creation. The libraries are available for Mac, Windows and Linux and they have been tested on PD extented 0.43 and PD 0.45. Download : https://github.com/pierreguillot/PdEnhanced/releases Feedback are wellcome (for developement questions, the best is to use the git project). I hope you'll find this libraries useful. Bonne année Ps : The C library seems to work very well under Linux. So, if we don't have problems with the other dependencies, we'll be able to offer a Linux version of the Hoa Library very quickly. ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Chocolate et Coffee
Some of us can help with that :D On Dec 31, 2013, at 2:12 PM, Pierre Guillot guillotpier...@gmail.com wrote: - I didn't schedule to add the library to pd extented because it's already a lot of work and I'm ashamed but I'm not very familiar with the Makefile... And the default one seems complicated to use when you have more than one file per object. But if someone want to help me, he's welcome ! Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Chocolate et Coffee
Hah I know but I imagine there could be a way to fallback to the original implementations. My reaction was based mostly on how nice they look. That seems to be important to some people and I've had to push them in workshops to not dismiss Pd purely because it doesn't look like Max (go figure ...). On Dec 31, 2013, at 2:31 PM, Pierre Guillot guillotpier...@gmail.com wrote: The Vanilla objects have the advantage to work fine on computers with very few memory and old graphic cards or on the hardwares like the raspberry pi. My objects don't need the best computer but I think if I use a very old computer I'll have some latency. But thank you ! And for Pd-extented, I'm going to explain the architecture of the code on the git (that's not difficult) if this can help you to help me. Cheers 2013/12/31 Dan Wilcox danomat...@gmail.com Some of us can help with that :D On Dec 31, 2013, at 2:12 PM, Pierre Guillot guillotpier...@gmail.com wrote: - I didn't schedule to add the library to pd extented because it's already a lot of work and I'm ashamed but I'm not very familiar with the Makefile... And the default one seems complicated to use when you have more than one file per object. But if someone want to help me, he's welcome ! Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] streamStretch~
This is very nice, thanks! I will be using this on Mars soon ... On Dec 30, 2013, at 12:00 PM, pd-list-requ...@iem.at wrote: From: William Brent william.br...@gmail.com Subject: [PD] [PD-announce] streamStretch~ Date: December 29, 2013 at 11:59:10 PM GMT+1 To: PD-List pd-list@iem.at Here's another cleanup of something I made for a recent performance. Like martha~, it's a Pd-vanilla abstraction, so ready to use on any platform. The idea is to make multiple time-stretched/transposed copies of the live input that trail behind as a kind of detuned halo (or with the right settings, a dense and disgusting mush). A simplified version of the I07.phase.vocoder.pd doc patch is at its core, so this is mainly about taking care of all the buffering, polyphony, and auto-spawning of streams. http://williambrent.conflations.com/pages/research.html#streamStretch Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Mess with Pd installation on Linux
Did you see this in the PD FAQ?: http://puredata.info/docs/faq/how-can-i-run-pd-with-realtime-priority-in-gnu-linux On Dec 30, 2013, at 3:31 PM, pd-list-requ...@iem.at wrote: From: Alexandros Drymonitis adr...@gmail.com Subject: Re: [PD] Mess with Pd installation on Linux Date: December 30, 2013 at 3:30:47 PM GMT+1 To: yvan volochine yvan...@gmail.com Cc: pd-list pd-list@iem.at On Mon, Dec 30, 2013 at 4:12 PM, yvan volochine yvan...@gmail.com wrote: On 30/12/13 14:29, Alexandros Drymonitis wrote: I've realized that I need to open pd with sudo in order to have it work with jack (I also have to open jack with sudo in order to use the firewire). as IOhannes said, you _should not_ do that.. (if you do it could mean that you did not add yourself to the `audio` group, as suggested by my previous link) Ok, I was opening jack with sudo before you posted the link, now I can indeed open it without sudo and it will see the firewire, no prob. So I'm also opening pd without sudo, but I get the same behaviour. Sometimes it works, sometimes it doesn't. how do you start jack? can you post here the full command? jack -d firewire (I use if I want to open pd from the same terminal window, but don't really know how to turn off jack afterwards..) y -- http://yvanvolochine.com http://soundcloud.com/yvanvolochine http://soundcloud.com/elgusanorojo http://github.com/gusano http://vimeo.com/yv ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] headroom in Pd
Ouch. I guess alot of us don't have serious projects :D (Out of curiosity, does Max do soft clipping also?) On Dec 29, 2013, at 10:20 PM, pd-list-requ...@iem.at wrote: From: Miller Puckette m...@ucsd.edu Subject: Re: [PD] headroom in Pd Date: December 29, 2013 at 6:42:00 PM GMT+1 To: Martin Peach martin.pe...@sympatico.ca Cc: IOhannes m zmölnig zmoel...@iem.at, pd-list@iem.at This is frightening - if I were a musician reading this I'd be frightened to ever use Appe software in a serious project. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM causes soung glitches
Yeah that was a bit harsh, IOhannes, but I can also understand when help me emails get to be too much after you've spent lots of time and energy providing great tools for free (where's the love?). Luiz, you could probably have worded things a bit differently (less accusatory). We recognize a need for something, let's suggest solutions or some sort of plan rather than reiterating the problem. On Dec 28, 2013, at 10:34 PM, pd-list-requ...@iem.at wrote: I cant help solving the problem directly. My programming skills are not so good. But if you want I can do other tasks, try to raise money, I dont know. How do I start? You answered your own question, Luiz :D IMHO sponsoring/organizing a Pd developer meetup would go a long way towards improving Pd as a whole. Getting devs together face-to-face can really get things going and, if you're organization is bringing them there, you can obviously set the tone / focus (aka improving GEM in Pd, etc). Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-list Digest, Vol 105, Issue 30
I would checkout rjlib and the s_osc~ which has bandlimited oscillators ... no need to reinvent the wheel. rjlib is vanilla so it will work fine with libpd. Also, if you want the analog sound, the creb/moog~ external is kosher for the App store. I have it in PdParty. On Dec 20, 2013, at 5:27 PM, pd-list-requ...@iem.at wrote: From: Tony Hillerson tony.hiller...@gmail.com Subject: [PD] A naive approach to bandlimiting Date: December 20, 2013 at 5:26:59 PM EST To: pd-list@iem.at Hey guys, I’m building an iOS and Android app with an “analog synth component. I’m pretty inexperienced with the DSP world, and my math and theoretical understanding of things is pretty rudimentary. Because I’m building a mobile app, I feel like I need to build each of the components of the synth myself instead, to avoid issues such as those with the App store and the GPL. I’ve built the oscillator array, now and I have something I’d like to run by this group. I understand enough of the problem of band limiting to know the ill effect to the sound, and that there are a few different approaches people take to solve it. I don’t quite understand enough of how these solutions work, though to know if there’s “a solution” that I should use. After thinking about the problem I tried the approach I lay out below, and I’d like feedback. Is it a naive way of solving the problem? Does it introduce other problems? Is it really inefficient? Here goes: I have nine tables, which I populate with a collection of geometric wave data using sinesum. Each table has fewer harmonics than the last. Then I use an array of [moses] objects to check the incoming MIDI note and call a set tablename on a [tabosc4~] before each note is played. I choose a table with fewer harmonics as the note gets higher, and the boundary is generally the B note in the next octave. So, to produce a sawtooth wave, I have a wavetable with 714 partials for MIDI notes 24 and below, 357 partials for MIDI 36 down to 25, 178 partials from MIDI 48 to 37, and so on until between 128 and 109 I use a table with a single sine wave. My naive understanding is that this approach is fairly efficient with CPU, but not efficient with memory. I believe it will let me have nice fat low-end notes, but should never have any aliasing as notes go higher in the register. Anyhow, I hope that was clear enough. What of this approach? -- Tony Hillerson Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] A naive approach to bandlimiting
I would checkout rjlib and the s_osc~ which has bandlimited oscillators ... no need to reinvent the wheel. rjlib is vanilla so it will work fine with libpd. Also, if you want the analog sound, the creb/moog~ external is kosher for the App store. I have it in PdParty. On Dec 20, 2013, at 5:27 PM, pd-list-requ...@iem.at wrote: From: Tony Hillerson tony.hiller...@gmail.com Subject: [PD] A naive approach to bandlimiting Date: December 20, 2013 at 5:26:59 PM EST To: pd-list@iem.at Hey guys, I’m building an iOS and Android app with an “analog synth component. I’m pretty inexperienced with the DSP world, and my math and theoretical understanding of things is pretty rudimentary. Because I’m building a mobile app, I feel like I need to build each of the components of the synth myself instead, to avoid issues such as those with the App store and the GPL. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] video output from PD
If he only needs to at videos and the sync is rather loose, then yeah scripting omxplayer would work. From what he wrote earlier, it's sounds like he wants per frame start/stop control which he can't get with omxpmayer alone, at least from what I'm aware. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Dec 2, 2013, at 3:21 AM, enrike alte...@gmail.com wrote: Another option could be to create a Python script that listens to OSC and triggers the omxplayer process. That would be easier to code but I guess you would have less control that using OMX player class in OpenFrameworks, I havent tested raspberry so much to know which way would be better ig., 2013.eko aberen 01a 23:05(e)an, Dan Wilcox(e)k idatzi zuen: I would pick up an old rackmount ethernet switch and use static ips. I imagine wireless would work, but you're asking for trouble if you don't get an industrial wifi router. As for software, I'd echo using OpenFrameworks. The current version (0.8.0) now supports the RPI and there is an OMX video player class which can run with hardware acceleration. It would be simple to code a single, custom video player app that listens over OSC to start, stop, set frame position, etc. Said app would read from an xml file to know which video to load, so you don't have to hardcode anything. You will not be able to do this with PD alone on the RPI since, as mentioned before, GEM currently has no OPENGL ES support on the RPI. Email me if you guys need help/have a budget, although my timeframe is a little cramped right now. On Dec 1, 2013, at 6:00 AM, pd-list-requ...@iem.at mailto:pd-list-requ...@iem.at wrote: *From:*peiman khosravi peimankhosr...@gmail.com mailto:peimankhosr...@gmail.com *Subject:**Re: [PD] video output from PD* *Date:*December 1, 2013 at 5:25:53 AM EST *To:*Charles Goyard c...@fsck.fr mailto:c...@fsck.fr *Cc:*PD List pd-list@iem.at mailto:pd-list@iem.at Hello, Thanks for the answers. I've been looking around and it doesn't look like that omxplayer accepts OSC messages. Does it? Also how are the Pis connected to a network? Through ethernet? In this case I would need a router with 20 outputs right? To explain a bit more about the project. It's a live band, with precomposed videos playing back (with stop/start variations) across a bunch of analogue TVs placed on stage, all in sync with the sound. We don't know yet to what extent the result will be predetermined or generative but as long as there is the possibility of controlling the overall visual rhythm... The live sound from each instrument is also being transformed through lots of DSP in pd. So it's a complex setup and it needs to be reliable as we'll be taking the show on the road at some point. Many Thanks Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.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] video output from PD
Ah, another I option I almost forgot about is pikix, a cool little vj app for the rpi. I'm not sure if it has per frame or osc control but, in the spirit of open source, it might be beneficial to add that and contribute it back versus rolling an expendable OF app. On Dec 2, 2013, at 10:07 AM, peiman khosravi peimankhosr...@gmail.com wrote: Thanks very much for all the suggestions. I know python, so that would be the easies option for me but as Dan mentioned I think we will need per frame control over the playback. Best, Peiman www.peimankhosravi.co.uk || RSS Feed || Concert News On 2 December 2013 14:46, Dan Wilcox danomat...@gmail.com wrote: If he only needs to at videos and the sync is rather loose, then yeah scripting omxplayer would work. From what he wrote earlier, it's sounds like he wants per frame start/stop control which he can't get with omxpmayer alone, at least from what I'm aware. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Dec 2, 2013, at 3:21 AM, enrike alte...@gmail.com wrote: Another option could be to create a Python script that listens to OSC and triggers the omxplayer process. That would be easier to code but I guess you would have less control that using OMX player class in OpenFrameworks, I havent tested raspberry so much to know which way would be better ig., 2013.eko aberen 01a 23:05(e)an, Dan Wilcox(e)k idatzi zuen: I would pick up an old rackmount ethernet switch and use static ips. I imagine wireless would work, but you're asking for trouble if you don't get an industrial wifi router. As for software, I'd echo using OpenFrameworks. The current version (0.8.0) now supports the RPI and there is an OMX video player class which can run with hardware acceleration. It would be simple to code a single, custom video player app that listens over OSC to start, stop, set frame position, etc. Said app would read from an xml file to know which video to load, so you don't have to hardcode anything. You will not be able to do this with PD alone on the RPI since, as mentioned before, GEM currently has no OPENGL ES support on the RPI. Email me if you guys need help/have a budget, although my timeframe is a little cramped right now. On Dec 1, 2013, at 6:00 AM, pd-list-requ...@iem.at mailto:pd-list-requ...@iem.at wrote: *From:*peiman khosravi peimankhosr...@gmail.com mailto:peimankhosr...@gmail.com *Subject:**Re: [PD] video output from PD* *Date:*December 1, 2013 at 5:25:53 AM EST *To:*Charles Goyard c...@fsck.fr mailto:c...@fsck.fr *Cc:*PD List pd-list@iem.at mailto:pd-list@iem.at Hello, Thanks for the answers. I've been looking around and it doesn't look like that omxplayer accepts OSC messages. Does it? Also how are the Pis connected to a network? Through ethernet? In this case I would need a router with 20 outputs right? To explain a bit more about the project. It's a live band, with precomposed videos playing back (with stop/start variations) across a bunch of analogue TVs placed on stage, all in sync with the sound. We don't know yet to what extent the result will be predetermined or generative but as long as there is the possibility of controlling the overall visual rhythm... The live sound from each instrument is also being transformed through lots of DSP in pd. So it's a complex setup and it needs to be reliable as we'll be taking the show on the road at some point. Many Thanks Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.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 Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] video output from PD
Worth a try but I see two (potential) problems: * is it hardware accelerated? it says it uses ffmpeg in the backend and that, to me, sounds like it's not using the OMX interface for hardware accelerated video on the pi * it requires jack, this means you're increasing overhead by running the jack server On Dec 2, 2013, at 10:28 AM, peiman khosravi peimankhosr...@gmail.com wrote: What about xjadeo, which I've used before. It doesn't accept osc but it does sync with ardour, and ardour accepts OSC. So maybe that would work? As long as Jack and Ardour and xjadeo can run on the ras Pi? Or else, if PD could sync up with Jack transport then no need for ardour either. Thanks Peiman www.peimankhosravi.co.uk || RSS Feed || Concert News On 2 December 2013 15:14, Dan Wilcox danomat...@gmail.com wrote: Ah, another I option I almost forgot about is pikix, a cool little vj app for the rpi. I'm not sure if it has per frame or osc control but, in the spirit of open source, it might be beneficial to add that and contribute it back versus rolling an expendable OF app. On Dec 2, 2013, at 10:07 AM, peiman khosravi peimankhosr...@gmail.com wrote: Thanks very much for all the suggestions. I know python, so that would be the easies option for me but as Dan mentioned I think we will need per frame control over the playback. Best, Peiman www.peimankhosravi.co.uk || RSS Feed || Concert News On 2 December 2013 14:46, Dan Wilcox danomat...@gmail.com wrote: If he only needs to at videos and the sync is rather loose, then yeah scripting omxplayer would work. From what he wrote earlier, it's sounds like he wants per frame start/stop control which he can't get with omxpmayer alone, at least from what I'm aware. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Dec 2, 2013, at 3:21 AM, enrike alte...@gmail.com wrote: Another option could be to create a Python script that listens to OSC and triggers the omxplayer process. That would be easier to code but I guess you would have less control that using OMX player class in OpenFrameworks, I havent tested raspberry so much to know which way would be better ig., 2013.eko aberen 01a 23:05(e)an, Dan Wilcox(e)k idatzi zuen: I would pick up an old rackmount ethernet switch and use static ips. I imagine wireless would work, but you're asking for trouble if you don't get an industrial wifi router. As for software, I'd echo using OpenFrameworks. The current version (0.8.0) now supports the RPI and there is an OMX video player class which can run with hardware acceleration. It would be simple to code a single, custom video player app that listens over OSC to start, stop, set frame position, etc. Said app would read from an xml file to know which video to load, so you don't have to hardcode anything. You will not be able to do this with PD alone on the RPI since, as mentioned before, GEM currently has no OPENGL ES support on the RPI. Email me if you guys need help/have a budget, although my timeframe is a little cramped right now. On Dec 1, 2013, at 6:00 AM, pd-list-requ...@iem.at mailto:pd-list-requ...@iem.at wrote: *From:*peiman khosravi peimankhosr...@gmail.com mailto:peimankhosr...@gmail.com *Subject:**Re: [PD] video output from PD* *Date:*December 1, 2013 at 5:25:53 AM EST *To:*Charles Goyard c...@fsck.fr mailto:c...@fsck.fr *Cc:*PD List pd-list@iem.at mailto:pd-list@iem.at Hello, Thanks for the answers. I've been looking around and it doesn't look like that omxplayer accepts OSC messages. Does it? Also how are the Pis connected to a network? Through ethernet? In this case I would need a router with 20 outputs right? To explain a bit more about the project. It's a live band, with precomposed videos playing back (with stop/start variations) across a bunch of analogue TVs placed on stage, all in sync with the sound. We don't know yet to what extent the result will be predetermined or generative but as long as there is the possibility of controlling the overall visual rhythm... The live sound from each instrument is also being transformed through lots of DSP in pd. So it's a complex setup and it needs to be reliable as we'll be taking the show on the road at some point. Many Thanks Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.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 Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com
Re: [PD] video output from PD
I would pick up an old rackmount ethernet switch and use static ips. I imagine wireless would work, but you're asking for trouble if you don't get an industrial wifi router. As for software, I'd echo using OpenFrameworks. The current version (0.8.0) now supports the RPI and there is an OMX video player class which can run with hardware acceleration. It would be simple to code a single, custom video player app that listens over OSC to start, stop, set frame position, etc. Said app would read from an xml file to know which video to load, so you don't have to hardcode anything. You will not be able to do this with PD alone on the RPI since, as mentioned before, GEM currently has no OPENGL ES support on the RPI. Email me if you guys need help/have a budget, although my timeframe is a little cramped right now. On Dec 1, 2013, at 6:00 AM, pd-list-requ...@iem.at wrote: From: peiman khosravi peimankhosr...@gmail.com Subject: Re: [PD] video output from PD Date: December 1, 2013 at 5:25:53 AM EST To: Charles Goyard c...@fsck.fr Cc: PD List pd-list@iem.at Hello, Thanks for the answers. I've been looking around and it doesn't look like that omxplayer accepts OSC messages. Does it? Also how are the Pis connected to a network? Through ethernet? In this case I would need a router with 20 outputs right? To explain a bit more about the project. It's a live band, with precomposed videos playing back (with stop/start variations) across a bunch of analogue TVs placed on stage, all in sync with the sound. We don't know yet to what extent the result will be predetermined or generative but as long as there is the possibility of controlling the overall visual rhythm... The live sound from each instrument is also being transformed through lots of DSP in pd. So it's a complex setup and it needs to be reliable as we'll be taking the show on the road at some point. Many Thanks Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Selfdestroying patches
Sine you're opening the patches via libpd through ofxPd, you already have the pointer to the patch instance. Simply use that to close each instance individually. If you want to have the patch close itself, you can have it send a message to the C++ layer with it's $0 or a custom index so you know which object to close. On Nov 18, 2013, at 6:00 AM, pd-list-requ...@iem.at wrote: From: Ronni Montoya ronni.mont...@gmail.com Subject: [PD] Selfdestroying patches Date: November 17, 2013 at 10:44:59 PM EST To: PD List pd-list@iem.at Hi, im opening multiple instances of a pd patch from openframeworks using the ofxPd library . My patch generates a grain, so when i create multiple instances of this patch from openframeworks it generates a granular cloud. I need that after the grain is generated ( when sound finishes) the patch can selfdestroy itself ( instance get closed) . How can i do this? cheers R. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PdParty (PD + iOS) seeking more testers
Howdy again, I just pushed a new PdParty build to TestFlight which adds GPS compass events (Alexandre has a lucky student). Also, I sent the TestFlight info to at least 7-8 people, but have had only 2 sign up. If you haven't yet and still want to join in trying the app, please check for an email from me which has the my app sign up link. Follow that and sign up for TF, then follow it's instructions and install the TF app on your iDevice. On both steps, I'll get a notification to add you to the project and to the profile for the next build. After that, you should get an email on each new build and you can use the TF app to update PdParty. It sounds like a pain I know but, trust me, this is waay easier than doing it manually with device ids and provisioning profiles, etc. On Nov 13, 2013, at 2:34 AM, Dan Wilcox danomat...@gmail.com wrote: Howdy all, I've used PdParty for a few small events and I'm seeking more testers. So far, it's been pretty stable and, other than a few rough edges, is ready for use. I just need an icon at this point before putting it on the app store. Reply to this if you want in. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd 0.45 [getdir] equivalent?
Howdy, Forgive me if I haven't kept up with the Pd 0.45 improvements, but is there/will there be a vanilla mechanism to get the full path of the current patch/parent etc? Basically, I'd like to be able to use the pd open patch.pd /path/to/dir open message in pure vanilla without hardcoding the path or relying on an external (ggee [getdir] does the job). As far as I know, there is no vanilla only way to do this, or am I wrong? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Announce: new rjlib compatible rc-patches
Howdy all, I've begun the process of porting my patch library to compatibility with / reliance on rjlib and an overall less reliance on externals so they will work well with libpd PdParty. In the spirit of release early, release often, you can get it from github in the rc folder: https://github.com/danomatika/rc-patches/tree/master/rc Full disclosure: I've always turned cool examples from this list into abstractions and generally attribute the original authors. I also borrow some abstractions from other libraries in order to keep outside requirements low (mainly some from of the list-abs). Please let me know if I miss an attribution or if you don't want me to include an abstraction you've written. Highlights include: (I recommend the crossfm/pm/fmpm synths + GEM trying Pd-extended + Billy Idol in c_midiplay-help!) c_autospigot - pass a signal only if it's above an amplitude threshold c_midiplay - midifile player (requires mrpeach [midifile]) c_nstep - arbitrary length bang sequence player c_playlist - manage a playlist from a text file c_qseq - sequencer interface to qlist c_spigot - toggle a signal without clicking e_3bandeq - dj-style 3 band equalizer e_moog - moog style resonant low pass filter (requires ggee) e_powdist - pow based distortion e_ringmod - ring modulation g_scope - simple oscilloscope gui g_spectroscope - frequency spectrum gui g_vu - mono vu meter g_vu2 - stereo vu meter m_ctlin - ctlin that can learn it's ctl num channel m_fadtodb - convert fader scale to vu db m_mavg - moving average filter m_scalefilter - filter notes based on a given scale s_303 - roland tb 303 style bass synth (requires ggee) s_crossfm - cross frequency modulation synth s_crossfmpm - cross frequency / phase modulation synth s_crosspm - cross phase modulation synth s_sample - one shot sample player u_allnotesoff - send noteoff for all midi notes u_count - up/down counter u_demux2 - demultiplex from 1 inlet between 2 outlets u_list2symbol - convert a list into a symbol u_mux2 - multiplex between 2 inlets to 1 outleti u_openclose - open and close patches via filename (requires ggee) u_remote - send remote messages to state saving objects u_savestate - save load scene state settings u_tabdump - dump the contents of a table as a list u_tabset - set the contents of a table via a list Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] PdParty (PD + iOS) seeking more testers
Howdy all, I've used PdParty for a few small events and I'm seeking more testers. So far, it's been pretty stable and, other than a few rough edges, is ready for use. I just need an icon at this point before putting it on the app store. Reply to this if you want in. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Status of Fink packages
Sorry, this may not help much but: Wow, I didn't realize Fink was still around. Most people I know (including myself) are using Homebrew which currently has v0.11 json-c. I also did a check on Macports they have v0.9 ... :( On Nov 10, 2013, at 6:00 AM, pd-list-requ...@iem.at wrote: From: Thomas Mayer tho...@residuum.org Subject: [PD] [OT] Status of Fink packages Date: November 9, 2013 at 10:00:37 AM EST To: PD List pd-list@iem.at Hello, sorry for this off topic question, but I am requiring version 0.11 of json-c for the next release of PuREST JSON, and I do not have a Mac. Currently search for packages (http://pdb.finkproject.org/pdb/index.php) on the Fink website does not load, and so I have no way to see the current version of json-c in it. Is there any other way to look up the version? If it has an older version, can someone please upgrade to 0.11 (https://s3.amazonaws.com/json-c_releases/releases/index.html)? Thanks in advance, Thomas -- Theoretically, [the amount of money in circulation] is watched carefully by clever, serious economists. In practice, all the world's money is one big swirling, whirling pool. (Cory Doctorow - For The Win) http://www.residuum.org/ Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (no subject)
Hi Josh, The cppTest does not make any sound, it only runs the patch to test that message sending is working (something quick and dirty I wrote, not meant to be a working example). This is the same as the plain C test. This is by design because there is no default audio api layer in pure C++, as opposed to Obj-C/Cocoa. I'll add some notes to the comments about this. Simply put, you need to call the processFloat, processShort, etc functions in the audio processing callback of whatever audio api you use (PortAudio, Jack, CoreAudio, etc). So yes, the iOS examples do make sound because they use the libpd Obj-C audio unit and audio controller, but the cppTest does not. Also, there has been some work on the Obj-C wrapper so it can work on OSX as well. Has anyone done that/gotten it working? I'd love to get some info/Github pull request on what to change so we can add that functionality. On Nov 7, 2013, at 2:00 AM, pd-list-requ...@iem.at wrote: From: Joshan Mahmud joshan.mah...@gmail.com Subject: [PD] (no subject) Date: November 7, 2013 at 2:00:00 AM EST To: pd-list@iem.at pd-list@iem.at Hi all Apologise for the novice question, but I'm trying to work purely with C++ libpd (OSX desktop) and have been working with samples/cppTest/cpptest.xcodeproj from https://github.com/libpd/libpd. I can build the project fine (libpd the cppTest app) but when it opens the test patch (or any for that matter) I do not get any sound. The patch themselves works fine. Print statements are ok and sending receiving messages seem ok. But I even built a patch which just *~ two phasors, and couldn't hear it when I used the cppTest code to open my patch. I don't think there is anything wrong with libpd nor my sound card as I compiled ran the iOSTest project (deployed to a simulator iPhone) and that worked (fuzzy audio, but sound came through). Anyone have any good ideas? I know that with the output AudioUnit on OSX has a default volume of 0 (unlike iOS which has default of 1.0 for volume) so would it be something like that? Thanks!!! Josh Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help with OSX App minefield
On Nov 4, 2013, at 1:35 PM, pd-list-requ...@iem.at wrote: But people aren't going to write a gui for Pd. There is already libpd and I don't see a bunch of elegant and efficient Pd frontends sprouting up because of that. (Though I'm sure there are a lot of projects that do cool things with it.) The main reason for this is that we haven't pulled out the gui elements yet. There isn't yet an interface in libpd to edit the object graph and I'm not sure where the plans are on that. Once it's there I'm sure we could see some interesting things. I imagine I could add patch editing to PdParty using Objective-C in about a week or two if I had such an interface. I agree with both Han's point that a long term goal of cleanly separating the gui from the dsp is what we want. At the same time, I agree with Jonathan in that we shouldn't abandon/neglect what's already here and working. The overall plan, as far as I know, is once there is a clean separation the dsp core from the gui, the pd tcl/tk app would then be updated to use libpd. As for when that would happen, who knows? Anyone want to hire Jonathan, Hans, me, etc at a research lab to do it? I'll be available in the spring :D Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-l2ork running on OSX (was: Re: New Blankets names Jonathan Wilkes Artist in Transit Fellow)
Can you check the link? Didn't work for me ... also, we should all donate if we can. Jonathan has been doing alot of great work. On Oct 25, 2013, at 6:00 AM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: [PD] Pd-l2ork running on OSX (was: Re: New Blankets names Jonathan Wilkes Artist in Transit Fellow) Date: October 25, 2013 at 12:02:15 AM EDT To: pd-list@iem.at pd-list@iem.at Apropos: Here's a first attempt at getting Pd-l2ork up and running on OSX: https://jwilkes.nfshost.com/Pd-l2ork.app.zip * Includes a few libraries: zexy, import, cyclone, and ggee * I also replaced the help browser with the search-plugin powered by the xapian backend * I added references and meta patches to the control, audio, and data structures tutorials. If you haven't used Pd-l2ork before, it has some interesting features: * infinite undo * preset_hub and preset_node for settings presets on patches and abstractions * quick-connect: e.g., make a [route 0 1 2 3 4 5 6 7] and eight message boxes below it, then select all of them and make a connection from the leftmost outlet of [route] to the leftmost message box. Now all are connected! (There are some other shortcuts when you select just the topmost or bottommost object, too.) * pdinfo, canvasinfo, and classinfo objects * a bunch of other improvements that should all probably be documented in a What's New patch that doesn't exist yet. Please test it and let me know how it works. If you'd like to give a donation, then please follow Joe's instructions below for the New Blankets mini-fundraiser. Best, Jonathan Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-l2ork running on OSX
Ok. Just playing around a little and noticed: * there are 2 Preferences menu options in the Pd menu, the first works and is a folder with further options while the second Preferences... doesn't do anything. * the Media menu has a couple empty sections with remaining separators where the Audio Midi settings options used to be * the put menu is empty when the main pd window is active, while Pd-extended simply greys out the menu options. The Put menu is then populated after selecting a canvas window. * the Search Browser works and is noticeably faster than the last time I tried it, but the search result links don't work for me. Navigating with links on the Home page do work. * I'm not a fan of the separate console window .. yet another window floating around, but that's not a huge deal * dosen't have the nice icon that pd-extended has :D also, pd-lork should consider using something similar to the nice About patch in Pd-extended. Oh, there are so many improvements in pd-lork! So nice. I hope most if not all of these make their way into vanilla. The gui performance is much better, although I like the Pd-extended main console window better. The patch cords are obviously nicer, although I like the straight lines in Pd-extended better with anti-aliasing off, however that's just a niggle. On Oct 25, 2013, at 6:00 AM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: [PD] Pd-l2ork running on OSX (was: Re: New Blankets names Jonathan Wilkes Artist in Transit Fellow) Date: October 25, 2013 at 12:02:15 AM EDT To: pd-list@iem.at pd-list@iem.at Apropos: Here's a first attempt at getting Pd-l2ork up and running on OSX: https://jwilkes.nfshost.com/Pd-l2ork.app.zip Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd on Mac OSX 10.9
Howdy all, I updated to OSX 10.9 Mavericks last night and pd-extended runs fine. Only note is that a dialog box pops up when you first run it saying You need X11 installed to run pd. In that case, simply download and install XQuartz which provides X11: http://xquartz.macosforge.org/landing/ I had XQuartz installed before but the OS upgrade must have removed it. In any case the dialog they give you includes some extra info so beginners should be able to figure it out. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On Oct 22, 2013, at 1:07 PM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] Building externals on OSX Date: October 22, 2013 1:14:41 PM EDT To: pd-list@iem.at On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Yes. It's a different instruction set and Rosetta, the PCC compatibility layer, won't run an OSX 10.7+. Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? http://update.omnigroup.com/ (Hardware / CPU type): Intel 97.8% PPC 2.2% https://www.adium.im/sparkle/ (CPU type): Intel 97.83% PPC 2.71% I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. Well, those sleek and sexy PPC devices were last made sold in 2005, so it's not a surprise the vast majority of people using OSX have Intel machines mainly because software developers ( the OS) have moved on to 32 bit and now 64 bit intel years ago. Your political bias notwithstanding (I say use what works for you), I have a 4 year old Apple laptop that still does everything I need with the latest version of OSX and I plan to upgrade to OSX Mavericks when it comes out. That's pretty good, as I had a job when I bought it and I am currently an unemployed artist working on his thesis right now, so it's good this sleek and sexy device is not yet an ugly, unprofitable one. As with anything, not everyone buys the newest one every iteration and I can say, without any hardware issues whatsoever so far, I got what I paid for. In any case, I've long thought of helping with the OSX compatibility for Pd (updating GEM to Cocoa/64 bit for instance) but I honestly don't have the time or support right now. Maybe next spring I can do a reverse kickstarter? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
I'm not going to argue OS politics, again use what works best for you. I can understand the frustration with how the build system works on OSX. It is actually really nice in a lot of ways but it took me a while to get the hang of it after switching from Linux. Without counting Debian, I still think there's really no need at this point to support a PPC build for OSX. When I wrote drop PPC support in earlier emails, I was referring only to OSX. The code as it is now should compile just fine on Debian PPC since the only architecture differences as far as I know would be compiling for little endian versus big endian on Intel. I don't think there are any architecture specific assembly / function calls in Pd. So in the end, dropping OSX PPC support helps in simplifying the build scripts at least. Again, I think there's really no need to host newer Pd OSX PPC binaries, just leave the last one there since anyone using it will be on a much older version of OSX anyway. On Oct 22, 2013, at 5:05 PM, pd-list-requ...@iem.at wrote: Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? http://update.omnigroup.com/ (Hardware / CPU type): Intel 97.8% PPC 2.2% https://www.adium.im/sparkle/ (CPU type): Intel 97.83% PPC 2.71% Thanks. Those are low numbers, but I'd imagine the number of PPC users is still fairly high: http://www.statisticbrain.com/apple-computer-company-statistics/ I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. Well, those sleek and sexy PPC devices were last made sold in 2005, so it's not a surprise the vast majority of people using OSX have Intel machines mainly because software developers ( the OS) have moved on to 32 bit and now 64 bit intel years ago. Debian supports PPC, no? Anyone know how it does on the old machines? I suppose since Pd is in the repos one could say it still supports PPC. :) Your political bias notwithstanding (I say use what works for you), Well, I'd call it a political stance. And where it seemed quirky and deeply personal when I first adopted it, it now seems simply to be a restatement of the scientific method for computer security, at a time when there have been revelations that show our computers really need to be as secure as possible against attacks. I'd also point out that yours is a political stance. While I understand it, I must disagree with it because in terms of security it is much more difficult to use the scientific method to check whether the specs actually fit the implementation. In some cases on proprietary OSes neither are known so you're forced to reverse engineer the software, and for complex systems that's too time consuming and expensive to do. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. On Oct 21, 2013, at 9:12 PM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] Building externals on OSX Date: October 21, 2013 4:20:55 PM EDT To: pd-list@iem.at On 10/21/2013 02:09 PM, Hans-Christoph Steiner wrote: That sounds like you're building pd/extra from Pd-vanilla. I never had any luck with that build system. That's part of the reason why I ripped out extra from Pd-extended and made it a standalone library. It was much easier to make it work that way. Figured this one out, too. It was a problem of building 64 bit binaries-- I just ended up building for i386 and the problem went away. If I'm going to go to the trouble of building for both architectures, then I might as well go ahead and build ppc, too. So the real solution would be for me to remove my current xcode setup and read all the stackoverflow workarounds telling which older XCode version to setup an environment that supports building for ppc. -Jonathan Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
Except that that old version of Xcode/gcc doesn't have all the nice SDK stuff in the newer versions of OSX nor any of the optimizations performed by llvm ... On Oct 21, 2013, at 10:03 PM, Miller Puckette m...@ucsd.edu wrote: THat agrees with my experience I compile Pd vanlla on a 32-bit machine running 10.4 (I believe) and it's perfectly happy to grind out 3-architecture binary externs. (If you look in 32-bit Pd vanilla you'll see that sigmund~, etc, are OK fro PPC, i386, or whatever-you-call-it 64 bit intel. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] trouble of pd at opening
We don't know what OS you're on. If it's Mac OSX (which it sounds like), you need to delete the resume windows state or better yet disable resume state for Pd altogether: http://puredata.info/docs/tutorials/HowToTurnOffResumeWindowsForPDOnMacOSX107Lion On Oct 18, 2013, at 5:00 AM, pd-list-requ...@iem.at wrote: From: Olivier Baudry olivierbaudry@hotmail.fr Subject: [PD] trouble of pd at opening Date: October 17, 2013 11:38:43 AM CDT To: pd-list@iem.at Reply-To: olivierbaudry@hotmail.fr Dear all Sometimes with pd extended 0.43.4 I encounter crash At opening of pd, pd open all patcher of the day. 1) Step by step, I delete .plist generated by pd to recover the trouble 2) Relaunch pd 3) Result is the same 4) Any, idea command line or other advice is welcome olivierbaudry_eba.vcf Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] trouble of pd at opening
I finally got around to moving the OSX window save state fix into the Problems Fixes section in the FAQ: http://puredata.info/docs/faq/help-pd-crashes-on-startup-on-mac-osx-10-7 Hopefully it will be easier to find in the future. I'll remove the old doc page. On Oct 18, 2013, at 5:00 AM, pd-list-requ...@iem.at wrote: From: Olivier Baudry olivierbaudry@hotmail.fr Subject: [PD] trouble of pd at opening Date: October 17, 2013 11:38:43 AM CDT To: pd-list@iem.at Reply-To: olivierbaudry@hotmail.fr Dear all Sometimes with pd extended 0.43.4 I encounter crash At opening of pd, pd open all patcher of the day. 1) Step by step, I delete .plist generated by pd to recover the trouble 2) Relaunch pd 3) Result is the same 4) Any, idea command line or other advice is welcome olivierbaudry_eba.vcf Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
