Re: [PD] auto-completion with popup [was: 3 new gui-plugins]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2011 08:02 PM, yvan volochine wrote: from a noob pov it could easily lead to problems such as: - why is pd behaving strangely suddenly ? - remove all your gui-plugins and try again ? - ooh, I forgot that I used xxx-plugin which is breaking pd ! if xxx-plugin was breaking Pd, then you probably don't have a chance to see the verbose messages either. anyhow, i think the default behaviour should not be targetted at the worst case but at the normal case, which i hope is the none-broken one. if things do break, the user (and that's not only the noob) ought to be given an easy way to inspect the problem (that is why i pushed hard to replace the numeric log-levels with symbolic ones) mfgtasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3GR0QACgkQkX2Xpv6ydvTOEwCggGDyMwyt96UyZL8e4ky9I8P9 JREAniva5Jb3V72VCRyecCMwEvxRcbto =f+8z -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CVs
hello, it depends on how the software is designed to control sound modules, the whole thing could be done with signal objects, then we could say that it would be controled by CV where voltage would be the amount of signal value. From my own experience of designing a synth on pd, it's easier to use signals for controling sound modules, rather than message system. - Josh Moore kh405.7h3...@gmail.com a écrit : I just got out of a long and heated argument with someone who claimed he was an EE and told me that digital synthesizers use CVs. I tried to explain to him that if they did, it would be ONLY a numerical conversion so he was wrong and he still insisted that digital synthesizers used CVs. Has anyone had this kind of experience? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Patrice Colet ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] 0.43 should still be a test version
Hi, I tested Pd Vanilla 0.43 for just a couple of days (this was some weeks ago) and I found enough show-stopper regressions that I had to immediately revert to version 0.42.5. Version 0.43 still isn't mature enough to be used for purposes other than testing it. It should not be considered as the recommended release for everyday use; and most important, until it is stable, bug fixes should be still released for version 0.42. I am especially worried about this last thing, as now for example I have to choose between a version that can't broadcast UDP packets on Linux (0.42.5) and a version where the GUI may stop responding at any time (0.43.0). Here are three bugs that make it unusable, all of them are regressions: bug 3298989: suddenly all the gui objects of a certain type (e.g. all sliders) stop responding bug 3273884: mouse wheel scrolling doesn't work (it scrolls all the way down and all the way up in a single step) bug 3273848: editing an object box is painful. Depending on where exactly you click, you may be unable to reach the last character (even with the right arrow key); you have to click on it several times until you are lucky. Note that this is not meant as criticism to the great effort that has been done to write Pd 0.43; if I am criticizing anything at all it is the decision to release it as a stable release superseding 0.42.5. It's just too soon. I understand that the more people download and use it, the sooner these bugs can be detected and fixed and the sooner PD 0.43 will be stable. But if testing has to be encouraged, it must be done in a fair way. People who are not downloading Pd for the sake of testing it, and who need to get the most stable version, should be aware that 0.43 is _not_ the version they should download. Cheers, m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 0.43 should still be a test version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/08/2011 02:14 PM, Matteo Sisti Sette wrote: Hi, Version 0.43 still isn't mature enough to be used for purposes other than testing it. i switched to Pd-0.43 in a few external production environments (installations that are not only handled by me, that is), and use it exclusively on my own machines. It should not be considered as the recommended release for everyday use; and most important, until it is stable, bug fixes should be still released for version 0.42. I am especially worried about this last thing, as now for example I have to choose between a version that can't broadcast UDP packets on Linux (0.42.5) and a version where the GUI may stop responding at any time (0.43.0). i guess you are aware that not being able to broadcast UDP packets is not a bug at all, it's simply a missing feature. fmgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3GjHYACgkQkX2Xpv6ydvTp7ACdFjT1lek9FFeSZIhQ4rp0m/vn omYAoKwD8w8vwXuq26NZFIYRDlDvs0un =fFpR -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] ANN: Upcoming L2Ork tour of Europe
Apologies for cross-posting. After 8 months of planning, fund-raising a metric ton of greenbacks, and literally thousands of hours of hard work distributed across dozens of souls, Linux Laptop Orchestra (L2Ork) is truly excited to announce our maiden tour of Europe May 12 June 1, 2011. Joining forces with our guest soloist Ron Coulter and our talented soprano l2orkist Aurora Martin, the ensemble will be touring 8 countries, performing and holding workshops in following locations: May 14 Linz, Austria (as part of LiWoLi festival) May 15 Ljubljana, Slovenia May 16 Budapest, Hungary May 19 Croatia May 21 - Hamburg, Germany (Academy of Music and Theater) May 24 - Amsterdam, Netherlands (STEIM) May 25 Amsterdam, Netherlands (Zaal 100) May 26 Utrecht, Netherlands (HKU) May 30 Paris, France (IRCAM) June 01 Oslo, Norway (NIME 2011) Hope to see you at one of our upcoming destinations! In the meantime, to stay up-to-date with the latest developments join our facebook page (http://www.facebook.com/group.php?gid=117918141555131) For additional info on L2Ork please visit http://l2ork.music.vt.edu On a somewhat related note, L2Ork has also made another series of updates to the Linux-centric pd-l2ork variation of Pd which is also available on the L2Ork site together with a series of externals and abstractions. For additional info on pd-l2ork please visit http://l2ork.music.vt.edu/main/?page_id=56 Should you happen to have any questions, suggestions or concerns, please do not hesitate to contact me. Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 0.43 should still be a test version
On 05/08/2011 02:14 PM, Matteo Sisti Sette wrote: Here are three bugs that make it unusable, all of them are regressions: [...] bug 3273884: mouse wheel scrolling doesn't work (it scrolls all the way down and all the way up in a single step) bug 3273848: editing an object box is painful. Depending on where exactly you click, you may be unable to reach the last character (even with the right arrow key); you have to click on it several times until you are lucky. are you on windows ? I can't reproduce any of those on linux with latest git. cheers, _y ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CVs
On Sat, 7 May 2011, Josh Moore wrote: I just got out of a long and heated argument with someone who claimed he was an EE and told me that digital synthesizers use CVs. What's CV ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CVs
On 2011-05-08 10:46, Mathieu Bouchard wrote: On Sat, 7 May 2011, Josh Moore wrote: I just got out of a long and heated argument with someone who claimed he was an EE and told me that digital synthesizers use CVs. What's CV ? Control Voltage. Analog synthesizers use it to control things like oscillator frequency and amplifier volume. At least some digital synths use software-generated CVs to control analog oscillators and filters because it takes less processing to generate control waveforms than the actual output waveform. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 0.43 should still be a test version
On May 8, 2011, at 8:28 AM, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/08/2011 02:14 PM, Matteo Sisti Sette wrote: Hi, Version 0.43 still isn't mature enough to be used for purposes other than testing it. i switched to Pd-0.43 in a few external production environments (installations that are not only handled by me, that is), and use it exclusively on my own machines. I've also switched all my development and testing activity to 0.43, but still use 0.42.5 for teaching. But I'm also on Ubuntu 10.10 and Mac OS X 10.5, so I'm not quick to upgrade. I think Miller uses 0.43 now too, but I could be wrong. If you are interested in continued development on 0.42.5, I think Ico has done some with pd-l2ork. .hc It should not be considered as the recommended release for everyday use; and most important, until it is stable, bug fixes should be still released for version 0.42. I am especially worried about this last thing, as now for example I have to choose between a version that can't broadcast UDP packets on Linux (0.42.5) and a version where the GUI may stop responding at any time (0.43.0). i guess you are aware that not being able to broadcast UDP packets is not a bug at all, it's simply a missing feature. Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] smartphone for pd
Sadly, I must say that the iThings have the best performance. Apple did a good job there. But the rest of their ridiculous restrictions make it a really bad platform to work with. With Android, its much more like the Windows/PC world, where most of the devices have pretty bad audio performance, but certain ones have good performance. I hear the Samsung Galaxy devices have good audio performance, but haven't tried it myself. I have a Motorola Droid, which plays patches well, but with 100-200ms latency. .hc On May 7, 2011, at 1:28 AM, ronni montoya wrote: Hi, which smartphone do you recommend for using pd on it? Is there any that is better suited for pd? thanks R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list If you are not part of the solution, you are part of the problem. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Arduino (again...)
The tricky part about using Arduinos on GNU/Linux or Mac OS X is that they reboot when you connect to them. So after the [open 1( message, your patch needs to wait until the arduino finishes rebooting to send the configuration. With Pduino, the Arduino should report the version out of the right outlet once it finishes rebooting, so you could use that as a trigger to send the config. Or just wait 5000 ms or something. .hc On May 7, 2011, at 4:44 PM, Pierre Massat wrote: Hello! I'm looking for a way to automate the opening of my arduino and it's pins. I managed to open it at pd's start-up with a loadbang and an open message. But it doesn't work for the digital pins. It seems like they need to be opened a little later, and not all at once. I tried to delay the loadbang and use and trigger, to no avail. Any advice? Pierre ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] auto-completion with popup [was: 3 new gui-plugins]
On May 8, 2011, at 3:33 AM, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2011 08:02 PM, yvan volochine wrote: from a noob pov it could easily lead to problems such as: - why is pd behaving strangely suddenly ? - remove all your gui-plugins and try again ? - ooh, I forgot that I used xxx-plugin which is breaking pd ! if xxx-plugin was breaking Pd, then you probably don't have a chance to see the verbose messages either. anyhow, i think the default behaviour should not be targetted at the worst case but at the normal case, which i hope is the none-broken one. if things do break, the user (and that's not only the noob) ought to be given an easy way to inspect the problem (that is why i pushed hard to replace the numeric log-levels with symbolic ones) On that note, I tried to figure out how to get the symbolic levels to show up on the menubutton, but I couldn't get it to work. So I settled on just in the menu itself. .hc We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] auto-completion with popup [was: 3 new gui-plugins]
On May 7, 2011, at 2:02 PM, yvan volochine wrote: IMHO it would be better to see what kind of extra libs/plugins are loaded without debug level (it's easy to forget that you have this maybe-buggy thing in your path). I'd vote for posting those by default. i'd do a gui-plugin that raises the debug-level. That's always a possibility, you can set the default debug level with a one liner like: set ::loglevel 4 As for what should be the default behavior, that's a tough question. I've heard from a lot of newbies that having lots of text in the Pd window at startup is quite intimidating, so I think its good to really only show errors and strong warnings by default. More advanced users can hopefully figure out how to set the log level. I see gui-plugins more like add-ons and seeing that some of them behave strangely, I think it's a good habit to have infos about external libs being loaded in default debug level. from a noob pov it could easily lead to problems such as: - why is pd behaving strangely suddenly ? - remove all your gui-plugins and try again ? - ooh, I forgot that I used xxx-plugin which is breaking pd ! this kind of infos posted at startup would make sense to me: Gem version x Gridflow version x xxx-plugin version x ... but maybe that's just me ;) I understand your point though and I'll remove it from my code. Those Gem, etc version reports are just the thing that the people I talked to were complaining about. If you are totally new, then being hit with a wall of mystery text can be intimidating. From my perspective, I also don't want to see anything but errors by default, because I can always easily switch to see the debug log. I think in this case, the interests of newbies and advanced users align nicely. Also, I think Pd-extended should include a number of plugins by default, like perhaps your completion plugin. So that would mean that the plugin reports would be shown by default. .hc I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Arduino (again...)
Ok, I will try that. Thanks! Pierre 2011/5/8 Hans-Christoph Steiner h...@at.or.at The tricky part about using Arduinos on GNU/Linux or Mac OS X is that they reboot when you connect to them. So after the [open 1( message, your patch needs to wait until the arduino finishes rebooting to send the configuration. With Pduino, the Arduino should report the version out of the right outlet once it finishes rebooting, so you could use that as a trigger to send the config. Or just wait 5000 ms or something. .hc On May 7, 2011, at 4:44 PM, Pierre Massat wrote: Hello! I'm looking for a way to automate the opening of my arduino and it's pins. I managed to open it at pd's start-up with a loadbang and an open message. But it doesn't work for the digital pins. It seems like they need to be opened a little later, and not all at once. I tried to delay the loadbang and use and trigger, to no avail. Any advice? Pierre ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] udpsend performance issue
Hi, If I send a few hundreds packed OSC messages with [udpsend], it blocks for about 100-200 milliseconds or more (I see the message udpsend blocked for xxx milliseconds in the console, and I notice the effects). I know that this is a lot of messages and I can (and have to) optimize things by avoiding sending unnecessary data, but: I have replaced [udpsend] with a [netsend 1] (this is by no means a workaround, just a test to compare performance) and if I send the very same messages (which actually means sending much more bytes), netsend does _not_ block for such a long time. It doesn't print any such message (and netsend does print it if it blocks for a significant time) and I don't notice any delay. I have verified that it is actually sending the data. So I wonder, is there an intrinsic reason why udspend takes much more time than netsend to send a certainly smaller amount of data? Or is udpsend simply implemented in a less efficient way? Does anybody know where the bottleneck is and if there is a way to eliminate it? thanks m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Arduino (again...)
I tried the 5000ms delay and it works perfectly. One (last ?) question : It seems like i have to unplug the arduino before i want to open it again. Can you confirm that i cannot leave it plugged in and open/close the connection from within Pd (I use linux) ? Thanks for your help! Pierre 2011/5/8 Pierre Massat pimas...@gmail.com Ok, I will try that. Thanks! Pierre 2011/5/8 Hans-Christoph Steiner h...@at.or.at The tricky part about using Arduinos on GNU/Linux or Mac OS X is that they reboot when you connect to them. So after the [open 1( message, your patch needs to wait until the arduino finishes rebooting to send the configuration. With Pduino, the Arduino should report the version out of the right outlet once it finishes rebooting, so you could use that as a trigger to send the config. Or just wait 5000 ms or something. .hc On May 7, 2011, at 4:44 PM, Pierre Massat wrote: Hello! I'm looking for a way to automate the opening of my arduino and it's pins. I managed to open it at pd's start-up with a loadbang and an open message. But it doesn't work for the digital pins. It seems like they need to be opened a little later, and not all at once. I tried to delay the loadbang and use and trigger, to no avail. Any advice? Pierre ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Arduino (again...)
close/open works for me. .hc On May 8, 2011, at 2:06 PM, Pierre Massat wrote: I tried the 5000ms delay and it works perfectly. One (last ?) question : It seems like i have to unplug the arduino before i want to open it again. Can you confirm that i cannot leave it plugged in and open/close the connection from within Pd (I use linux) ? Thanks for your help! Pierre 2011/5/8 Pierre Massat pimas...@gmail.com Ok, I will try that. Thanks! Pierre 2011/5/8 Hans-Christoph Steiner h...@at.or.at The tricky part about using Arduinos on GNU/Linux or Mac OS X is that they reboot when you connect to them. So after the [open 1( message, your patch needs to wait until the arduino finishes rebooting to send the configuration. With Pduino, the Arduino should report the version out of the right outlet once it finishes rebooting, so you could use that as a trigger to send the config. Or just wait 5000 ms or something. .hc On May 7, 2011, at 4:44 PM, Pierre Massat wrote: Hello! I'm looking for a way to automate the opening of my arduino and it's pins. I managed to open it at pd's start-up with a loadbang and an open message. But it doesn't work for the digital pins. It seems like they need to be opened a little later, and not all at once. I tried to delay the loadbang and use and trigger, to no avail. Any advice? Pierre ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list There is no way to peace, peace is the way. -A.J. Muste [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] problem with mixer project
I think I found the problem: if ALSA audio is selected the problem shows up, but if I select OSS the patch works perfectly well. Could somebody tell me why does that happen? Is there anyway to set automaticly audio to OSS and midi to ALSA inserting some code inside the patch or will I have to set this manually or with flags each time I load the patch? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CVs
On Sat, May 07, 2011 at 02:31:57PM -0800, Josh Moore wrote: I just got out of a long and heated argument with someone who claimed he was an EE and told me that digital synthesizers use CVs. I tried to explain to him that if they did, it would be ONLY a numerical conversion so he was wrong and he still insisted that digital synthesizers used CVs. Has anyone had this kind of experience? Yes, I have also had this experience of feeling frustrated by people claiming to be engineers. Cheers, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udpsend performance issue
On 2011-05-08 13:48, Matteo Sisti Sette wrote: Hi, If I send a few hundreds packed OSC messages with [udpsend], it blocks for about 100-200 milliseconds or more (I see the message udpsend blocked for xxx milliseconds in the console, and I notice the effects). I know that this is a lot of messages and I can (and have to) optimize things by avoiding sending unnecessary data, but: I have replaced [udpsend] with a [netsend 1] (this is by no means a workaround, just a test to compare performance) and if I send the very same messages (which actually means sending much more bytes), netsend does _not_ block for such a long time. It doesn't print any such message (and netsend does print it if it blocks for a significant time) and I don't notice any delay. I have verified that it is actually sending the data. So I wonder, is there an intrinsic reason why udspend takes much more time than netsend to send a certainly smaller amount of data? Or is udpsend simply implemented in a less efficient way? Does anybody know where the bottleneck is and if there is a way to eliminate it? [udpsend] uses almost the same code as [netsend] to send the data. I guess the bottleneck is in the way you load the hundreds of messages into [udpsend]. Are you receiving one packet per message at the other end? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udpsend performance issue
On 05/09/2011 04:54 AM, Martin Peach wrote: [udpsend] uses almost the same code as [netsend] to send the data. I guess the bottleneck is in the way you load the hundreds of messages into [udpsend]. Are you receiving one packet per message at the other end? What do you mean by one packet per message? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
