Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Tue, 8 Mar 2011, Andy Farnell wrote: This is pure superstition and folklore, but I'm sure it had something to do with using [knob] objects. Just a feeling in my bones. Well, that's possibly a very good guess. Now if only someone could look at [knob]'s code, to find out what might be wrong with it... Anything that uses sys_vgui() can be doing things wrong sometimes. For example, current sys_vgui() conventions can cause conflicting pointers in Win64, but there is no evidence that this ever happened. Afaict, this is a separate bug from the one you experienced, and from the windows bug that I've seen a long time ago. The Win64 bug is not easy to fix and it doesn't look like anyone will want to fix it anytime soon. ___ | 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Tue, 8 Mar 2011, Lorenzo Sutton wrote: I think I already used the cuisine metaphor here... My Italian genes always point me to that... Along the lines of Mathieu's (?) topic in the dataflow IRC about ready-made solutions. « Readymade Solutions Require Readymade Problems; For Everything Else There Is PureData.™ » But it also applies to MAX and every other programming language. I said it in opposition to the kind of audio app (or video app) that gives you a feature set to which the problem must be fitted (or else, too bad for you). Whenever I open any «audio app» other than Pd, all I can see is a bunch of limitations that is going to prevent me from doing what I want 30 minutes in the future. But when I say Pd here, it includes MAX. The choice between Pd and MAX is not what I had in mind when I thought of the above slogan, and of « The diagram is the program ». In the comparison between Pd and MAX, I don't think we need slogans nearly as much as we need more features (even though Pd already offers a lot of unique tools). ___ | 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] Toughts on PD vs. Max stability on macintels on, analogindustries.com
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-03-08 00:43, Hans-Christoph Steiner wrote: I guess you don't work in anything but 44100 sampling rates. I have done projects that use 22050 and 48k, and both won't work right unless the sampling rate is set correctly. Therefore its an essential property of the patch. hmm, most patches should be stable with regard to sample rate. so a patch that only works at 22kHz, could be considered buggy. otoh, i guess you are aware of that, and it indeed was hard to create a sample-rate agnostic version of the patch without going through ugly hacks (most likely: soundfiles recorded at specific sr, and no built-in capabilities of Pd to resample) finally: i've done plenty of patches that won't work at all if you only have stereo-output. personally i don't know whether it is a good idea to force a patch from within the patch to run at certain settings. the user usually has a better idea of the capabilities of their hardware then the off-site developer. the mediasettings library provides a programmatic way to change the settings, with possible userinteraction. the main target was to allow to implement persistent audio settings using alternative GUIs, rather than persistent audio settings when moving patches between hosts. mediasettings has been developed for the IntegraLive project; there has been long discussion within the project whether audio-settings should be Patch specific or host specific (and i cannot remember the outcome). i guess one should only try to set the parameters that are crucial (e.g. if you know that your patch will only run at 92kHz, only try to set the samplerate but don't try to change the device) mediasettings allows is (well it's designed to allow it; i hope it does) fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk116isACgkQkX2Xpv6ydvQeVQCgh7LoTB7c4ROwLqb/WlLbADU1 iRsAoMfTkUzrKoD2nWFleezM4YsWAZcP =evv6 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
chris clepper wrote: I get asked by people if Pd is ever coming out of beta. I think I already used the cuisine metaphor here... My Italian genes always point me to that... Along the lines of Mathieu's (?) topic in the dataflow IRC about ready-made solutions. And of course it would have been nice if he *shared* the patch(es) which made Pd crash. It's interesting (from a more, let's say 'social' point of view) that in these MAX vs PD, Windows VS Linux, commercial VS FLOSS discussions the former attitude is usually hey tried this, I think it's crap/too hard for me/buggy/can't use it at the first go... and the latter is always care to tell us what was wrong? whatever works best for you Interesting. Lorenzo. On Mon, Mar 7, 2011 at 2:47 PM, Mathieu Bouchard ma...@artengine.ca mailto:ma...@artengine.ca wrote: On Mon, 7 Mar 2011, Andy Farnell wrote: A trial version eh? Let's see how that comparison is working out in 30 days. I've been running a trial version of pd for 8 or 9 years now. I'm waiting for it to expire. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on, analogindustries.com
Hi, On Mon, Mar 07, 2011 at 10:46:02PM -0500, Mathieu Bouchard wrote: Right. But are some soundcards and/or drivers limited to only certain sampling rates ? Actually most soundcards only support a limited number of samplerates in their hardware, everything else then requires resampling in software. A common example are USB soundcards that often only support 48kHz or do not support high samplerates like 96kHz. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on, analogindustries.com
Hans-Christoph Steiner wrote: On Mar 7, 2011, at 1:28 PM, Peter Kirn wrote: Okay, I'm with others here - what is Chris on this time? I can see three complaints: 1. Ugly UI (fine.) 2. Lack of persistence of audio interface settings. Actually, two comments here on that -- first, of course, you can set this as a command-line argument, which to me is the safest way to go. But secondly, maybe there's a reason Pd can't persist audio settings between sessions? No idea. Anyway, at best, his comment here is misleading. You can definite make persistent audio interface settings. The preferred way is to set them in your patch. IOhannes is currently making a 'mediasettings' library which will make this much easier. Otherwise see get-audio-dialog in the 'hcs' lib. Otherwise just learn how to make a 1-line script, batch file or whatever it's called on MACs - uh Lorenzo. .hc 3. Crashes Crashes ... where? As near as I can tell, this entire rant is about the stability of vst~. (Is vst~ even part of Vanilla?) Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ 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] Toughts on PD vs. Max stability on macintels on, analogindustries.com
Hans-Christoph Steiner wrote: On Mar 7, 2011, at 6:19 PM, Mathieu Bouchard wrote: On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote: You can definite make persistent audio interface settings. The preferred way is to set them in your patch. Preferred by whom ? I can't picture anyone wanting to set anyone else's audio settings when they send someone else a patch. I guess you don't work in anything but 44100 sampling rates. I have done projects that use 22050 and 48k, and both won't work right unless the sampling rate is set correctly. Therefore its an essential property of the patch. But you can often use [samplerate~] in those situations no? Lorenzo. .hc IOhannes is currently making a 'mediasettings' library which will make this much easier. Otherwise see get-audio-dialog in the 'hcs' lib. But how can I edit that in ~/.pdsettings, ~/.pdextended, or whatever it is on whatever platform it is ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC http://at.or.at/hans/ ___ 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
Besides the unspecified bugs and crashes, I think what's overstated in that blog post is the brave comparison and generalization between OS and proprietary software. Imho it's fairly non-sense, even more 'cause not backed up by specifications or even simple ideas. I agree one can freely complain on his own blog, but, hey, fact is you're still using a free software and the license is quite clear about it. No warranty, if it doesn't work as you expect go on for Max. Without bothering yourself and the others. If you really need to do it, you can in a far more polite and constructive way. As we all know there's a massive amount of professionals working with Pd on Mac flawlessly. (I would be curious to know how many new blog visits he has in these days) M when i was giving a short Pd workshop in november there was a parallel session in maxMSP/jitter and one of those students came up to me and was complaining that MAX always crashed Pd didn't. just to throw in a equally unspecific report. -- Marco Donnarumma Independent New Media and Sonic Arts Professional, Performer, Instructor ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK ~ Portfolio: http://marcodonnarumma.com Lab: http://www.thesaddj.com | http://cntrl.sourceforge.net | http://www.flxer.net Event: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on, analogindustries.com
You can definite make persistent audio interface settings. The preferred way is to set them in your patch. Preferred by whom ? I can't picture anyone wanting to set anyone else's audio settings when they send someone else a patch. I guess you don't work in anything but 44100 sampling rates. I have done projects that use 22050 and 48k, and both won't work right unless the sampling rate is set correctly. Therefore its an essential property of the patch. But you can often use [samplerate~] in those situations no? There are some times when you have to know the sample rate beforehand, especially in delay situations where an algorithm depends both on the milliseconds of delay AND the actual number of samples. This can happen in reverb and filter design, and elsewhere. Otherwise this is also a problem in more obvious ways when you're playing sound files -- sometimes I'll make my patches so that if it detects the wrong [samplerate~] it tells the user to close the patch and fix it. Which reminds me: there used to be a problem with [delwrite~] where it would allocate its memory when the patch containing it loaded, based on the sample rate active at the time, such that if you switched Pd to a higher sample rate after the patch loaded, you'd have the same maximum number of samples of delay, but not the same maximum milliseconds. I remember there had been talk about fixing this, but if it's still a problem, this might be a reason not to set sample rate from the patch. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on, analogindustries.com
On Mar 8, 2011, at 4:43 AM, Lorenzo Sutton wrote: Hans-Christoph Steiner wrote: On Mar 7, 2011, at 6:19 PM, Mathieu Bouchard wrote: On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote: You can definite make persistent audio interface settings. The preferred way is to set them in your patch. Preferred by whom ? I can't picture anyone wanting to set anyone else's audio settings when they send someone else a patch. I guess you don't work in anything but 44100 sampling rates. I have done projects that use 22050 and 48k, and both won't work right unless the sampling rate is set correctly. Therefore its an essential property of the patch. But you can often use [samplerate~] in those situations no? Lorenzo. Sure, its totally possible to make patches with samples work at any sample rate, but usually this is a silly exercise in futility. For example, in most of my sound design work, the sound is going to end up as a 48k audio track to a video. Why would I work at anything but 48k? Sound cards have only a small set of supported sampling rates, MP3s/etc. mostly use one sampling rate, etc. .hc 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] Toughts on PD vs. Max stability on macintels on, analogindustries.com
On Tue, 8 Mar 2011, Lorenzo Sutton wrote: Hans-Christoph Steiner wrote: I guess you don't work in anything but 44100 sampling rates. I have done projects that use 22050 and 48k, and both won't work right unless the sampling rate is set correctly. Therefore its an essential property of the patch. But you can often use [samplerate~] in those situations no? Not necessarily. Even things like [lop~] look like they aren't adapting well to the samplerate, even though they are computed using samplerate. However, I haven't dug deep enough to figure out whether it was really a [lop~] problem, or rather a [vd~]/[tabread4~] problem, or perhaps a problem with the very concept of sampling (that is, that we shouldn't expect too much from harmonics that are too close to Nyquist... and that starts a lot below Nyquist frequency). ___ | 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] Toughts on PD vs. Max stability on macintels on, analogindustries.com
On Tue, 8 Mar 2011, Matt Barber wrote: Which reminds me: there used to be a problem with [delwrite~] where it would allocate its memory when the patch containing it loaded, based on the sample rate active at the time, such that if you switched Pd to a higher sample rate after the patch loaded, you'd have the same maximum number of samples of delay, but not the same maximum milliseconds. I remember there had been talk about fixing this, but if it's still a problem, this might be a reason not to set sample rate from the patch. I fixed that problem. The fix has been accepted and I think that it went in pd-extended 42.5, but I think that it wasn't listed in the change log. http://sourceforge.net/tracker/?func=detailaid=3011594group_id=55736atid=478072 http://sourceforge.net/tracker/index.php?func=detailaid=2978457group_id=55736atid=478072 It's split over two tickets because I don't really understand the difference between the patch tracker and the bug tracker. ___ | 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] Toughts on PD vs. Max stability on macintels on, analogindustries.com
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-03-08 16:46, Mathieu Bouchard wrote: On Tue, 8 Mar 2011, Matt Barber wrote: Which reminds me: there used to be a problem with [delwrite~] where it would allocate its memory when the patch containing it loaded, based on the sample rate active at the time, such that if you switched Pd to a higher sample rate after the patch loaded, you'd have the same maximum number of samples of delay, but not the same maximum milliseconds. I remember there had been talk about fixing this, but if it's still a problem, this might be a reason not to set sample rate from the patch. I fixed that problem. The fix has been accepted and I think that it went in pd-extended 42.5, but I think that it wasn't listed in the change log. http://sourceforge.net/tracker/?func=detailaid=3011594group_id=55736atid=478072 http://sourceforge.net/tracker/index.php?func=detailaid=2978457group_id=55736atid=478072 It's split over two tickets because I don't really understand the difference between the patch tracker and the bug tracker. btw, a bug issue can be changed into a patch issue. i guess you need admin rights for that, though. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk12UVEACgkQkX2Xpv6ydvSNGACfXEfsQNgR5MWUJ8HirYOYtx3D J6oAoMIEONrHHDJe5BbjeN0r/0Z2KD0a =Ei7B -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on, analogindustries.com
On Tue, 8 Mar 2011, IOhannes m zmoelnig wrote: On 2011-03-08 16:46, Mathieu Bouchard wrote: It's split over two tickets because I don't really understand the difference between the patch tracker and the bug tracker. btw, a bug issue can be changed into a patch issue. Yeah, but I wouldn't know what that means, because Hans copied the patch from the patch tracker to the bug tracker and marked the patch tracker item as a duplicate and considered the bug tracker item to be the non-duplicate. So, I don't know what the patch tracker is for, compared to the bug tracker, so I don't know why one would or would not change a bug issue into a patch issue and what it might change or not to the processing of issues. ___ | 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Mon, 7 Mar 2011, Miller Puckette wrote: On Mon, Mar 07, 2011 at 04:45:09PM -0500, Mathieu Bouchard wrote: Is that because of the version numbers ? They always begin with a zero. I never thought of that... It seems to be generalised all over pd : nearly all versioning of externals and abstractions is like that. I got tired of it and started trimming the 0 at the beginning of version numbers (instead of trying to correct my students when they were already doing so). When Iohannes confirmed that GEM won't ever reach 1.0, I started doing it even more liberally. Reminds me of the version number war between Digital Research DOS, MicroSoft DOS and IBM DOS... because much of the appreciation for modest, humble version numbers seemed to be in reaction to such sillyness. But it didn't take long before it went silly the other way. ___ | 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] Toughts on PD vs. Max stability on macintels on, analogindustries.com
On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote: On Mar 7, 2011, at 6:19 PM, Mathieu Bouchard wrote: I can't picture anyone wanting to set anyone else's audio settings when they send someone else a patch. I guess you don't work in anything but 44100 sampling rates. I have done projects that use 22050 and 48k, and both won't work right unless the sampling rate is set correctly. Therefore its an essential property of the patch. Ok, yeah, well, I do work in both 44100 and 22050, but I have nearly everything in 44100, and when I use 88200, it's only about part of the patch. But anyway I was thinking more about stuff like -oss -audiodev -channels. You are quite right about the sampling rate, but that means too bad for soundcards that don't support your patch. ___ | 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Tue, 8 Mar 2011, João Pais wrote: Randomly disappearing boxes, and generally, canvas appearance that stops reflecting canvas content — wasn't that a big WINDOWS®-only bug in Pd a few years ago ? No idea what the problem was. Does that still happen to anyone ? I've used Pd 99,% of my time in windows, and don't ever remember that happening. Since what year ? I think it was a fairly long time ago, although I do have a vague memory of having seen the problem much later and having been surprised, but that might have been simply because someone was using a very old version. My guess is that it was something that got fixed in Pd 38 or so (2004), but that's a bit of a wild guess. ___ | 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
I saw it quite recently. A student showed me a patch where objects kept disappearing. IIRC it would have been on a Mac with OSX 10.6 running whatever was the extended release available end October 2010 I said is was probably a graphics bug and to reinstall. AFAIK it went away. This is pure superstition and folklore, but I'm sure it had something to do with using [knob] objects. Just a feeling in my bones. a. On Tue, 8 Mar 2011 14:21:23 -0500 (EST) Mathieu Bouchard ma...@artengine.ca wrote: On Tue, 8 Mar 2011, João Pais wrote: Randomly disappearing boxes, and generally, canvas appearance that stops reflecting canvas content — wasn't that a big WINDOWS®-only bug in Pd a few years ago ? No idea what the problem was. Does that still happen to anyone ? I've used Pd 99,% of my time in windows, and don't ever remember that happening. Since what year ? I think it was a fairly long time ago, although I do have a vague memory of having seen the problem much later and having been surprised, but that might have been simply because someone was using a very old version. My guess is that it was something that got fixed in Pd 38 or so (2004), but that's a bit of a wild guess. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Tue, 8 Mar 2011, Marco Donnarumma wrote: I agree one can freely complain on his own blog, but, hey, fact is you're still using a free software and the license is quite clear about it. No warranty, if it doesn't work as you expect go on for Max. Without bothering yourself and the others. If you really need to do it, you can in a far more polite and constructive way. I went to read another older (2010) discussion about Pd on the same blog, and it made all pd-list arguments look like a happy family having fun. That blog is not for the faint of heart. Just ignore it. (I would be curious to know how many new blog visits he has in these days) It's probably better not to know. ___ | 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
Randomly disappearing boxes, and generally, canvas appearance that stops reflecting canvas content — wasn't that a big WINDOWS®-only bug in Pd a few years ago ? No idea what the problem was. Does that still happen to anyone ? I've used Pd 99,% of my time in windows, and don't ever remember that happening. Since what year ? since the year I dropped max for windows, around 2004 or something. between other reasons (OpS), max was crashing a lot, and only by looking at a metro it was possible to see that it wasn't that regular at all. to be fair, it was the first max version for windows, now is better. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
Hi everybody. I regularly read the blog @ analogindustries.com, and today an interesting post about pd vs max/msp stability on macintel appeared. You can read about it here http://www.analogindustries.com/blog/entry.php?blogid=1299508451902 To be honest, I always found pd on PPC macs to be fairly stable for my needs, and the author of the post (in comments) points out that on pc's pd is fairly stable too. So I just wanted to bring out the matter to the community, just for the sake of discussion. No hatred please! :) cheers, p. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
A quick search of the mailing list and bug tracker don't reveal anything from Chris Randall. As a software developer he is no doubt aware that user bug reports are vital to fixing problems. I think he could have done a bit more to help his situation. On Mon, Mar 7, 2011 at 11:45 AM, pierlu pie...@gmail.com wrote: Hi everybody. I regularly read the blog @ analogindustries.com, and today an interesting post about pd vs max/msp stability on macintel appeared. You can read about it here http://www.analogindustries.com/blog/entry.php?blogid=1299508451902 To be honest, I always found pd on PPC macs to be fairly stable for my needs, and the author of the post (in comments) points out that on pc's pd is fairly stable too. So I just wanted to bring out the matter to the community, just for the sake of discussion. No hatred please! :) cheers, p. ___ 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
in the way that he is talking about looks like a more generalized problem, but in my personal experience i have no problem at all here, and about a way to configure audio and midi in pd for every time it starts, a software developer should not have a problem on it, even more, if it is using the software for years..well, just my opinion 2011/3/7 pierlu pie...@gmail.com Hi everybody. I regularly read the blog @ analogindustries.com, and today an interesting post about pd vs max/msp stability on macintel appeared. You can read about it here http://www.analogindustries.com/blog/entry.php?blogid=1299508451902 To be honest, I always found pd on PPC macs to be fairly stable for my needs, and the author of the post (in comments) points out that on pc's pd is fairly stable too. So I just wanted to bring out the matter to the community, just for the sake of discussion. No hatred please! :) cheers, p. ___ 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
Hear hear! Sure, there are crasher bugs with Pd, but if you aren't even going to bother to report them, how can you expect them to be fixed? Most of the developers of Pd use Pd in their own work, and therefore are very likely to fix problems they encounter. I rarely encounter crasher bugs because I try to fix them when they happen to me. So that points to something else: the area where the Pd devs work are the area where Pd will work best. I don't know any Pd dev doing a lot with VSTs or even MIDI, so that is not where Pd is going to shine. .hc On Mar 7, 2011, at 12:23 PM, chris clepper wrote: A quick search of the mailing list and bug tracker don't reveal anything from Chris Randall. As a software developer he is no doubt aware that user bug reports are vital to fixing problems. I think he could have done a bit more to help his situation. On Mon, Mar 7, 2011 at 11:45 AM, pierlu pie...@gmail.com wrote: Hi everybody. I regularly read the blog @ analogindustries.com, and today an interesting post about pd vs max/msp stability on macintel appeared. You can read about it here http://www.analogindustries.com/blog/entry.php?blogid=1299508451902 To be honest, I always found pd on PPC macs to be fairly stable for my needs, and the author of the post (in comments) points out that on pc's pd is fairly stable too. So I just wanted to bring out the matter to the community, just for the sake of discussion. No hatred please! :) cheers, p. ___ 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 [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] Toughts on PD vs. Max stability on macintels on analogindustries.com
Le 07/03/2011 18:33, Hans-Christoph Steiner a écrit : Hear hear! Sure, there are crasher bugs with Pd, but if you aren't even going to bother to report them, how can you expect them to be fixed? Most of the developers of Pd use Pd in their own work, and therefore are very likely to fix problems they encounter. I rarely encounter crasher bugs because I try to fix them when they happen to me. So that points to something else: the area where the Pd devs work are the area where Pd will work best. I don't know any Pd dev doing a lot with VSTs or even MIDI, so that is not where Pd is going to shine. pd works great with midi. (except sysex). it can be VERY accurate if you start pd -noaudio. c .hc On Mar 7, 2011, at 12:23 PM, chris clepper wrote: A quick search of the mailing list and bug tracker don't reveal anything from Chris Randall. As a software developer he is no doubt aware that user bug reports are vital to fixing problems. I think he could have done a bit more to help his situation. On Mon, Mar 7, 2011 at 11:45 AM, pierlu pie...@gmail.com mailto:pie...@gmail.com wrote: Hi everybody. I regularly read the blog @ analogindustries.com http://analogindustries.com, and today an interesting post about pd vs max/msp stability on macintel appeared. You can read about it here http://www.analogindustries.com/blog/entry.php?blogid=1299508451902 To be honest, I always found pd on PPC macs to be fairly stable for my needs, and the author of the post (in comments) points out that on pc's pd is fairly stable too. So I just wanted to bring out the matter to the community, just for the sake of discussion. No hatred please! :) cheers, p. ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list [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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
Well it works great with midi even with audio on. The thing I noticed is that cc messages are not as so responsive as midi messages. Working with launchpad I noticed that I can send at once several midi messages by pressing more than one button at a time while when sending cc messages I can only push one button at a time to make cc work properly. (the top row on the launchpad sends cc instead of midi messages). p. On Mon, Mar 7, 2011 at 6:49 PM, cyrille henry c...@chnry.net wrote: Le 07/03/2011 18:33, Hans-Christoph Steiner a écrit : Hear hear! Sure, there are crasher bugs with Pd, but if you aren't even going to bother to report them, how can you expect them to be fixed? Most of the developers of Pd use Pd in their own work, and therefore are very likely to fix problems they encounter. I rarely encounter crasher bugs because I try to fix them when they happen to me. So that points to something else: the area where the Pd devs work are the area where Pd will work best. I don't know any Pd dev doing a lot with VSTs or even MIDI, so that is not where Pd is going to shine. pd works great with midi. (except sysex). it can be VERY accurate if you start pd -noaudio. c .hc On Mar 7, 2011, at 12:23 PM, chris clepper wrote: A quick search of the mailing list and bug tracker don't reveal anything from Chris Randall. As a software developer he is no doubt aware that user bug reports are vital to fixing problems. I think he could have done a bit more to help his situation. On Mon, Mar 7, 2011 at 11:45 AM, pierlu pie...@gmail.com mailto:pie...@gmail.com wrote: Hi everybody. I regularly read the blog @ analogindustries.com http://analogindustries.com, and today an interesting post about pd vs max/msp stability on macintel appeared. You can read about it here http://www.analogindustries.com/blog/entry.php?blogid=1299508451902 To be honest, I always found pd on PPC macs to be fairly stable for my needs, and the author of the post (in comments) points out that on pc's pd is fairly stable too. So I just wanted to bring out the matter to the community, just for the sake of discussion. No hatred please! :) cheers, p. ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list [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 ___ 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] Toughts on PD vs. Max stability on macintels on, analogindustries.com
Okay, I'm with others here - what is Chris on this time? I can see three complaints: 1. Ugly UI (fine.) 2. Lack of persistence of audio interface settings. Actually, two comments here on that -- first, of course, you can set this as a command-line argument, which to me is the safest way to go. But secondly, maybe there's a reason Pd can't persist audio settings between sessions? No idea. Anyway, at best, his comment here is misleading. 3. "Crashes" Crashes ... where? As near as I can tell, this entire rant is about the stability of vst~. (Is vst~ even part of Vanilla?) Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
A trial version eh? Let's see how that comparison is working out in 30 days. a. On Mon, 7 Mar 2011 17:45:12 +0100 pierlu pie...@gmail.com wrote: Hi everybody. I regularly read the blog @ analogindustries.com, and today an interesting post about pd vs max/msp stability on macintel appeared. You can read about it here http://www.analogindustries.com/blog/entry.php?blogid=1299508451902 To be honest, I always found pd on PPC macs to be fairly stable for my needs, and the author of the post (in comments) points out that on pc's pd is fairly stable too. So I just wanted to bring out the matter to the community, just for the sake of discussion. No hatred please! :) cheers, p. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
Re-posting as my previous post got scrubbed - sorry, Thunderbird is convinced Pd-list archives are rich HTML. Doh. ;) Anyway, I understand now - Chris is complaining generally about stability, not about vst~. It's troubling, but he's not going into specifics, so it's hard to know how to respond. I am genuinely curious about what's causing his troubles; I suspect it isn't his imagination, so that makes me wonder what the cause is. As for the UI - well, I think everyone's aware of the situation there. For audio interface setting persistence, I see that is now improved in Pd-extended; don't know if that's a patch worth making to Vanilla. It's a question that comes up a lot, and I don't know enough about the state of that feature, but I'd be curious to know. Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Mon, 7 Mar 2011, Andy Farnell wrote: A trial version eh? Let's see how that comparison is working out in 30 days. I've been running a trial version of pd for 8 or 9 years now. I'm waiting for it to expire. ___ | 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
It's a missed opportunity for everyone involved. Here was a developer of audio plugins with a lot of experience who could have provided a lot of valuable feedback, but chose not to do so. It doesn't take that much time to fire off the crash log to the list or post something on Sourceforge, plus he would have a lot more direct interaction with the Pd developers. Could have been a mutually beneficial relationship. On Mon, Mar 7, 2011 at 2:04 PM, Peter Kirn pe...@createdigitalmedia.netwrote: Re-posting as my previous post got scrubbed - sorry, Thunderbird is convinced Pd-list archives are rich HTML. Doh. ;) Anyway, I understand now - Chris is complaining generally about stability, not about vst~. It's troubling, but he's not going into specifics, so it's hard to know how to respond. I am genuinely curious about what's causing his troubles; I suspect it isn't his imagination, so that makes me wonder what the cause is. As for the UI - well, I think everyone's aware of the situation there. For audio interface setting persistence, I see that is now improved in Pd-extended; don't know if that's a patch worth making to Vanilla. It's a question that comes up a lot, and I don't know enough about the state of that feature, but I'd be curious to know. Peter ___ 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
I get asked by people if Pd is ever coming out of beta. On Mon, Mar 7, 2011 at 2:47 PM, Mathieu Bouchard ma...@artengine.ca wrote: On Mon, 7 Mar 2011, Andy Farnell wrote: A trial version eh? Let's see how that comparison is working out in 30 days. I've been running a trial version of pd for 8 or 9 years now. I'm waiting for it to expire. ___ | 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Mon, 7 Mar 2011, Peter Kirn wrote: Anyway, I understand now - Chris is complaining generally about stability, not about vst~. It's troubling, but he's not going into specifics, so it's hard to know how to respond. I am genuinely curious about what's causing his troubles; I suspect it isn't his imagination, so that makes me wonder what the cause is. As for the UI - well, I think everyone's aware of the situation there. Randomly disappearing boxes, and generally, canvas appearance that stops reflecting canvas content — wasn't that a big WINDOWS®-only bug in Pd a few years ago ? No idea what the problem was. Does that still happen to anyone ? For audio interface setting persistence, I see that is now improved in Pd-extended; don't know if that's a patch worth making to Vanilla. The more difficult it is to apply patches to Vanilla, the less it's worth applying patches to Vanilla. ___ | 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
I just emailed Chris to see if he would send along crash logs and info. Maybe some bugs will get fixed from this. On Mon, Mar 7, 2011 at 2:50 PM, chris clepper cgclep...@gmail.com wrote: It's a missed opportunity for everyone involved. Here was a developer of audio plugins with a lot of experience who could have provided a lot of valuable feedback, but chose not to do so. It doesn't take that much time to fire off the crash log to the list or post something on Sourceforge, plus he would have a lot more direct interaction with the Pd developers. Could have been a mutually beneficial relationship. On Mon, Mar 7, 2011 at 2:04 PM, Peter Kirn pe...@createdigitalmedia.netwrote: Re-posting as my previous post got scrubbed - sorry, Thunderbird is convinced Pd-list archives are rich HTML. Doh. ;) Anyway, I understand now - Chris is complaining generally about stability, not about vst~. It's troubling, but he's not going into specifics, so it's hard to know how to respond. I am genuinely curious about what's causing his troubles; I suspect it isn't his imagination, so that makes me wonder what the cause is. As for the UI - well, I think everyone's aware of the situation there. For audio interface setting persistence, I see that is now improved in Pd-extended; don't know if that's a patch worth making to Vanilla. It's a question that comes up a lot, and I don't know enough about the state of that feature, but I'd be curious to know. Peter ___ 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Mon, 7 Mar 2011, chris clepper wrote: I get asked by people if Pd is ever coming out of beta. Is that because of the version numbers ? They always begin with a zero. ___ | 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
I never thought of that... cheers M On Mon, Mar 07, 2011 at 04:45:09PM -0500, Mathieu Bouchard wrote: On Mon, 7 Mar 2011, chris clepper wrote: I get asked by people if Pd is ever coming out of beta. Is that because of the version numbers ? They always begin with a zero. ___ | 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
--- On Mon, 3/7/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com To: chris clepper cgclep...@gmail.com Cc: pd-list@iem.at Date: Monday, March 7, 2011, 10:45 PM On Mon, 7 Mar 2011, chris clepper wrote: I get asked by people if Pd is ever coming out of beta. Is that because of the version numbers ? They always begin with a zero. But Gridflow goes up to 9. So just make sure to install Gridflow with Pd, and you should then be able to instantiate up to nine simple objects without Pd randomly crashing on you: [import gridflow] [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] -- Warning: 10th metro object may crash Pd -Jonathan ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -Inline Attachment Follows- ___ 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] Toughts on PD vs. Max stability on macintels on, analogindustries.com
On Mar 7, 2011, at 1:28 PM, Peter Kirn wrote: Okay, I'm with others here - what is Chris on this time? I can see three complaints: 1. Ugly UI (fine.) 2. Lack of persistence of audio interface settings. Actually, two comments here on that -- first, of course, you can set this as a command-line argument, which to me is the safest way to go. But secondly, maybe there's a reason Pd can't persist audio settings between sessions? No idea. Anyway, at best, his comment here is misleading. You can definite make persistent audio interface settings. The preferred way is to set them in your patch. IOhannes is currently making a 'mediasettings' library which will make this much easier. Otherwise see get-audio-dialog in the 'hcs' lib. .hc 3. Crashes Crashes ... where? As near as I can tell, this entire rant is about the stability of vst~. (Is vst~ even part of Vanilla?) Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Mar 7, 2011, at 5:07 PM, Jonathan Wilkes wrote: --- On Mon, 3/7/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com To: chris clepper cgclep...@gmail.com Cc: pd-list@iem.at Date: Monday, March 7, 2011, 10:45 PM On Mon, 7 Mar 2011, chris clepper wrote: I get asked by people if Pd is ever coming out of beta. Is that because of the version numbers ? They always begin with a zero. But Gridflow goes up to 9. So just make sure to install Gridflow with Pd, and you should then be able to instantiate up to nine simple objects without Pd randomly crashing on you: [import gridflow] [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] -- Warning: 10th metro object may crash Pd Wait, are you telling me that Pd doesn't got to 11?!? That must be fixed! But just created 10 linked metros and got no crash on Pd- extended 0.42.5 on Mac OSX 10.5.8. .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote: On Mar 7, 2011, at 5:07 PM, Jonathan Wilkes wrote: But Gridflow goes up to 9. So just make sure to install Gridflow with Pd, and you should then be able to instantiate up to nine simple objects without Pd randomly crashing on you: Wait, are you telling me that Pd doesn't got to 11?!? That must be fixed! Sure. Just wait until April 1st and I'll release GridFlow 11.0. ___ | 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
--- On Mon, 3/7/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com To: Jonathan Wilkes jancs...@yahoo.com Cc: chris clepper cgclep...@gmail.com, Mathieu Bouchard ma...@artengine.ca, pd-list@iem.at Date: Monday, March 7, 2011, 11:22 PM On Mar 7, 2011, at 5:07 PM, Jonathan Wilkes wrote: --- On Mon, 3/7/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com To: chris clepper cgclep...@gmail.com Cc: pd-list@iem.at Date: Monday, March 7, 2011, 10:45 PM On Mon, 7 Mar 2011, chris clepper wrote: I get asked by people if Pd is ever coming out of beta. Is that because of the version numbers ? They always begin with a zero. But Gridflow goes up to 9. So just make sure to install Gridflow with Pd, and you should then be able to instantiate up to nine simple objects without Pd randomly crashing on you: [import gridflow] [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] | [metro] -- Warning: 10th metro object may crash Pd Wait, are you telling me that Pd doesn't got to 11?!? That must be fixed! But just created 10 linked metros and got no crash on Pd-extended 0.42.5 on Mac OSX 10.5.8. Sorry, I should have put a disclaimer: complete hogwash! I was just referring to the blog that started this thread, where the complaint was that instantiating a simple [metro] object can crash Pd. I don't think it is true, nor do I think that there's a get-out-of-crash-free card for each integer above 0 in the GF numbering system. I made a patch once with a slider with range 0-11, but it only let you slide it up to 10, unless you click a [tgl] associated with it, to get one more. No matter what it's controlling, it's a lot of fun. -Jonathan .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on, analogindustries.com
On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote: You can definite make persistent audio interface settings. The preferred way is to set them in your patch. Preferred by whom ? I can't picture anyone wanting to set anyone else's audio settings when they send someone else a patch. IOhannes is currently making a 'mediasettings' library which will make this much easier. Otherwise see get-audio-dialog in the 'hcs' lib. But how can I edit that in ~/.pdsettings, ~/.pdextended, or whatever it is on whatever platform it is ? ___ | 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] Toughts on PD vs. Max stability on macintels on, analogindustries.com
On Mar 7, 2011, at 6:19 PM, Mathieu Bouchard wrote: On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote: You can definite make persistent audio interface settings. The preferred way is to set them in your patch. Preferred by whom ? I can't picture anyone wanting to set anyone else's audio settings when they send someone else a patch. I guess you don't work in anything but 44100 sampling rates. I have done projects that use 22050 and 48k, and both won't work right unless the sampling rate is set correctly. Therefore its an essential property of the patch. .hc IOhannes is currently making a 'mediasettings' library which will make this much easier. Otherwise see get-audio-dialog in the 'hcs' lib. But how can I edit that in ~/.pdsettings, ~/.pdextended, or whatever it is on whatever platform it is ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
Randomly disappearing boxes, and generally, canvas appearance that stops reflecting canvas content — wasn't that a big WINDOWS®-only bug in Pd a few years ago ? No idea what the problem was. Does that still happen to anyone ? I've used Pd 99,% of my time in windows, and don't ever remember that happening. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 when i was giving a short Pd workshop in november there was a parallel session in maxMSP/jitter and one of those students came up to me and was complaining that MAX always crashed Pd didn't. just to throw in a equally unspecific report. Am 08.03.2011 um 01:33 schrieb Hans-Christoph Steiner: Hear hear! Sure, there are crasher bugs with Pd, but if you aren't even going to bother to report them, how can you expect them to be fixed? Most of the developers of Pd use Pd in their own work, and therefore are very likely to fix problems they encounter. I rarely encounter crasher bugs because I try to fix them when they happen to me. So that points to something else: the area where the Pd devs work are the area where Pd will work best. I don't know any Pd dev doing a lot with VSTs or even MIDI, so that is not where Pd is going to shine. .hc On Mar 7, 2011, at 12:23 PM, chris clepper wrote: A quick search of the mailing list and bug tracker don't reveal anything from Chris Randall. As a software developer he is no doubt aware that user bug reports are vital to fixing problems. I think he could have done a bit more to help his situation. On Mon, Mar 7, 2011 at 11:45 AM, pierlu pie...@gmail.com wrote: Hi everybody. I regularly read the blog @ analogindustries.com, and today an interesting post about pd vs max/msp stability on macintel appeared. You can read about it here http://www.analogindustries.com/blog/entry.php?blogid=1299508451902 To be honest, I always found pd on PPC macs to be fairly stable for my needs, and the author of the post (in comments) points out that on pc's pd is fairly stable too. So I just wanted to bring out the matter to the community, just for the sake of discussion. No hatred please! :) cheers, p. ___ 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 [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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk11hVsACgkQ3EB7kzgMM6KfdgCfcHLjxVioPoKDf5XMTQUJeg0f 6msAnjcztRMz8wK9i7Ag2MeThtXaM6BV =C9WF -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com
On Tue, 8 Mar 2011, Max wrote: just to throw in a equally unspecific report. Yes. It's important to answer rumours using rumours. There's a prof who told me that she couldn't teach Pd, and it was because of its security holes. Then she also told me that Pd doesn't have any video support. After that she stopped answering emails. I also heard that MAX was so bad, there's a classroom where they had to ban Pd to ensure that it looked like buying MAX licenses had been a good investment. Much of MAX's popularity is due to vendor lock-in after cheap licenses had been dumped on students who happened to be taking courses that happened to require MAX. And of course, I mean MAX the software, not Max Neupert. ;) ___ | 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] Toughts on PD vs. Max stability on macintels on, analogindustries.com
On Mon, 7 Mar 2011, Jonathan Wilkes wrote: For Audio API (OSS, ALSA, etc.): You can choose the respective menu item, then set it up in the dialog window that pops up. Click Save all settings to... save all settings. Isn't that persistent audio interface settings? D'oh, yeah, but I don't notice it, as I still rely on commandline flags, shell-scripts and alias-commands. I knew it was somewhere... ;) Things I would normally set using the Media Menu: input devices, # of channels, whether or not to use multiple devices, delay. But delay is a kind of in-between : it's at once very machine-dependent and very patch-dependent. Some patches are meant for low-latency, and some patches have to be high-latency to prevent drop-outs, but the actual amount can't really be decided in advance in a machine-independent way. Things I would set using the Media Menu OR some kind of in-patch mechanism: sample rate Right. But are some soundcards and/or drivers limited to only certain sampling rates ? (Side note : I thought that my soundcard was quite limited, but now I try to find a limit to the sampling rate that I can set, and I can't find one...?) ___ | 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] Toughts on PD vs. Max stability on macintels on analogindustries.com
--- On Tue, 3/8/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] Toughts on PD vs. Max stability on macintels on analogindustries.com To: Max abonneme...@revolwear.com Cc: PD list pd-list@iem.at Date: Tuesday, March 8, 2011, 4:34 AM On Tue, 8 Mar 2011, Max wrote: just to throw in a equally unspecific report. Yes. It's important to answer rumours using rumours. There's a prof who told me that she couldn't teach Pd, and it was because of its security holes. I don't like the fact that every time I create an object in Pd, it is sent to the central Pd server which keeps logs of all the objects in our patches. I think Pd is selling the logs to third parties, because every time I part a stream of numbers I get tons of ads to the console window for Liberty University. -Jonathan Then she also told me that Pd doesn't have any video support. After that she stopped answering emails. I also heard that MAX was so bad, there's a classroom where they had to ban Pd to ensure that it looked like buying MAX licenses had been a good investment. Much of MAX's popularity is due to vendor lock-in after cheap licenses had been dumped on students who happened to be taking courses that happened to require MAX. And of course, I mean MAX the software, not Max Neupert. ;) ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -Inline Attachment Follows- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd vs GUI (Was Re: pd and multi-core processors)
I'd just like to add that the same happens to MIDI with DSP off on a rather strong machine (Opteron 148 @ 2200). In which sense the same happens? Do you mean that sending a MIDI message takes more CPU time than it should? -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd vs GUI (Was Re: pd and multi-core processors)
On Wed, Apr 7, 2010 at 4:26 PM, Matteo Sisti Sette matteosistise...@gmail.com wrote: I'd just like to add that the same happens to MIDI with DSP off on a rather strong machine (Opteron 148 @ 2200). In which sense the same happens? Do you mean that sending a MIDI message takes more CPU time than it should? Sorry i meant that giving too much job (in zero logical time) to the GUI has an impact on MIDI timing. Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd vs GUI (Was Re: pd and multi-core processors)
2010/4/7 András Murányi muran...@gmail.com: Sorry i meant that giving too much job (in zero logical time) to the GUI has an impact on MIDI timing. Andras Hi, What I noticed in a few project where I was using a heavy GUI and a midi controller was a big delay in the midi signal transmission. I always solved this problem splitting the GUI/engine patch and midi control patch in two different pd's instances . Does Anyone has experienced something similar? husk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd vs GUI (Was Re: pd and multi-core processors)
András Murányi escribió: On Wed, Apr 7, 2010 at 4:26 PM, Matteo Sisti Sette matteosistise...@gmail.com mailto:matteosistise...@gmail.com wrote: I'd just like to add that the same happens to MIDI with DSP off on a rather strong machine (Opteron 148 @ 2200). In which sense the same happens? Do you mean that sending a MIDI message takes more CPU time than it should? Sorry i meant that giving too much job (in zero logical time) to the GUI has an impact on MIDI timing. Oh yes of course, it has impact on everything :) -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Pd vs GUI (Was Re: pd and multi-core processors)
On Mon, Apr 5, 2010 at 8:43 PM, Matteo Sisti Sette matteosistise...@gmail.com wrote: (this is a little OT respect to the thread) nicely enough, pd's graphical interface and the actual process, are separate threads, The communication between the engine of Pd (Pd) and the graphical interface (GUI) is not as efficient as you may expect it to be - at least not as much as I expected it to be. When you send a message to a GUI object, such as for example a set message to the receive-symbol of a slider, the Pd process sends a message to the GUI process and the GUI process actually redraws what it has to redraw: so the Pd process is not blocked while all the (embarassingly cpu consuming) draw operation is performed. So you would expect that the time needed to send a message to a GUI object is just the time needed to send a message through a TCP socket. Not quite so. I don't know why, but when you send a message to a GUI object it takes significantly much more CPU time to the Pd process than simply sending a message through TCP, though much less than it takes to actually redraw things. I _guess_ the Pd process probably waits for some kind of aknowledgement or respose from the GUI process or something like that, but this is only a guess. I found this out because I create patches that have to be used on the stage by users that are not pd-ers, so I make extensive use of GUI. All significant parameters or values that can be changed and/or need to be monitored are displayed on the GUI. So I send a lot of messages to the GUI. I also store snapshots of configuration that are then called (_not_ loaded from disk at the moment of calling them), so there often are massive bursts of messages to a lot of GUI objects in zero logical time (I already reduced the messages to only the actually needed ones). So, soon I began to have a lot of audio dropouts. So I tried out a solution that seemed ridiculous at first: I made an engine patch which does all the audio and midi stuff but has no GUI, and an interface patch that has only the GUI stuff, and exchanges control data (in both senses of course) with the engine patch. And obviously I run them on two different instances of Pd. My protocol of communication between the two patches is not even very optimized, so I send a lot of messages that could actually be avoided (don't tell anybody). Well with this system, despite the huge quantity of messages to and from GUI, I get no dropouts at all, everything works fine. I have indeed replicated at the patch level the engine-GUI architecture that is already implemented in Pd. When I did it, I really was afraid that I was doing something stupid; but it did work, and it makes an enormous difference (well I did do some test before, that seemed to indicate that it may work). So the time it takes (meaning the time during which the Pd process is either blocked or busy) to send a message through a [netsend] (with even a little overhead: passing through a [s] and a [r], a [list prepend send] and a [list trim] at the very least) is significantly less than the time it takes to send a message to a GUI object. I am curious to know whether this overhead in the communication between the two processes of Pd is entirely necessary (to robustly guarantee consistency for example) - and in case it is not, whether it is going to be addressed in the gui-rewrite.. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com I'd just like to add that the same happens to MIDI with DSP off on a rather strong machine (Opteron 148 @ 2200). This is a very interesting thing that you brought up and i would very much like to hear the experts' opinions. Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
Hallo, Patco hat gesagt: // Patco wrote: Patco a écrit : The most deluding stuff is $0 for my concern, it's very harassing to not being able to use it in messages. all the other craps are quite tolerable here with last versions. [i $0] | [$1( is harassing/boring too. What about this? [bang( | [list append pd-$0-happy-new-year and all the best for 2007!] | [print] Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
Frank Barknecht a écrit : Hallo, Patco hat gesagt: // Patco wrote: Patco a écrit : The most deluding stuff is $0 for my concern, it's very harassing to not being able to use it in messages. all the other craps are quite tolerable here with last versions. [i $0] | [$1( is harassing/boring too. What about this? [bang( | [list append pd-$0-happy-new-year and all the best for 2007!] | [print] Ciao This is pretty elegant! Thanks. [r number of pd-list users] | [until] | [t a b] | | | [i 0][+1] | | | [s $0demux] [list append pd-$0-happy-new-year 2007] |[r $0demux] | | [demultiplex] | ..| [s user1] [s usern] Cheers. Pc. ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Dec 31, 2006, at 4:32 PM, Mathieu Bouchard wrote: On Sun, 31 Dec 2006, Hans-Christoph Steiner wrote: On Dec 30, 2006, at 5:27 PM, Mathieu Bouchard wrote: But how does the type of those cords represent anything else than limitations of the implementation? How does the choice of considering those things as distinct types, and the choice to not auto-convert between types, constitute wise design decisions, beyond just being things that we have to accept as fact in the context of Pd? Its a design choice, its part of the language. This is not an answer to any of the above questions, Unless you're asserting that I should not ask such questions. Any implementation would have to include that in order to be compatible. And that's false, unless you include as a requirement that programs that fail to run with pd should also fail with any replacement of pd (which is usually not something considered a requirement). Removing type constraints doesn't break compatibility, It's not like removing all type information, which would break the parts of programs that make decisions based on type information. You are free to believe anything you want. But if you look at all the implementations of Java, C, C++, etc. you will see that they all handle strong typing, static typing, whatever the exact same way with only minor caveats here and there that are usually labeled as incompatible. .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Dec 31, 2006, at 5:09 PM, carmen wrote: Yes, a lot of this kind of stuff is done for efficiency's sake, like messages vs. audio rate data. also for efficieny's sake (on the implementation side), some of the newer graphical dataflow / patcher engines consider them one and the same, and solve the rate-efficiency issue by allowing a mix of a wide range of threads of varying execution rate (chuck calls them Shreds) in synch in the same subpatch... Since there is often talk of threading on here, I want to clarify ChucK's shreds a bit. ChucK does not use threads like pthreads, or Mac OS X/Windows threads. Its shreds are more like Windows 3.1 threads, i.e. cooperative or non-preemptive as they put it. Basically, its structured quite similarly to Pd, Csound, etc., except that the scheduler is more flexible and exposed. Plus, you have to handle a lot of the scheduling. .hc ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list [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] [*] vs [*~]
On Dec 30, 2006, at 5:27 PM, Mathieu Bouchard wrote: On Thu, 28 Dec 2006, Hans-Christoph Steiner wrote: Much more importantly, the thick coords represent that a different data type is passing thru the coords. It's not really an issue of representing the implementation, instead it's representing that those two types of coords can not be intermixed. But how does the type of those cords represent anything else than limitations of the implementation? How does the choice of considering those things as distinct types, and the choice to not auto-convert between types, constitute wise design decisions, beyond just being things that we have to accept as fact in the context of Pd? Its a design choice, its part of the language. Any implementation would have to include that in order to be compatible. .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Dec 30, 2006, at 10:41 PM, David NG McCallum wrote: On 27/12/06, Tim Blechmann [EMAIL PROTECTED] wrote: Do you mean that it would be difficult to figure out what's a DSP object and what's not, in terms of figuring out what's in the DSP chain? from the user point of view, i think, it's a good idea, to have a specific separation between dsp and messaging, because both work with very different concepts. Maybe I shouldn't be jumping into this discussion so late, with little programming knowledge, but… If we're to think about the metaphor of dataflow languages, which is essentially modelled after electronics and circuits (and I'm thinking about analogue circuits, although I'm sure a similar argument could be made for digital), then there should be no difference between control and audio, because they're the exact same thing. We might think that separating control and audio makes perfect sense from a user standpoint---I even think so. But I'm pretty sure that we only think that way because we've learned to think within the dataflow paradigm. If this distinction never existed, we wouldn't think twice about mixing the types, because there wouldn't be any types. I remember learning the difference between floats and ints. From a user's standpoint, why bother? I remember resigning myself to well that's annoying, but I guess it's necessary. Why does Pd not distinguish, but Max does? As far as I understand, the difference between control and audio data exists purely for computational efficiency, and has no real conceptual basis. (Maybe I'm asking for a beatdown with that statement…) Yes, a lot of this kind of stuff is done for efficiency's sake, like messages vs. audio rate data. Its hard to get around that. But the strong types of symbol vs. float are an human-computer interface question. .hc D! -- __ _ _ _ __ _ http://sintheta.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list [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] [*] vs [*~]
On Dec 30, 2006, at 5:14 PM, Mathieu Bouchard wrote: On Thu, 28 Dec 2006, Hans-Christoph Steiner wrote: Pd is strongly typed, so floats and signal data are different types, just like floats and symbols. What is a type? (without just giving a list of the existing types in pd) What does strongly typed mean? Have you read what I wrote to you, about strongly typed being vague wording? I think the wikipedia page does a pretty good job of describing it: http://en.wikipedia.org/wiki/Strong_typing The bullet points in particular. .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Sun, 31 Dec 2006, Hans-Christoph Steiner wrote: On Dec 30, 2006, at 5:14 PM, Mathieu Bouchard wrote: Have you read what I wrote to you, about strongly typed being vague wording? I think the wikipedia page does a pretty good job of describing it: http://en.wikipedia.org/wiki/Strong_typing The bullet points in particular. No, not the bullet points, I mean like the part at the end that says: « For this reason, writers who wish to write unambiguously about type systems often eschew the term strong typing in favor of specific expressions such as static typing or type safety. » However, after dealing with types that long, I've come to believe that static typing is vague too. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Sun, 31 Dec 2006, Hans-Christoph Steiner wrote: On Dec 30, 2006, at 5:27 PM, Mathieu Bouchard wrote: But how does the type of those cords represent anything else than limitations of the implementation? How does the choice of considering those things as distinct types, and the choice to not auto-convert between types, constitute wise design decisions, beyond just being things that we have to accept as fact in the context of Pd? Its a design choice, its part of the language. This is not an answer to any of the above questions, Unless you're asserting that I should not ask such questions. Any implementation would have to include that in order to be compatible. And that's false, unless you include as a requirement that programs that fail to run with pd should also fail with any replacement of pd (which is usually not something considered a requirement). Removing type constraints doesn't break compatibility, It's not like removing all type information, which would break the parts of programs that make decisions based on type information. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
Yes, a lot of this kind of stuff is done for efficiency's sake, like messages vs. audio rate data. also for efficieny's sake (on the implementation side), some of the newer graphical dataflow / patcher engines consider them one and the same, and solve the rate-efficiency issue by allowing a mix of a wide range of threads of varying execution rate (chuck calls them Shreds) in synch in the same subpatch... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
Patco a écrit : The most deluding stuff is $0 for my concern, it's very harassing to not being able to use it in messages. all the other craps are quite tolerable here with last versions. [i $0] | [$1( is harassing/boring too. ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Thu, 28 Dec 2006, Hans-Christoph Steiner wrote: Much more importantly, the thick coords represent that a different data type is passing thru the coords. It's not really an issue of representing the implementation, instead it's representing that those two types of coords can not be intermixed. But how does the type of those cords represent anything else than limitations of the implementation? How does the choice of considering those things as distinct types, and the choice to not auto-convert between types, constitute wise design decisions, beyond just being things that we have to accept as fact in the context of Pd? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On 27/12/06, Tim Blechmann [EMAIL PROTECTED] wrote: Do you mean that it would be difficult to figure out what's a DSP object and what's not, in terms of figuring out what's in the DSP chain? from the user point of view, i think, it's a good idea, to have a specific separation between dsp and messaging, because both work with very different concepts. Maybe I shouldn't be jumping into this discussion so late, with little programming knowledge, but… If we're to think about the metaphor of dataflow languages, which is essentially modelled after electronics and circuits (and I'm thinking about analogue circuits, although I'm sure a similar argument could be made for digital), then there should be no difference between control and audio, because they're the exact same thing. We might think that separating control and audio makes perfect sense from a user standpoint---I even think so. But I'm pretty sure that we only think that way because we've learned to think within the dataflow paradigm. If this distinction never existed, we wouldn't think twice about mixing the types, because there wouldn't be any types. I remember learning the difference between floats and ints. From a user's standpoint, why bother? I remember resigning myself to well that's annoying, but I guess it's necessary. Why does Pd not distinguish, but Max does? As far as I understand, the difference between control and audio data exists purely for computational efficiency, and has no real conceptual basis. (Maybe I'm asking for a beatdown with that statement…) D! -- __ _ _ _ __ _ http://sintheta.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Sat, 30 Dec 2006, David NG McCallum wrote: If we're to think about the metaphor of dataflow languages, which is essentially modelled after electronics and circuits (and I'm thinking about analogue circuits, although I'm sure a similar argument could be made for digital), then there should be no difference between control and audio, because they're the exact same thing. If pd's message system was designed while thinking of any kind of hardware, it must've been MIDI hardware (nevermind undo the MIDI revolution...) while analogue circuits can transmit float-like messages by sending appropriate events (either in the data wire or as an auxiliary wire), they lack the dynamic range and the precision of the floats or even the integers. Fixing that requires a digital protocol, which is also what is required for supporting symbols. G-Pointers (at the heart of so-called Data Structures) require more than just a digital protocol, they require a common digital memory accessible by any object that is supposed to work on them. The main differences between messages and signals, is that messages have a very variable rate, an execution order, and more flexible feedback than signals. Also, the variable rate can convey meaning: there's a big difference between getting no message, and getting an empty (bang) message. Dataflow as a concept is not limited to a metaphor of electronic circuits, though lots of dataflow systems limit themselves like that. IMHO, dataflow is about outlets and inlets being connected and something (possibly anything) getting sent from outlet to inlet. [...] because we've learned to think within the dataflow paradigm. Actually you may call it the Miller paradigm instead: afaik, it's very appropriate to do so (factually speaking). If this distinction never existed, we wouldn't think twice about mixing the types, because there wouldn't be any types. Mostly agreed. As far as I understand, the difference between control and audio data exists purely for computational efficiency, and has no real conceptual basis. (Maybe I'm asking for a beatdown with that statement?) Trouble comes when you try to emulate messages using signals... efficiently... and without making things much more complicated than using messages. In the end, what's important is not so much to make the system simple, it's about making the system such that it makes the problem-solving simple. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
why is there no |!/~| object like in max/msp? I don't know. Where's the [swap] that can support signals? ;) well, a |swap| object itself is not a really good solution without an optimizing compiler for the dsp chain ... and why is expr~ so slow? I don't know, this might deserve a look (or a rewrite). sample-wise dsp processing is usually way slower than block-wise. iirc, i read something about a factor 2 ... t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The aim of education is the knowledge, not of facts, but of values William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
If there was no DSP chain, or if the chain included all of the non-DSP, we might delay such determination until later... (but should we?) if there was no dsp chain, it would be easier to utilize several audio threads (see jackdmp) ... caching would definitely be worse, though ... But what if there was one dsp_chain per thread, and that when the dsp_add() phase happens, it adds to one of several dsp_chains depending on some kind of load-balancing metric? i'm not sure, if you can use traditional dsp chains for multi-threaded systems. probably you'd be better off, if you implement some multi-threaded graph traversal, so that parallel nodes can be run on separate cores. for now, i see several problems though: - the scheduling overhead of traversing a graph in contrary to iterating over an array - i'm not sure, if current general purpose operating systems are able to allow a thread scheduling, that's fine enough, maybe a linux-rt kernel with high-resolution timers and dyntick would be required for lowest latencies ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Your mind will answer most questions if you learn to relax and wait for the answer. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
--- Tim Blechmann [EMAIL PROTECTED] schrieb: and why is expr~ so slow? I don't know, this might deserve a look (or a rewrite). sample-wise dsp processing is usually way slower than block-wise. iirc, i read something about a factor 2 ... afaik, [expr~] does non-recursive / block-wise processing, whereas [fexpr~] does sample-wise / recursive processing. so, your explanation would apply to [fexpr~], if i am not totally wrong. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Dec 27, 2006, at 12:01 PM, Mathieu Bouchard wrote: I have some newbie questions here... why is it that [*] is only for floats, whereas if you want to multiply two signals one has to use [*~] ? Pd is strongly typed, so floats and signal data are different types, just like floats and symbols. And then why is it that [*~] can multiply a signal by a float, but [*] can't do that? And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left? Why is it that if I want to divide a float by a signal, then I have to explicitly cast the float to signal (using [sig~]) or use [expr~] ? The right inlet is generally matched to the first argument in the object box. In this context, it makes sense to have only [*~]'s right inlet violate the strict typing because you can't type signal data into the object box. .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [*] vs [*~]
I have some newbie questions here... why is it that [*] is only for floats, whereas if you want to multiply two signals one has to use [*~] ? And then why is it that [*~] can multiply a signal by a float, but [*] can't do that? And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left? Why is it that if I want to divide a float by a signal, then I have to explicitly cast the float to signal (using [sig~]) or use [expr~] ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
Haha at first I didn't see who posted this and thought, 'what a newb...' Now I'm thinking that some philosophic sparring of Pd fundamentals is about to begin. I'll make some popcorn and watch this one from the sidelines... ~Kyle On 12/27/06, Mathieu Bouchard [EMAIL PROTECTED] wrote: I have some newbie questions here... why is it that [*] is only for floats, whereas if you want to multiply two signals one has to use [*~] ? And then why is it that [*~] can multiply a signal by a float, but [*] can't do that? And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left? Why is it that if I want to divide a float by a signal, then I have to explicitly cast the float to signal (using [sig~]) or use [expr~] ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
some follow-ups: why is it that [*] is only for floats, whereas if you want to multiply two signals one has to use [*~] ? why do patch cords have different width? And then why is it that [*~] can multiply a signal by a float, but [*] can't do that? why can |*~| multiply two signals, but why can't |*~ 1| do that? And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left? Why is it that if I want to divide a float by a signal, then I have to explicitly cast the float to signal (using [sig~]) or use [expr~] ? why is there no |!/~| object like in max/msp? and why is expr~ so slow? why are the inlets of |pow~| reversed? -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk I had nothing to offer anybody except my own confusion Jack Kerouac signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
Hallo! Hm ... what do you want to say ? You want polymorphism ? LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
I have some newbie questions here... why is it that [*] is only for floats, whereas if you want to multiply two signals one has to use [*~] ? And then why is it that [*~] can multiply a signal by a float, but [*] can't do that? because according to Pd rules its not OK to confuse the user with seperate objects/operators for floats vs ints or symbols vs strings, but ok for signals vs floats? why is it that [*] can't multiply a list by an integer? or is that what you mean by signal, a list of floats? And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left? Why is it that if I want to divide a float by a signal, then I have to explicitly cast the float to signal (using [sig~]) or use [expr~] ? the main reason i can think of is it's a lossy operation if the return value is a float. what value for the signal are you operating on - the value of the first sample in the DSP block? the average of all the samples in the block? the * vs *~ distinction might be useful to specify a desired return type.. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
What about efficiency? There may be certain advantages to defining the data types, and constraining _inlets_ and atom types during editing, rather than at run time. (that's just a guess) Hm ... what do you want to say ? You want polymorphism ? I say what I say. I'm asking, would we prefer polymorphism in this particular circumstance, and why or why not. (Of course I want polymorphism, but I don't want to push that into the question, else the question would be less questioning.) (In PureUnity I have to do strange hacks so that a box can be [+] or [+~] depending on the context, because I can't be satisfied just doing copy+paste and adding/deleting the ~ sign wherever needed: it's ugly to have to do that). ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Wed, 2006-12-27 at 13:43 -0500, Mathieu Bouchard wrote: On Wed, 27 Dec 2006, Georg Holzmann wrote: Hm ... what do you want to say ? You want polymorphism ? I say what I say. I'm asking, would we prefer polymorphism in this particular circumstance, and why or why not. (Of course I want polymorphism, but I don't want to push that into the question, else the question would be less questioning.) well, does polymorphism improve the expressive power in terms of determination between messaging and dsp? t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Wed, 27 Dec 2006, carmen wrote: Matju wrote: why is it that [*] is only for floats, whereas if you want to multiply two signals one has to use [*~] ? And then why is it that [*~] can multiply a signal by a float, but [*] can't do that? because according to Pd rules its not OK to confuse the user with seperate objects/operators for floats vs ints or symbols vs strings, but ok for signals vs floats? Well, signals have also that special mojo that makes their execution order fly high above the mortal mofos like floats and stuff... that would be a reason to keep them different. why is it that [*] can't multiply a list by an integer? [*], like many arithmetic classes, interpret a 2-element list as if it were: [unpack] || [* ] there's a lot of implicit [unpack] all over pd. If lists are to be supported in [*], we need to have them implemented differently... have another kind of list, a list-atom (A_LIST), but then, because it means a new way of interacting with atoms (unlike strings that can be handled just like symbols), it has to be given a new selector. This can't be 'list' because it's a conflict with an existing name that has different expectations (the existing 'list' is closer to 'anything'; the new selector goes with a single A_LIST element instead of having the message be the collection). or is that what you mean by signal, a list of floats? It could be, but there are three major distinctions: 1. that list is float-only, stored as t_float[] instead of t_atom[]. 2. that list would be A_LIST so that it doesn't get caught in [unpack]. 3. that list has the mojo. And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left? the main reason i can think of is it's a lossy operation if the return value is a float. The assumption that you are making is interesting: you assume that in this case the output would/could be a float, according to some unspecified rule which appears to be that the output type follows the type of the left input. In MAX (and jMax), float vs int is decided by the right input, not the left one. In GridFlow's [#], output size is determined by left input, which is sort of suggesting that output type should also be determined by left input (although this feature has not been implemented there). In Pd, the mode of [*~] (and such) is determined by right input. Actually, I should stress that this is determined by right argument, which then forces a specific right inlet type. I don't remember whether MAX/jMax's float-vs-int input type can be changed at runtime, but for atom-vs-signal I think I recall that they do it like Pd. what value for the signal are you operating on - the value of the first sample in the DSP block? In the logic of [#], it would be the first sample, because [#] causes an implicit [#redim] on its right input. the average of all the samples in the block? That wouldn't be so often useful for sound, would it? In any case, it's the same difference as between those two: [#downscale_by 64] [#downscale_by 64 smoothly] the * vs *~ distinction might be useful to specify a desired return type.. ... but that's only one way to specify a rule. doing it by the type of the right input (inlet and/or argument) is another way. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Wed, 27 Dec 2006, Tim Blechmann wrote: well, does polymorphism improve the expressive power in terms of determination between messaging and dsp? I can't answer because I can't guess what you mean by determination here. Do you mean that it would be difficult to figure out what's a DSP object and what's not, in terms of figuring out what's in the DSP chain? Why do we need a DSP chain? Why do those tilde have the mojo dsp_chain() stuff while the message mofos don't deserve such a cache-locality? If there was no DSP chain, or if the chain included all of the non-DSP, we might delay such determination until later... (but should we?) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Wed, 2006-12-27 at 15:40 -0500, Mathieu Bouchard wrote: On Wed, 27 Dec 2006, Tim Blechmann wrote: well, does polymorphism improve the expressive power in terms of determination between messaging and dsp? I can't answer because I can't guess what you mean by determination here. Do you mean that it would be difficult to figure out what's a DSP object and what's not, in terms of figuring out what's in the DSP chain? from the user point of view, i think, it's a good idea, to have a specific separation between dsp and messaging, because both work with very different concepts. Why do we need a DSP chain? Why do those tilde have the mojo dsp_chain() stuff while the message mofos don't deserve such a cache-locality? well, computing audio signals is usually way more expensive then computing messaging. for my personal performance patch, the messaging is usually less than 2% of the cpu usage... If there was no DSP chain, or if the chain included all of the non-DSP, we might delay such determination until later... (but should we?) if there was no dsp chain, it would be easier to utilize several audio threads (see jackdmp) ... caching would definitely be worse, though ... t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Wed, 27 Dec 2006, Tim Blechmann wrote: Matju wrote: why is it that [*] is only for floats, whereas if you want to multiply two signals one has to use [*~] ? why do patch cords have different width? Because Miller added that in 0.35 or 0.36 or some other release. But more deeply: because it reflects the nature of the implementation of pd or of its limitations. If it wanted to make more distinctions, it could have separated the patchcord types by message types and add several kind of zigzags, stipples, colours, etc. For example, in this diagram, http://www.videogamecritic.net/images/coleco/jumpman_junior.gif There are short zigzag cords vs long zigzag cords, and those inform the user about what those cords are for. (The red vs green distinction is optional, so that the visual appearance of the diagram communicates the same information if a two-tone display is used.) why is there no |!/~| object like in max/msp? I don't know. Where's the [swap] that can support signals? ;) and why is expr~ so slow? I don't know, this might deserve a look (or a rewrite). why are the inlets of |pow~| reversed? Because it was supposed to be called [!pow~] instead? I had nothing to offer anybody except my own confusion Jack Kerouac I'd rather have your confusion, than the certainty that some people offer... _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
On Wed, 27 Dec 2006, Tim Blechmann wrote: from the user point of view, i think, it's a good idea, to have a specific separation between dsp and messaging, because both work with very different concepts. But of the difference between dsp and messaging, which ones of the very differences of the very different concepts need to be emphasized, and which ones need to be downplayed? Just because there are differences, doesn't mean they need to be outlined in bold or tilde. Why do we need a DSP chain? Why do those tilde have the mojo dsp_chain() stuff while the message mofos don't deserve such a cache-locality? well, computing audio signals is usually way more expensive then computing messaging. for my personal performance patch, the messaging is usually less than 2% of the cpu usage... Ok, but messaging tends to happen in bursts. In a single-thread system, this has to happen between the processing of two blocks. If a [metro] gets only triggered every 100 blocks, that's 200% of CPU usage which ends up delaying the next block, so latency has to be increased in order to remove jitter. If there was no DSP chain, or if the chain included all of the non-DSP, we might delay such determination until later... (but should we?) if there was no dsp chain, it would be easier to utilize several audio threads (see jackdmp) ... caching would definitely be worse, though ... But what if there was one dsp_chain per thread, and that when the dsp_add() phase happens, it adds to one of several dsp_chains depending on some kind of load-balancing metric? The price an artist pays for doing what he wants is that he has to do it. -- William S. Burroughs Damn right. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
