Re: [PD] Midi and windows 7
David Schaffer wrote: Hi there, Whenever I start Pd extended on my win xp system, it warns me that midi in is dangerous under Windows. I would like to know if this issue has been solved with windows 7. it's just a message. it is not really dangerous (in the way that your roland guitar synth will blow up). the message is printed with the current MIDI implementation for w32 within Pd. it has nothing to do with the version of w32 you are running. i very seldomly use MIDI, but i did use MIDI on w32/xp without encountering any dangers. i think it is printed because the multimedia api (which is what Pd uses on w32 to access midi), is rather (old and) limited: e.g. there is no raw midi in. this might change once somebody takes care of it and ports the w32-midi to another API. in this case the warning might change. bottomline: i _think_ the danger mainly refers to the fact, that the objects might change. e.g. the [midiin] object might, at some day in the future, start emitting messages. don't let that take you by suprise. fmgasdr IOhannes 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] possible bug with iem_pbank_csv
Malte Steiner wrote: Hello first thanks to Thomas Musil for all his work on PD, its great! I think I have discoverd a bug in iem_pbank_csv, maybe its specific to my machine. When I write the data to disk and load it back I have only access to the first line. When I open the resulting .csv in an editor I see that all lines are there and that the data is stored correctly. I tried with different settings for delimiters and linebreaks but with same results. Same goes for the original helppatch. Last experiment I did with the example, copying the original csv file and than store another one with the same data. Again, when I reload it, it has suddenly only access to the settings from the first line while the original worked. When I compare the two files I can see a slightly difference, the good and working one as 2 bytes for linebreak (cr/rt perhaps) while the new one only has one. this is a known bug of iem_pbank_csv: it can only handle dos-like linebreaks (CRLF) and is helpless with unix linebreaks CR (or LF that is). it think that thomas has fixed this somewhere, but probably he never committed it :-( fgasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] PdParser
Hi, From the RjDj labs: PdParser can be used to parse Pd files in Python (for stuff like documentation for example). Browse here for the download: http://mccormick.cx/dev/PdParser/ Or check it out with bzr: bzr co http://mccormick.cx/dev/PdParser/ Example: (Find all objects which are comment boxes in the subpatch 'REFERENCE', and all messages boxes in the subpatch 'hello') p = PdParser(my-patch.pd) def found(canvasStack, type, action, bits): ... print canvasStack:, canvasStack, type:, type, action:, action, arguments:, bits ... p.add_filter_method(found, canvas=REFERENCE, type=#X, action=text) p.add_filter_method(found, canvas=hello, type=#X, action=msg) print p.parse(), elements found Best, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
I've certainly used patches with 500-1000 abstraction instances without problem, I guess I haven't tried 4600. I wouldn't be surprised at all if the limit (i.e. the point where things begins not working) were somwhere between the two numbers. I had a lot of problems with very big patches, and a lot of times things that worked perfectly fine with a dimension N stopped working with N+1, where by dimension I mean just the quantity of things (e.g. instances of a same abstraction), without the smallest change in complexity. In some cases some developer (I won't tell the name, but it's someone very important here) was able to find specific bugs and fixed it and published a new release. Unfortunately PD becomes somewhat unreliable if not unstable, when patches get really big. That's very frustrating, because the way it is 'defined' (i.e. the way it is supposed to work) really allows beautiful, complex, scalable design; but the implementation doesn't support it at the end. Also, these kind of bugs are very difficult to isolate. The greatest frustration is when you carefully design something so that size (e.g. number of instances) shouldn't be a problem, you strongly test it within a certain 'size' and verify it is rock-solid, and then, when you have everything working and your project grows a little bit and you just add a couple more instances of something, it stasrts crashing -- 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] Very large patches unstable?
Matteo Sisti Sette wrote: I've certainly used patches with 500-1000 abstraction instances without problem, I guess I haven't tried 4600. The greatest frustration is when you carefully design something so that size (e.g. number of instances) shouldn't be a problem, you strongly test it within a certain 'size' and verify it is rock-solid, and then, when you have everything working and your project grows a little bit and you just add a couple more instances of something, it stasrts crashing hmm, so what is your suggestion to solve the problem? either you restrict people to what they can do on purpose, or you allow them to go beyond limits. in some aspects, Pd does the former, in many it does the latter (which is the strength of Pd, i believe). however, pushing the limits inevitably also means hitting the limits. since the limits are always expanding, it is a bad target for development. rather i would have people who reach them, report here and provide examples how to reach these limits, so they can be fixed. i find Pd frustrating because it is so unstable is for me a highly frustrating statement. lines intentionally left blang to fill in the usualy rant on FLOSS software and the user mgfasdr IOhannes 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] Very large patches unstable?
hello, i made some patch that use 98454 abstractions. it certainly is very long to load, and almost impossible to save. but if your are patient, pd vanilla is solid like a rock. Cyrille Stephen Lucas a écrit : I'm experiencing some instability with a patch that is very large. Basically, I have an abstraction that does some calculations between a send and receive, whose names are controlled by the creation arguments of the abstraction. I made a little patch to create 68x68 of these (yes, I really need that many), and correctly place them on the canvas so that they don't overlap graphically. As far as I can tell, they all created fine and I even managed to save the patch. I did use a text editor to manually increase the size of the canvas, since message based object creation will not automatically resize the canvas if something will be past the bounds of the canvas. I've been getting inconsistant problems (crashing) with what I can only assume is an issue with a patch this large (4624 objects). If I understand things correctly, these abstractions do not have any DSP objects and should not be consuming large quantities of system resources if they're just hanging around, waiting to be used. I suspect the problem may mainly be linked to actually looking at the patch, which I don't need to do, but I don't feel confident using a patch that is always cheating death. If I don't look at the patch and just load it as an abstraction in another patch, it seems much more stable, but still takes a long time to create, delete, open, or close. Has anyone else seen this problem and am I crazy for trying to do this? In Max I probably would have tried to approach this using poly~, but I don't know any objects in pd that have similar methods of creating several instances of an abstraction. If this is simply a problem of having a very large canvas, I could compartmentalize the abstractions to solve that. Thanks to anyone who puts in their 2cents. -Stephen ___ 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] PdParser
It seems usefullthanks for share! husk On Wed, Dec 2, 2009 at 12:21 PM, Chris McCormick ch...@mccormick.cx wrote: Hi, From the RjDj labs: PdParser can be used to parse Pd files in Python (for stuff like documentation for example). Browse here for the download: http://mccormick.cx/dev/PdParser/ Or check it out with bzr: bzr co http://mccormick.cx/dev/PdParser/ Example: (Find all objects which are comment boxes in the subpatch 'REFERENCE', and all messages boxes in the subpatch 'hello') p = PdParser(my-patch.pd) def found(canvasStack, type, action, bits): ... print canvasStack:, canvasStack, type:, type, action:, action, arguments:, bits ... p.add_filter_method(found, canvas=REFERENCE, type=#X, action=text) p.add_filter_method(found, canvas=hello, type=#X, action=msg) print p.parse(), elements found Best, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- If identity in the Post-modernism is nothing you can call me a RadikalTeknoFreak Hartivist www.estereotips.net qeve.estereotips.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
IOhannes m zmoelnig escribió: hmm, so what is your suggestion to solve the problem? Unfortunately I am not a C++ developer so I cannot study the source code and give practical, specific, useful suggestions. The only suggestions I can give are the obvious ones: - fix the bugs - design things with an eye on optimization and scalability. Regarding the second point, just from what I have heard (i.e. I can't speak with full knowledge of the facts), I think a lot of things in PD are not implemented in the most optimized way, that is for example, double linked lists are used where more efficient data structures could be used. I guess efficiency is considered often not to be an issue just because it is (implicitely) considered unlikely that a user will put a few thousands objects with a dozen of levels of nesting (abstractions inside abstractions). I simply guess that in some cases, an implementation that is O(n^2) is chosen just because it is the easiest one, where a O(nlogn) is possible. The implicit assumption is that n won't ever be big enough to make a difference. Sometimes that assumption is reasonable, sometimes it is not. I can't suggest anything more specific than just ask yourself, when you (I'm saying 'you' meaning PD developers) take such decisions: Is it really safe to assume 'n' won't ever be big enough? Isn't it worth using a more efficient data structure? Can I really assume that it would be 'foolish' to have n[some value here]? Or maybe not? That is about pushing the limits. That accounts for cases where big numbers get unmanageable for efficiency reasons (either of time or of memory, but usually time), that is things get slow when they COULD be fast enough. BUT, that does not account for crashes. When PD (or any program) crashes, there's no philosophical reasoning about pushing/hitting/going beyound the limits that can justify that. When there's a crash, there's simply a bug. Some pointer goes out of the bounds of allocated memory, or maybe an integer wraps to negative values and is used as an array index, or whatever. That is, someone forgot to write a line of code that does a check; or, there is some kind of leak (memory leak, for example), which is simply due to an oversight in writing code, and probably that only becomes evident when numbers (of things doing things) get large. Etcetera. Those are bugs, oversights, it is not a matter of allowing to go beyound limits. Allowing the user to go beyound limits doesn't mean allocating N bytes and then allowing the user to address locations that don't exist. It doesn't mean using N bits for a number and allowing the user to introduce a number that exceeds 2^N. Allowing to go beyound the limits means designing things in such a way that they can be used in ways that the developer haven't thought about. And wherever a physical, numerical, well-defined limit still exists, which is unavoidable, it MUST be documented. in many it does the latter (which is the strength of Pd, i believe). Of course it does. That's why I love it. But sometimes I have the impression that though that is the philosophy, it is not fully expressed in the implementation. rather i would have people who reach them, report here and provide examples how to reach these limits, so they can be fixed. That's what I always do whenever I can. If I had the skills, I would even try to locate the problem in the source code, but I don't have them. So I just report the bugs and, if I can, provide some example patch. Sometimes however the bugs are too difficult to isolate, so the only patch I could send with the report, would be the complete patch, and usually I can't do that because I develop patches for artists (i.e. not for myself) so I can't make them publish even if I would like to. If they were mine, I would, but I can't trust people on behalf of other people. However in some cases I did manage to isolate the bug, report it, and even get it fixed. I know it feels bad to receive a bug report without an easy way to reproduce the bug. In those cases, I try to give as much information as I can in order to give some clue to the developers. i find Pd frustrating because it is so unstable is for me a highly frustrating statement. Well, since the subject was touched, I just thought I would just share my opinion. I am happy, and sorry at the same time, that I have transmitted you my frustration. Note that I keep using PD after all. Perhaps I should sometimes share also the great joys and satisfactions it gives me, and not only the frustrations which are a small percentage. I tend to be somewhat practical and write only when there's an issue to be solved; that implies being unintentionally negative. Cheers, m. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -
Re: [PD] Very large patches unstable?
Cyrille Henry wrote: i made some patch that use 98454 abstractions. it certainly is very long to load, and almost impossible to save. but if your are patient, pd vanilla is solid like a rock. Almost impossible to save: that's an example of what I consider to be a big issue and that seems to be overlooked (but the letter is just an impression). About the very long to load part, I simply think: is it avoidable? If it is, then it should be avoided. -- 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] possible bug with iem_pbank_csv
last night I checked out the iemlib from SVN but was to tired to setup everything for compilation but I recognized a commit by Thomas a while ago saying it is now OS independent which sounds like that. Have to test it. Otherwise its very handy for storing settings and work well with my patch and controlling hardware, in this case a BCF2000. I wonder what weired pd extended I have here, it says its 0.42.5 although the official is 0.41.4, I guess the Archaudio people put together something on their own. Cheers, Malte -- media art + development http://www.block4.com follow me on Twitter: http://twitter.com/herrsteiner or face the book: http://www.facebook.com/herrsteiner ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
Matteo Sisti Sette wrote: IOhannes m zmoelnig escribió: hmm, so what is your suggestion to solve the problem? Unfortunately I am not a C++ developer so I cannot study the source code and give practical, specific, useful suggestions. The only suggestions I can give are the obvious ones: - fix the bugs - design things with an eye on optimization and scalability. Before that I would try the very large patch on a faster computer with more RAM. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
Matteo Sisti Sette wrote: IOhannes m zmoelnig escribió: hmm, so what is your suggestion to solve the problem? Unfortunately I am not a C++ developer so I cannot study the source code and give practical, specific, useful suggestions. i was not talking about C/C++ suggestions. i fully understand that not everybody is able or willing (e.g. because of time constraints) to learn a programming language for the implementation of things like Pd. The only suggestions I can give are the obvious ones: - fix the bugs - design things with an eye on optimization and scalability. these are not the kind of suggestions i was trying to get. imo, they do not solve any problem, just put the load on those that were able or willing to do learn how to fix things on the code level. these are demands. I simply guess that in some cases, an implementation that is O(n^2) is chosen just because it is the easiest one, where a O(nlogn) is possible. hmm. it's entirely possible that you do learn to code C and implement something in O(nlogn) or O(1). i guess it is just easier to not. BUT, that does not account for crashes. When PD (or any program) crashes, there's no philosophical reasoning about pushing/hitting/going beyound the limits that can justify that. When there's a crash, there's simply a bug. i haven't claimed anything else. a bug is there to be fixed. it's not about philosophical reasoning, it's about practical doing. Some pointer goes out of the bounds of allocated memory, or maybe an integer wraps to negative values and is used as an array index, or whatever. That is, someone forgot to write a line of code that does a check; or, there is some kind of leak (memory leak, for example), which is simply due to an oversight in writing code, and probably that only becomes evident when numbers (of things doing things) get large. Etcetera. Those are bugs, oversights, it is not a matter of allowing to go beyound limits. no it's way simpler: Pd could just allow you to have a a single [osc~] object and a single [dac~] object. no need to write buggy code to dynamically create objects. simple to maintain. harder to create bugs. boring to use. allowing the user to go beyond limits usually involves more sophisticated code: easier to make errors, easier to create bugs. And wherever a physical, numerical, well-defined limit still exists, which is unavoidable, it MUST be documented. indeed. the Pdolice will get 'em sooner or later. in many it does the latter (which is the strength of Pd, i believe). Of course it does. That's why I love it. But sometimes I have the impression that though that is the philosophy, it is not fully expressed in the implementation. true. but what can you do about it? basically i see two ways: do it better, or tell people that they MUST do it better. rather i would have people who reach them, report here and provide examples how to reach these limits, so they can be fixed. That's what I always do whenever I can. If I had the skills, I would even try to locate the problem in the source code, but I don't have them. So I just report the bugs and, if I can, provide some example patch. Sometimes however the bugs are too difficult to isolate, so the only patch I could send with the report, would be the complete patch, and usually I can't do that because I develop patches for artists (i.e. not for myself) so I can't make them publish even if I would like to. If they were mine, I would, but I can't trust people on behalf of other people. but you feel that it is not too difficult for other people to isolate the bug and fix it, with nothing more than if i create 12000 instances of a patch (which i cannot send you because it's proprietary and i can't trust you) it crashes, but it doesn't crash with 20500 instances of another patch. However in some cases I did manage to isolate the bug, report it, and even get it fixed. which i appreciate (though right now i wonder why: it's not that anybody get's much for fixing the bug, apart from gory glory) i find Pd frustrating because it is so unstable is for me a highly frustrating statement. Well, since the subject was touched, I just thought I would just share my opinion. I am happy, and sorry at the same time, that I have transmitted you my frustration. Note that I keep using PD after all. Perhaps I should sometimes share also the great joys and satisfactions it gives me, and not only the frustrations which are a small percentage. I tend to be somewhat practical and write only when there's an issue to be solved; that implies being unintentionally negative. i don't have much problems with that. mostly i'm a very happy person (despite of how i write my emails) but if somebody is ready to shout your work frustrates me, than they should be prepared to get an answer your statement frustrates me. i think there's equal rights about frustrations and expressing them. lot's of the above i've written is a
Re: [PD] Very large patches unstable?
I'm currently working heavy on a patch that has 100ish abstractions that loads 1.1gigs of samples into memory, and it hasn't crashed yet. It does certainly take a couple minutes to load tho. But once it loads, I can work for days without restarting the patch, even thru putting the computer to sleep. I'm running Pd-extended 0.42.5-20091112. One thing I have noticed is that there was no feedback that the patch is loading. Pd just stops responding while loading the patch. This could be interpreted as a crash, but its not. Wait, and it'll eventually load. And I added a watch mouse cursor for Pd-extended when its loading, so that should help communicate that Pd is busy loading. As for shortening load times, Claude wrote code for caching abstractions which dramatically speeds things up, that would be nice to have, but it is also tricky to do. What's more important, faster load times or less bugs? That's my concern. .hc On Dec 2, 2009, at 6:51 AM, cyrille henry wrote: hello, i made some patch that use 98454 abstractions. it certainly is very long to load, and almost impossible to save. but if your are patient, pd vanilla is solid like a rock. Cyrille Stephen Lucas a écrit : I'm experiencing some instability with a patch that is very large. Basically, I have an abstraction that does some calculations between a send and receive, whose names are controlled by the creation arguments of the abstraction. I made a little patch to create 68x68 of these (yes, I really need that many), and correctly place them on the canvas so that they don't overlap graphically. As far as I can tell, they all created fine and I even managed to save the patch. I did use a text editor to manually increase the size of the canvas, since message based object creation will not automatically resize the canvas if something will be past the bounds of the canvas. I've been getting inconsistant problems (crashing) with what I can only assume is an issue with a patch this large (4624 objects). If I understand things correctly, these abstractions do not have any DSP objects and should not be consuming large quantities of system resources if they're just hanging around, waiting to be used. I suspect the problem may mainly be linked to actually looking at the patch, which I don't need to do, but I don't feel confident using a patch that is always cheating death. If I don't look at the patch and just load it as an abstraction in another patch, it seems much more stable, but still takes a long time to create, delete, open, or close. Has anyone else seen this problem and am I crazy for trying to do this? In Max I probably would have tried to approach this using poly~, but I don't know any objects in pd that have similar methods of creating several instances of an abstraction. If this is simply a problem of having a very large canvas, I could compartmentalize the abstractions to solve that. Thanks to anyone who puts in their 2cents. -Stephen ___ 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] possible bug with iem_pbank_csv
I compiled the iemlib and installed the resulting 4 files iem_mp3.pd_linux iem_t3_lib.pd_linux iemlib1.pd_linux iemlib2.pd_linux and added them to the startup bins and they load fine. Bug is persistent so I will look into the source later. Before I installed it I removed a iemlib folder which got installed by the extendend package before, having all externals as individual files. What I am missing now are the filters and stuff like gui-menue which worked before. Shouldnt they located in iemlib1? A bit confusing, some light would be appreciated. Cheers, Malte -- media art + development http://www.block4.com follow me on Twitter: http://twitter.com/herrsteiner or face the book: http://www.facebook.com/herrsteiner ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
What's more important, faster load times or less bugs? That's my concern. less bugs. every time. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Some more Pd related publication in Japan
Hi all, A book with a good amount of writing on Pd was issued on Dec.1 here in Japan. http://shop.cqpub.co.jp/hanbai/books/MBC/MBCZ201001.html As you may have guessed, the book is about building projects on the Arduino board. However, around half way through the book, it begins to devote pages on a thorough description of Pd and Firmata including a Pd reference. Projects in the later half of this book are mainly driven in Pd and nearly no Arduino code is listed.. The book appears to be categorized as a Mook (Magazine + book... is this term common elsewhere?) and does not have an ISBN assigned. -- David Shimamoto ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
Let's suppose 'I' am the user and 'you' are the developer, which I guess is partially true sometimes. Let's also say what should be implicit, that we are discussing for the sake of exchanging ideas, and that nobody is criticising the work of nobody, and also that the fact of replying in a somewhat 'polemic' tone doesn't mean one feels offended but only that the debate excites him/her (this is my case, hope it is yours as well). You're right, mine are not suggestions, they are demands. Wich leads me to what seems to be the (or one) underlying point throughout your email, that is: what right do I have to demand things from you? Why should you listen to my demands and work to fulfill [dunnow if it is the right verb here] them? What do you get from it? Well, I admit I don't know the answers; in a commercial software scenario it is easier, because you are paid to develop the software, and I [am supposed to] pay to use it, so asking to fix things is a right for me, and fixing things is a due for you. This is not the case with FLOSS and I don't really know what is the motivation for the developer to, well, develop. But I assume there is one, because if there wasn't one then the software would'nt exist and we wouldn't be talking about it. I have to assume that for some reason you (the developer) are interested in developing the software and in making it the best it can be. Otherwise, we wouldn't be talking in the first place. So, I don't have any right to demand anything, I am very grateful that PD exists the way it is, with its bugs and everything, and you don't have to fix anything; but assuming you are interested for some reason in developing the software and you are doing it, what kind of contribution can I give as a user? The answer is feedback, and feedback consists, among other things, in DEMANDS. These demands can be reasonable or foolish, that is, the feedback from the user can be valuable or useless. The latter also holds for bug reports (another kind of feedback), which can actually help to fix the bug or not. [...] allowing the user to go beyond limits usually involves more sophisticated code: easier to make errors, easier to create bugs. Well yes, I agree with that, or I understand that. Does that mean that we should be happy with the presence of bugs? Seems like you're saying: What do you prefer, a boring, simple, limited but rock-solid software, or a powerful, flexible [whatever positive adjective you may want to add here] but buggy one? Well if I, as a user, had to choose I would probably agree with you in chosing the second one, but you, as a developer, are [should be/may be/whatever] committed to go towards the goal of the flexible, powerful [etc] AND rock-solid software... Jesus, are we discussing whether bugs should be fixed or not? Remember (I say this to myself too) that the whole debate arose because somebody mentioned a situation of instability and I pointed out that it seems to be particularly frequent with big patches in PD. So, let's try not to take this as a criticism (maybe the tone of my first mail didn't help in this sense). PD is constantly under development, isn't it? It is not a finished product (if such a thing even exists). So, it has its strengths and weaknesses, like every piece of software. It doesn't make sense to discuss whether the first compensate the latter or viceversa; it MAY make sense to analyze its strengths and merits; but I think it is more useful to point out weaknesses so that they can be worked on in the future. What are the weak points of PD (don't be afraid, I won't try to list them)? Well, to make an example everybody knows the graphical interface is tremendously slow. That is well known; I don't know how much priority the developer community give to that problem (quite low I guess), but the problem is well known, so there is no need to discuss about it. One thing that I have experienced, and that a few users have experienced but, I suspect, not so many, is that with huge patches things start becoming unstable. Since it is not so frequent to hit this problem, when I did, I gave my feedback about them, including bug reports when I could isolate some reproducible crash, and test patches when I could. Now, since another user commented about instability with huge patches, I took the opportunity to stress again the importance that this kind of issue has (imo, obviously), and to express the feeling (possibly wrong) that they are not given the importance they deserve. That's all. sometimes I have the impression that though that is the philosophy, it is not fully expressed in the implementation. true. but what can you do about it? basically i see two ways: do it better, or tell people that they MUST do it better. Well, unfortunately I can't do it better, and about the second option, I guess you are sarchastic. I think there's a third thing I can do: give the developers information (i.e. reports,
Re: [PD] Very large patches unstable?
Here's a friendly suggestion, instead of spending time writing giant emails, spend that time trying to isolate the bugs that you are complaining about. If you can make a pd patch that reproduces a bug every time, then that is usually 90% of the work needed to get it fixed. I'm very unlikely to read really long emails, there is just too much email in the world these days, but I read every single bug report, and try almost all patch submitted to the trackers. If I have a Pd patch that shows me the problem, then I am very likely to try to fix it. .hc On Dec 2, 2009, at 11:36 AM, Matteo Sisti Sette wrote: Let's suppose 'I' am the user and 'you' are the developer, which I guess is partially true sometimes. Let's also say what should be implicit, that we are discussing for the sake of exchanging ideas, and that nobody is criticising the work of nobody, and also that the fact of replying in a somewhat 'polemic' tone doesn't mean one feels offended but only that the debate excites him/ her (this is my case, hope it is yours as well). You're right, mine are not suggestions, they are demands. Wich leads me to what seems to be the (or one) underlying point throughout your email, that is: what right do I have to demand things from you? Why should you listen to my demands and work to fulfill [dunnow if it is the right verb here] them? What do you get from it? Well, I admit I don't know the answers; in a commercial software scenario it is easier, because you are paid to develop the software, and I [am supposed to] pay to use it, so asking to fix things is a right for me, and fixing things is a due for you. This is not the case with FLOSS and I don't really know what is the motivation for the developer to, well, develop. But I assume there is one, because if there wasn't one then the software would'nt exist and we wouldn't be talking about it. I have to assume that for some reason you (the developer) are interested in developing the software and in making it the best it can be. Otherwise, we wouldn't be talking in the first place. So, I don't have any right to demand anything, I am very grateful that PD exists the way it is, with its bugs and everything, and you don't have to fix anything; but assuming you are interested for some reason in developing the software and you are doing it, what kind of contribution can I give as a user? The answer is feedback, and feedback consists, among other things, in DEMANDS. These demands can be reasonable or foolish, that is, the feedback from the user can be valuable or useless. The latter also holds for bug reports (another kind of feedback), which can actually help to fix the bug or not. [...] allowing the user to go beyond limits usually involves more sophisticated code: easier to make errors, easier to create bugs. Well yes, I agree with that, or I understand that. Does that mean that we should be happy with the presence of bugs? Seems like you're saying: What do you prefer, a boring, simple, limited but rock-solid software, or a powerful, flexible [whatever positive adjective you may want to add here] but buggy one? Well if I, as a user, had to choose I would probably agree with you in chosing the second one, but you, as a developer, are [should be/ may be/whatever] committed to go towards the goal of the flexible, powerful [etc] AND rock-solid software... Jesus, are we discussing whether bugs should be fixed or not? Remember (I say this to myself too) that the whole debate arose because somebody mentioned a situation of instability and I pointed out that it seems to be particularly frequent with big patches in PD. So, let's try not to take this as a criticism (maybe the tone of my first mail didn't help in this sense). PD is constantly under development, isn't it? It is not a finished product (if such a thing even exists). So, it has its strengths and weaknesses, like every piece of software. It doesn't make sense to discuss whether the first compensate the latter or viceversa; it MAY make sense to analyze its strengths and merits; but I think it is more useful to point out weaknesses so that they can be worked on in the future. What are the weak points of PD (don't be afraid, I won't try to list them)? Well, to make an example everybody knows the graphical interface is tremendously slow. That is well known; I don't know how much priority the developer community give to that problem (quite low I guess), but the problem is well known, so there is no need to discuss about it. One thing that I have experienced, and that a few users have experienced but, I suspect, not so many, is that with huge patches things start becoming unstable. Since it is not so frequent to hit this problem, when I did, I gave my feedback about them, including bug reports when I could isolate some reproducible crash, and test patches when I could. Now, since another user commented
Re: [PD] Very large patches unstable?
On Thu, 3 Dec 2009, hard off wrote: What's more important, faster load times or less bugs? That's my concern. less bugs. every time. You don't even know what are those bugs and whether they even exist. I'm not sure whether Hans knows either. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
Matteo Sisti Sette wrote: [...] allowing the user to go beyond limits usually involves more sophisticated code: easier to make errors, easier to create bugs. Well yes, I agree with that, or I understand that. Does that mean that we should be happy with the presence of bugs? Seems like you're saying: What do you prefer, a boring, simple, limited but rock-solid software, or a powerful, flexible [whatever positive adjective you may want to add here] but buggy one? Well if I, as a user, had to choose I would probably agree with you in chosing the second one, but you, as a developer, are [should be/may be/whatever] committed to go towards the goal of the flexible, powerful [etc] AND rock-solid software... i am sure that everyone agrees with that. it is only, that bugs do happen. and i think that they happen more often when writing more complicated code. not everybody here is called knuth. Jesus, are we discussing whether bugs should be fixed or not? i don't think we are discussing that (at least i hope; the thread seems to have the tendency towards such a discussion; i want to avoid it, as the answer is clear for me anyhow). in order to avoid more confusion: yes, i agree that all bugs should be fixed. (note that i don't _believe_ that all bugs _can_ be fixed; but this another thing) I am a developer also (or I consider myself such), though I don't develop in C++; obviously my work is way way simpler than something even comparable to a software like PD. i wish people would stop saying that there work is inferior than others they build upon. it's only slightly more annoying than people saying there work is better than the ones they build upon :-) (seriously: don't make yourself worse than you are; even if you cannot write something comparable to Pd, you can probably write things that those writing Pd cannot do) but if somebody is ready to shout your work frustrates me, than they should be prepared to get an answer your statement frustrates me. i think there's equal rights about frustrations and expressing them. Well I must recognize you are right here. But please be sure I didn't mean to shout. oh, i said i was polemic. fgmasdr IOhannes 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] Some more Pd related publication in Japan
Fun stuff. You should add a link on the puredata.info site, in the docs section. Perhaps in books? A news item would be nice too. .hc On Dec 2, 2009, at 11:27 AM, PSPunch wrote: Hi all, A book with a good amount of writing on Pd was issued on Dec.1 here in Japan. http://shop.cqpub.co.jp/hanbai/books/MBC/MBCZ201001.html As you may have guessed, the book is about building projects on the Arduino board. However, around half way through the book, it begins to devote pages on a thorough description of Pd and Firmata including a Pd reference. Projects in the later half of this book are mainly driven in Pd and nearly no Arduino code is listed.. The book appears to be categorized as a Mook (Magazine + book... is this term common elsewhere?) and does not have an ISBN assigned. -- David Shimamoto ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list 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] Very large patches unstable?
Martin Peach escribió: Matteo Sisti Sette wrote: The only suggestions I can give are the obvious ones: - fix the bugs - design things with an eye on optimization and scalability. Before that I would try the very large patch on a faster computer with more RAM. I strongly disagree with that. Maybe _after_, but certainly not _before_ that. That way of thinking (with all respect) is the reason why so much software is very badly done - and obviously I am _NOT_ talking about PD here. -- 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] Very large patches unstable?
On Wed, 2 Dec 2009, Matteo Sisti Sette wrote: The greatest frustration is when you carefully design something so that size (e.g. number of instances) shouldn't be a problem, you strongly test it within a certain 'size' and verify it is rock-solid, and then, when you have everything working and your project grows a little bit and you just add a couple more instances of something, it stasrts crashing [...] In some cases some developer (I won't tell the name, but it's someone very important here) was able to find specific bugs and fixed it and published a new release. I think it's more constructive to say who fixed bugs, even if it's someone who wrote the bugs in the first place. We shouldn't have a culture in which bugs are that much shameful, because it steepens a few learning curves, it raises the entry level, and it causes finished externals to stay sitting on their author's hard disk just because it's too long to review it to ensure it contains no potentially embarrassing mistakes... http://en.wikipedia.org/wiki/File:CatalysisScheme.png complex, scalable design; but the implementation doesn't support it at the end. Also, these kind of bugs are very difficult to isolate. It's hard to do anything about this unless we are talking about specific cases. I'd rather have you point at specific bugs than making general claims. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
On Wed, 2 Dec 2009, IOhannes m zmoelnig wrote: i find Pd frustrating because it is so unstable is for me a highly frustrating statement. I was also told we can't install Pd, because it is not secure. so we are using MAX instead. I asked questions about it but got no answers. This is in a university that sponsored a Pd Convention. lines intentionally left blang to fill in the usualy rant on FLOSS software and the user One minute of silence. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] noteout issue
Hi list, Probably not a 'pure' puredata issue but: [bang( | \ [36 100( [40 100( | / | / (both to inlet one) [noteout 10] triggers : - only one of the two notes (Linux Debian 5/Ubuntu 9.10) - two notes simultaneasly (Windows XP) i suspect it is something on the midi settings of alsa or something. thanks in advance. Sílvio Almeida _ Obtenha 30 Emoticons grátis para o seu Windows Live Messenger http://www.livemessenger-emoticons.com/funfamily/pt-pt/___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
On Wed, 2 Dec 2009, Matteo Sisti Sette wrote: are not implemented in the most optimized way, that is for example, double linked lists are used where more efficient data structures could be used. In almost all of Pd, singly-linked lists are used. That's even more inefficient than doubly-linked lists. I simply guess that in some cases, an implementation that is O(n^2) is chosen just because it is the easiest one, where a O(nlogn) is possible. Quite often, it's even O(n) vs O(n^2). really safe to assume 'n' won't ever be big enough? Isn't it worth using a more efficient data structure? Can I really assume that it would be 'foolish' to have n[some value here]? Or maybe not? I agree about this but it would be foolish to not think about how those modifications to the source code would get distributed. There's not much that I would bother to write for pd-vanilla, without à priori getting an explicit note from the man, certifying that the proposal won't sit for æternal rest in the holy sourceforget repository of forgotten diffs. Allowing to go beyound the limits means designing things in such a way that they can be used in ways that the developer haven't thought about. And wherever a physical, numerical, well-defined limit still exists, which is unavoidable, it MUST be documented. You can't learn that in a culture that encourages people to think of programming by imagining an infinite, strictly-monotonous sequence of ever-bigger computers, whereby if a given programme runs on any infinite subsequence of those computers, it's all fine. ;) Sometimes however the bugs are too difficult to isolate, If you still have not tried Valgrind, now is the time. It does wonders. Perhaps I should sometimes share also the great joys and satisfactions it gives me, and not only the frustrations which are a small percentage. I'm guilty of that too. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
On Wed, 2 Dec 2009, Martin Peach wrote: Before that I would try the very large patch on a faster computer with more RAM. Good idea. Now with four CPUs, you can now load Pd in the same amount of time as before, but as a bonus, your system is 75% CPU idle in the meanwhile. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
matju wrote: On Wed, 2 Dec 2009, Martin Peach wrote: Before that I would try the very large patch on a faster computer with more RAM. Good idea. Now with four CPUs, you can now load Pd in the same amount of time as before, but as a bonus, your system is 75% CPU idle in the meanwhile. Oh no of course not! You must then make your patch even bigger until it's again using 110% and crashes because of 'bugs'. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
On Wed, 2 Dec 2009, martin.pe...@sympatico.ca wrote: On Wed, 2 Dec 2009, Martin Peach wrote: Before that I would try the very large patch on a faster computer with more RAM. Good idea. Now with four CPUs, you can now load Pd in the same amount of time as before, but as a bonus, your system is 75% CPU idle in the meanwhile. Oh no of course not! You must then make your patch even bigger until it's again using 110% and crashes because of 'bugs'. What I mean is that Pd has only two threads and so can't get any faster with 4 CPUs than with two. Furthermore, if the slowdown is concentrated in one thread, it doesn't get any faster with 4 CPUs than with _one_. This 1/4 ratio is where I took the 75% in my example. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
On Wed, 2 Dec 2009, cyrille henry wrote: i made some patch that use 98454 abstractions. it certainly is very long to load, and almost impossible to save. What can make any patch longer to save than to load? I'd like to know. Normally, using abstractions makes it much longer to load a patch than to save it. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
On Wed, 2 Dec 2009, Hans-Christoph Steiner wrote: As for shortening load times, Claude wrote code for caching abstractions which dramatically speeds things up, that would be nice to have, but it is also tricky to do. What's more important, faster load times or less bugs? That's my concern. What are the bugs in Claude's code? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] noteout issue
the way i understood midi, is that you can't have to events going on at the same time, since it is a stream, i might be wrong though. maybe the windows version of noteout (or the windows midi driver) does some ordering, that the linux one doesn't. if you add a delay 1 object to one of the messages, that should solve the problem without audible differences. hope this helps simon On Wed, 2009-12-02 at 18:58 +, Silvio Almeida wrote: Hi list, Probably not a 'pure' puredata issue but: [bang( | \ [36 100( [40 100( | / | / (both to inlet one) [noteout 10] triggers : - only one of the two notes (Linux Debian 5/Ubuntu 9.10) - two notes simultaneasly (Windows XP) i suspect it is something on the midi settings of alsa or something. thanks in advance. Sílvio Almeida __ Mantenha os seus amigos actualizados - mesmo quando não tem sessão iniciada. ___ 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] Very large patches unstable?
Mathieu Bouchard a écrit : On Wed, 2 Dec 2009, cyrille henry wrote: i made some patch that use 98454 abstractions. it certainly is very long to load, and almost impossible to save. What can make any patch longer to save than to load? I'd like to know. Normally, using abstractions makes it much longer to load a patch than to save it. in the patch i made that use so many abstraction, i have : abstraction_1 that have about 10 abstraction_2 inside. abstraction_2 use about 10 abstraction_3 ... abstraction_5 use about 10 abstraction_6 if you save abstraction_2, then pd will have to reload all abstraction_2 this is lot's longer than loading the patch. anyway, in order to reload abstractions, pd have to remove the old and create a new. this is longer than only create a new. Cyrille _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ 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] Very large patches unstable?
Mathieu Bouchard escribió: In some cases some developer (I won't tell the name, but it's someone very important here) was able to find specific bugs and fixed it and published a new release. I think it's more constructive to say who fixed bugs, even if it's someone who wrote the bugs in the first place. We shouldn't have a culture in which bugs are that much shameful, Wait wait wait, i'm SORRY for the terrible MISUNDERSTANDING here - well i'd rather call it MISEXPLAINING to place the blame on the right place, which is on me. The reason why I didn't tell the name wasn't ABSOLUTELY that. That possibility didn't even come up to my mind, and no, I don't consider bugs a shameful thing, not only that much but not even a bit. Also, the part of not telling the name was a kind of a joke since I _thought_ it was clear I was talking about Miller. I didn't want to tell the name (facetiously) in order to avoid setting a precedent so that every user would start sending Miller crashing patches and expect bug fixes for the next day. When Miller wrote me (publicly in this m/l) to send him a crashing patch (in reply to a message of mine about some bug), he started the message with It's a dangerous thing to offer, but -- 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] pureKONTROL
hi list, pureKONTROL is a simple patch that I wrote in order to convert MIDI signal from a nanoKontrol controller to OSC message. It has a fashion GUI but maybe use it in -nogui mode is more appropriate (read it fast) ;) you can read more and download it from: http://www.estereotips.net/?page_id=482lang=en cheers husk -- If identity in the Post-modernism is nothing you can call me a RadikalTeknoFreak Hartivist www.estereotips.net qeve.estereotips.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
--- On Wed, 12/2/09, cyrille henry c...@chnry.net wrote: From: cyrille henry c...@chnry.net Subject: Re: [PD] Very large patches unstable? To: Mathieu Bouchard ma...@artengine.ca Cc: PD-List pd-list@iem.at Date: Wednesday, December 2, 2009, 9:36 PM Mathieu Bouchard a écrit : On Wed, 2 Dec 2009, cyrille henry wrote: i made some patch that use 98454 abstractions. it certainly is very long to load, and almost impossible to save. What can make any patch longer to save than to load? I'd like to know. Normally, using abstractions makes it much longer to load a patch than to save it. in the patch i made that use so many abstraction, i have : abstraction_1 that have about 10 abstraction_2 inside. abstraction_2 use about 10 abstraction_3 ... abstraction_5 use about 10 abstraction_6 if you save abstraction_2, then pd will have to reload all abstraction_2 this is lot's longer than loading the patch. anyway, in order to reload abstractions, pd have to remove the old and create a new. this is longer than only create a new. But saving the parent patch that holds all of these abstractions should take very little time. I thought that's what you were talking about. -Jonathan Cyrille _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ 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] Very large patches unstable?
On Wed, 2 Dec 2009, Matteo Sisti Sette wrote: Well, I admit I don't know the answers; in a commercial software scenario it is easier, because you are paid to develop the software, and I [am supposed to] pay to use it, so asking to fix things is a right for me, and fixing things is a due for you. It's not that easy with commercial software either. Naturally, it depends on the specific company and product. But chances are that if you just found a rare-enough bug (difficult to come across), then for the company it might make more business sense to take the time that could be spent on your bug and instead allocate this effort on increasing the deliberate vendor lock-in, even considering the impact on their own reputation. Companies may decide to fix the bug anyway, and in that case, consider yourself lucky. This is not the case with FLOSS and I don't really know what is the motivation for the developer to, well, develop. That's great of you: some people would instead claim that they know, and then when they see real behaviour of FLOSS authors they'd call it illogical or paradoxical. Those people don't know that they don't know, whereas you, you don't claim to know. And frankly, no-one can find all of the reasons. but assuming you are interested for some reason in developing the software and you are doing it, what kind of contribution can I give as a user? The answer is feedback, and feedback consists, among other things, in DEMANDS. There's this major difference between «demand» in English and «demande» in French, such that both of those words get translated to a completely different-looking word in the other language. I believe you are meaning to say «demande» as in French, because «demand» in English is more like an order for something that MUST be done. The invisible walls of language are worsened by the fact that people do as if they can always rely on nonverbal cues, even when they read pure text. Well yes, I agree with that, or I understand that. Does that mean that we should be happy with the presence of bugs? Seems like you're saying: What do you prefer, a boring, simple, limited but rock-solid software, or a powerful, flexible [whatever positive adjective you may want to add here] but buggy one? Depends on which bugs. Bugs have different priorities. Different people put different priorities on bugs. It is not a finished product (if such a thing even exists). Miller Puckette opened the 2007 convention by saying that PureData is almost finished. What are the weak points of PD (don't be afraid, I won't try to list them)? Well, to make an example everybody knows the graphical interface is tremendously slow. That is well known; I don't know how much priority the developer community give to that problem (quite low I guess), but the problem is well known, so there is no need to discuss about it. At the time of the 2007 convention I worked a bit on accelerating TkCanvas. I mentioned it on the pd-list but got no replies. I don't recall anyone else suggesting that as a solution. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
On Wed, 2 Dec 2009, Jonathan Wilkes wrote: On Wed, 12/2/09, cyrille henry c...@chnry.net wrote: anyway, in order to reload abstractions, pd have to remove the old and create a new. this is longer than only create a new. But saving the parent patch that holds all of these abstractions should take very little time. I thought that's what you were talking about. That's also what I thought it was. Cyrille only mentioned saving a patch containing over 6 abstraction instances, not saving an abstraction that has to be reloaded. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pureKONTROL
This looks cool and launches fine on win 7 x64. Don't have my nanoKontrol plugged in yet to test further, but thanks for sharing! -j On Wed, Dec 2, 2009 at 1:00 PM, Husk 00 hus...@gmail.com wrote: hi list, pureKONTROL is a simple patch that I wrote in order to convert MIDI signal from a nanoKontrol controller to OSC message. It has a fashion GUI but maybe use it in -nogui mode is more appropriate (read it fast) ;) you can read more and download it from: http://www.estereotips.net/?page_id=482lang=en cheers husk -- If identity in the Post-modernism is nothing you can call me a RadikalTeknoFreak Hartivist www.estereotips.net qeve.estereotips.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
On Wed, 2 Dec 2009, Hans-Christoph Steiner wrote: Here's a friendly suggestion, instead of spending time writing giant emails, spend that time trying to isolate the bugs that you are complaining about. One is lost in the code, and you tell him that the solution is to spend more time running around in no particular direction. Here's a friendly suggestion : stop replying to mails that you don't read and don't care about. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
Mathieu Bouchard escribió: It's not that easy with commercial software either. [...] Well I was just implying that with commercial software I feel the RIGHT to complain about bugs and EXPECT (in the sense of demand in english, lol, not of real expectation) them to be fixed, because software is the only field where you BUY something that does not work and are even supposed to accept that, which I don't. I didn't imply that companies will do what I would expect them to do according to what I think is their moral duty. Indeed business strategy will usually push them to the exactly opposite direction. They will wait for the next majour release to fix bugs, so that you pay again for something you have already bought. That's why I think nobody should ever pay for software. Well, I would indeed be happy to pay for software if it was bug free, but if I take for true what seems to be an almost universally shared opinion, that bug free software does not and won't ever exist, then I must conclude, that nobody should pay for software. There's this major difference between «demand» in English and «demande» in French, [..] I believe you are meaning to say «demande» as in French, because «demand» in English is more like an order for something that MUST be done. Oh... I don't speak a word of French, so I'm not sure, you may be right. I meant (and understood) demand more or less as asking someone to do something, not necessarily in an imperative way. Miller Puckette opened the 2007 convention by saying that PureData is almost finished. Hahahahahahha, yes, I remember that was mentioned in the mailing list. But even if I don't know Miller at all, I had seen his performance in Barcelona at OFF ICMC 2006 so I already knew he has a great sense of humor. -- 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] noteout issue
Well, rough and ready answer to this might just be putting [del 1] between one of them and the noteout, you're unlikely to notice the millisecond difference. Or, even better, [del 0.5] [del 0.01]? From: wavfr...@hotmail.com To: pd-list@iem.at Date: Wed, 2 Dec 2009 18:58:43 + Subject: [PD] noteout issue Hi list, Probably not a 'pure' puredata issue but: [bang( | \ [36 100( [40 100( | / | / (both to inlet one) [noteout 10] triggers : - only one of the two notes (Linux Debian 5/Ubuntu 9.10) - two notes simultaneasly (Windows XP) i suspect it is something on the midi settings of alsa or something. thanks in advance. Sílvio Almeida Mantenha os seus amigos actualizados - mesmo quando não tem sessão iniciada. _ Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy http://clk.atdmt.com/UKM/go/186394592/direct/01/___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
Matteo Sisti Sette wrote: I meant (and understood) demand more or less as asking someone to do something, not necessarily in an imperative way. Demand is a strong word. It implies such position of power that you have a right to make a demand. Free software is such a gift that developers have more place to demand that you learn to code C and fix the bug yourself or contribute better documentation, than you have to demand they improve the software. Or you could always make a financial agreement, and offer money, and demand in return that they fix the software in the way you wish. Ardour, for example, has worked well with this micro-sponsored open source development model. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
On Wed, 2 Dec 2009, Matteo Sisti Sette wrote: Well I was just implying that with commercial software I feel the RIGHT to complain about bugs and EXPECT (in the sense of demand in english, lol, not of real expectation) them to be fixed, because software is the only field where you BUY something that does not work and are even supposed to accept that, which I don't. That's because software is the only field in which new developments are called maintenance. It's also the only field in which the only thing you ever do is plan (a computer programme is a plan). It's also the only field in which the cost of repairing a mistake is that much low. Therefore the market expands to handle the biggest plans that human minds can possibly handle, as there aren't so many consequences to making a mistake here and there. I didn't imply that companies will do what I would expect them to do according to what I think is their moral duty. I think that their first moral duty is to express all of the disclaimers that they mean, before you buy. All of the rest is optional. but if I take for true what seems to be an almost universally shared opinion, that bug free software does not and won't ever exist, I believe that bug-free software is possible. I also believe that it is not a very interesting fact, because all it focuses on are all-or-nothing things: no bug vs any number of any bugs. Basically any other fact about bugs is more important than that. Before facts, though, you need definitions and agreements. A «bug» in the «bug tracker» is somewhat likely to not be one. Bugs are only relative to a statement of what the programme should do. Oh... I don't speak a word of French, so I'm not sure, you may be right. I meant (and understood) demand more or less as asking someone to do something, not necessarily in an imperative way. I guessed that if you made the mistake I thought you had made, then it must be having some kind of link with the same mistake in French. Miller Puckette opened the 2007 convention by saying that PureData is almost finished. Hahahahahahha, yes, I remember that was mentioned in the mailing list. But even if I don't know Miller at all, I had seen his performance in Barcelona at OFF ICMC 2006 so I already knew he has a great sense of humor. I already had read Miller's posts for five years when I attended that keynote. When he said it, it didn't cross my mind for a second that it could be a joke. Instead I firmly believed that he was being serious. I haven't changed my position since, I won't reconsider it, and I'd like you to reconsider yours. Yes, I've seen Miller perform a few times, but it's really unrelated. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
On Wed, 2 Dec 2009, Matteo Sisti Sette wrote: Wait wait wait, i'm SORRY for the terrible MISUNDERSTANDING here - well i'd rather call it MISEXPLAINING to place the blame on the right place, which is on me. That's what the problem is. I want you to put the blame on a piece of code, not on any person, even you. Also, the part of not telling the name was a kind of a joke since I _thought_ it was clear I was talking about Miller. We have no idea. We still have no info about your bug about big patches, except that it's about big patches and that it frustrates you. The bug could be involving anyone else's GUI classes, but how would we know? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
Justin Glenn Smith escribió: Matteo Sisti Sette wrote: I meant (and understood) demand more or less as asking someone to do something, not necessarily in an imperative way. Demand is a strong word. It implies such position of power that you have a right to make a demand. Ok then I used the wrong word and apologize for that. I meant something more like requirement. About not having the right to state the requirement I already explained myself. -- 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] Very large patches unstable?
On Dec 2, 2009, at 3:25 PM, Mathieu Bouchard wrote: On Wed, 2 Dec 2009, Hans-Christoph Steiner wrote: As for shortening load times, Claude wrote code for caching abstractions which dramatically speeds things up, that would be nice to have, but it is also tricky to do. What's more important, faster load times or less bugs? That's my concern. What are the bugs in Claude's code? I don't know if there are any. I am just saying new code has new bugs. Plus I think caching is tricky to nail down. .hc Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
Mathieu Bouchard escribió: Also, the part of not telling the name was a kind of a joke since I _thought_ it was clear I was talking about Miller. We have no idea. We still have no info about your bug about big patches, except that it's about big patches and that it frustrates you. Errr You are confusing me. No, right now I am not working on any big patch and I am not experimenting any frustrating bug. ( Well, actually, right now I am working with GEM and even with a dozen of objects I experiment some sudden crashes every now and then which have brought me to the point that I now hit CTRL+S without even realising. But that's almost surely GEM, and I won't even care until I test it on the target machine which is a mac (me on windows now) with dunnow-which version of Extended (me using vanilla + the last gem). ) The one that was reporting a specific problem was the guy who started the thread; I was just speaking in general terms. I had some problems with huge patches in the past; I usually had strict deadlines so I had to go on with whatever workaround saved the show. When I mentioned the fact that Miller fixed some bug I reported, it was not supposed to matter what bug since it is now fixed... Wait wait wait, i'm SORRY for the terrible MISUNDERSTANDING here - well i'd rather call it MISEXPLAINING to place the blame on the right place, which is on me. That's what the problem is. I want you to put the blame on a piece of code, not on any person, even you. E. no, I meant the blame about the misunderstanding: I don't like the word misunderstanding because it seems to blame the person who misunderstood, while the responsible may perfectly be the person who didn't explain clearly. -- 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] Very large patches unstable?
Mathieu Bouchard escribió: I already had read Miller's posts for five years when I attended that keynote. When he said it, it didn't cross my mind for a second that it could be a joke. Instead I firmly believed that he was being serious. I haven't changed my position since, I won't reconsider it, and I'd like you to reconsider yours. I was just kidding. I hope I didn't offend anybody. -- 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] Very large patches unstable?
--- On Wed, 12/2/09, Matteo Sisti Sette matteosistise...@gmail.com wrote: From: Matteo Sisti Sette matteosistise...@gmail.com Subject: Re: [PD] Very large patches unstable? To: Mathieu Bouchard ma...@artengine.ca Cc: pd-list@iem.at Date: Wednesday, December 2, 2009, 11:01 PM Mathieu Bouchard escribió: It's not that easy with commercial software either. [...] Well I was just implying that with commercial software I feel the RIGHT to complain about bugs and EXPECT (in the sense of demand in english, lol, not of real expectation) them to be fixed, because software is the only field where you BUY something that does not work and are even supposed to accept that, which I don't. I didn't imply that companies will do what I would expect them to do according to what I think is their moral duty. Indeed business strategy will usually push them to the exactly opposite direction. They will wait for the next majour release to fix bugs, so that you pay again for something you have already bought. That's why I think nobody should ever pay for software. Well, I would indeed be happy to pay for software if it was bug free, but if I take for true what seems to be an almost universally shared opinion, that bug free software does not and won't ever exist, then I must conclude, that nobody should pay for software. Do you mean to say that nobody should pay for _proprietary_ software? Otherwise, I don't understand how your conclusion follows from your argument, because free software has no obligation to follow the business model you describe (well, neither does proprietary software, for that matter). Besides, how is it that existence of bug = the software doesn't work? Buggs can exist without makking software inoperable, you konw. -Joanthan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Very large patches unstable?
Jonathan Wilkes escribió: [...] then I must conclude, that nobody should pay for software. Do you mean to say that nobody should pay for _proprietary_ software? You're right, I meant: nobody should be charged for using software Now you can put or not the word proprietary and it makes no difference, since nobody can be charged for using FLOS software. Besides, how is it that existence of bug = the software doesn't work? Buggs can exist without makking software inoperable, you konw. Well, exagerating on purpose, I said doesn't work not to mean is inoperable but rather doesn't work 100% as expected. Even if this is very questionable, it was in relation to the comparison with hardware commercial products, where usually even small defects give you the right to have the product replaced. -- 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] Very large patches unstable?
--- On Thu, 12/3/09, Matteo Sisti Sette matteosistise...@gmail.com wrote: From: Matteo Sisti Sette matteosistise...@gmail.com Subject: Re: [PD] Very large patches unstable? To: Jonathan Wilkes jancs...@yahoo.com Cc: Mathieu Bouchard ma...@artengine.ca, pd-list@iem.at Date: Thursday, December 3, 2009, 3:41 AM Jonathan Wilkes escribió: [...] then I must conclude, that nobody should pay for software. Do you mean to say that nobody should pay for _proprietary_ software? You're right, I meant: nobody should be charged for using software Now you can put or not the word proprietary and it makes no difference, since nobody can be charged for using FLOS software. That's not true: http://www.gnu.org/philosophy/selling.html Besides, how is it that existence of bug = the software doesn't work? Buggs can exist without makking software inoperable, you konw. Well, exagerating on purpose, I said doesn't work not to mean is inoperable but rather doesn't work 100% as expected. Even if this is very questionable, it was in relation to the comparison with hardware commercial products, where usually even small defects give you the right to have the product replaced. But in the hardware example, you're paying money for a product, and (at least in the U.S.) I think your demands to have the product replaced that you are speaking of stem from the Uniform Commerce Code. That's a demand in the true sense. With the free software examples we're talking about, you're not paying a fee to download and use the software. There's certainly still a code by which people work and interact, but it's much more elusive and far from uniform. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd lcd display wavetable?
obama... bump. On Sun, Nov 29, 2009 at 10:57 AM, tdrecordable gateswideo...@gmail.comwrote: hey all Anyone know where i could start looking if i wanted to dump a wave table to be seen on a onto small lcd display. eg http://www.spikenzielabs.com/SpikenzieLabs/LCD_How_To.html i'm a total noob at electronics but interested in figuring it out. t ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd lcd display wavetable?
tdrecordable wrote: obama... bump. On Sun, Nov 29, 2009 at 10:57 AM, tdrecordable gateswideo...@gmail.comwrote: hey all Anyone know where i could start looking if i wanted to dump a wave table to be seen on a onto small lcd display. eg http://www.spikenzielabs.com/SpikenzieLabs/LCD_How_To.html For starters, you would want to use the comport object on the pd side. When it comes to building the circuitry between the serial port or usb port on your computer and the LCD screen, check out if there is a http://dorkbot.org/ dorkbot group in your area, I am sure someone there could help you. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd lcd display wavetable?
also check this website. You could check also the arduino site if you want to go into electronics. PD and arduino are friendly :) 2009/12/3 Justin Glenn Smith noisesm...@gmail.com tdrecordable wrote: obama... bump. On Sun, Nov 29, 2009 at 10:57 AM, tdrecordable gateswideo...@gmail.com wrote: hey all Anyone know where i could start looking if i wanted to dump a wave table to be seen on a onto small lcd display. eg http://www.spikenzielabs.com/SpikenzieLabs/LCD_How_To.html For starters, you would want to use the comport object on the pd side. When it comes to building the circuitry between the serial port or usb port on your computer and the LCD screen, check out if there is a http://dorkbot.org/ dorkbot group in your area, I am sure someone there could help you. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Fagote / Contrafagote Bassoon / Contra-bassoon http://myspace.com/ricardolameiro ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd lcd display wavetable?
sorry, forgot to post the site http://lcdsmartie.sourceforge.net/ here it is 2009/12/3 Ricardo Lameiro ricardolame...@gmail.com also check this website. You could check also the arduino site if you want to go into electronics. PD and arduino are friendly :) 2009/12/3 Justin Glenn Smith noisesm...@gmail.com tdrecordable wrote: obama... bump. On Sun, Nov 29, 2009 at 10:57 AM, tdrecordable gateswideo...@gmail.com wrote: hey all Anyone know where i could start looking if i wanted to dump a wave table to be seen on a onto small lcd display. eg http://www.spikenzielabs.com/SpikenzieLabs/LCD_How_To.html For starters, you would want to use the comport object on the pd side. When it comes to building the circuitry between the serial port or usb port on your computer and the LCD screen, check out if there is a http://dorkbot.org/ dorkbot group in your area, I am sure someone there could help you. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Fagote / Contrafagote Bassoon / Contra-bassoon http://myspace.com/ricardolameiro -- Fagote / Contrafagote Bassoon / Contra-bassoon http://myspace.com/ricardolameiro ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
