Re: [PD] abstraction setting its own arguments
--- On Sun, 8/1/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Sunday, August 1, 2010, 7:40 PM On Sat, 31 Jul 2010, Jonathan Wilkes wrote: * the magical [inlet] message on loadbang is weird and will cause a crash in winxp if you happen to remove the abstraction's inlet. You mean you don't get the following error message ? « error: [args hello (world a 42) *] inlet 0 method loadbang: can't send init-messages, because object has no [inlet] » * sending output from [args] on loadbang is redundant when [loadbang]-[args] is so trivial. No, it just crashes. But my bigger point is that it's really confusing behavior for messages to be coming out an inlet at loadbang time when nothing is actually connected to that inlet. Why did you choose to do that? lots of shortcuts are trivial individually, then pile up to make a difference. The problem with auto-[loadbang] in args is that [loadbang] order is a dangerous thing (which I forgot to think about when designing that part of [args]... not sure what to do with it now... a bit hard to undo). Exactly. The clean patching solution for multiple loadbangs is pretty easy: [loadbang]-[t b b b etc.] . (I actually used that even before thinking about the problem of [loadbang] order because it just seemed like a simple, readable way to do it.) Maybe you could have another object with a different name like [getargs] that doesn't do the loadbang. Is there anything [args] can currently do that wouldn't be possible by taking an anything at its inlet? What would be the meaning of that anything ? I don't know why I said anything and not list. I guess I was thinking that $@ expands to an anything and not a list (unless the first arg is a float). But as you show, it would most likely arrive at [args] as a list anyway... you mean plugging [loadbang]-[list append $...@] into it ?... maybe it would work, but it would be two more objects per abstraction, too. (and it wouldn't be a anything. why anything ?) Yes, in this case I would say list. But since I'm working on clarifying the docs... The word anything seems sometimes to be used in opposition to the list message, to refer to a multi-element message with a selector other than list (or a single-element message with selector other than bang, symbol, float, or pointer). At other times it seems to mean any message that would be accepted by the anything-method, which includes list messages as well as the other pd built-ins. (like [any], [send], [spigot], etc. ) And at further other times, it seems like it means other than x/y/z, anything, as in, other than 11 reserved selectors, you can send anything to [bng] and it will trigger a bang. Do any of these fit your definition of anything? Additionally, your method of using commas to separate named init values assumes that the pd programmer doesn't want to send commas as arguments (which I did want to do in my [expr] example). I expect to add this feature whenever someone needs it : [args *, nocommas] would consider commas as non-special. Also : [args *, nocommas, noparens] would completely disable special parsing. But it's also possible that the syntax would be : [args *, commas 0, parens 0] a 0/1 attribute specified without a value defaults to 1. I haven't really thought about a rule for what is better, negative bools (names with no in them) when they sound good (mainly for exceptional cases), or positive bools all over. So what I'm saying is that your [args] doesn't fit my needs, and $@ wouldn't fit everyone's needs, but $@ + [args] + [other_parsers_as_needed] would fit the maximum number of needs You know, passing [loadbang]-[list append $...@]-[args] isn't making [args]'s code any shorter than with an autonomous [args] as it is now. And then, for the handling of abstractions' properties dialogues, I'm going to do something rather close to a list-method for [args], without doing it : I'm going to use [setargs] just before re-banging the [args]. It's the only way I can think of using [args] with an input that is not just the original arguments of the abstraction-instance... Why are [args] and [setargs] two separate objects? without burdening the users with learning a completely different way of getting args every time they want to do something different with them. I'm all for adding $@ to pd-extended, but by itself, its inclusion in pd-extended doesn't seem like a reason to change anything in [args] at all. In any case, if you feel like $@ has to be included in pd-extended, that's something you have to talk to Hans about. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Re: [PD] CPU saving strategies
Hi, On Sun, Aug 01, 2010 at 12:35:41PM +0200, David Schaffer wrote: I recently built a midi CC sequencer abs. It helps me add some timeline-based control to my patches. But I came across a problem I never had to deal with before: CPU consumption. I realized I could'nt use more than four instances of my sequencer before the patch would become unmanageable (interface freezes, audio drops, and, finally... a crash) I think this is related to the use of large size arrays. I would be grateful if someone out there could point me to a better data storing/ CPU saving strategy for my sequencer, maybe data structures? Thanks in advance. You're using way too many debugging GUIs, like [bng] or number boxes. Remove all of them that you don't see and optionally speedlimit the updates of those, that you want to see. [m_speedlimit] from rj (http://github.com/rjdj/rjlib) can be used for speedlimiting. In general, never patch debuigging stuff like this: [...] | [0\ - a numberbox | [...] or this: [...] | [bng] - a GUI bang | [...] Instead always put the debugging GUIs into their own path like here: [...] |\ | [0\ - a numberbox | [...] This way it's easier to remove them later, when you're finished debugging your patch. Make that a habit. 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] CPU saving strategies
Thanks for your advices Franck, these are the kind of programming tips I was looking for. David http://www.flickr.com/photos/schafferdavid/ http://audioblog.arteradio.com/David_Schaffer/ Date: Mon, 2 Aug 2010 13:02:00 +0200 From: f...@footils.org To: pd-list@iem.at Subject: Re: [PD] CPU saving strategies Hi, On Sun, Aug 01, 2010 at 12:35:41PM +0200, David Schaffer wrote: I recently built a midi CC sequencer abs. It helps me add some timeline-based control to my patches. But I came across a problem I never had to deal with before: CPU consumption. I realized I could'nt use more than four instances of my sequencer before the patch would become unmanageable (interface freezes, audio drops, and, finally... a crash) I think this is related to the use of large size arrays. I would be grateful if someone out there could point me to a better data storing/ CPU saving strategy for my sequencer, maybe data structures? Thanks in advance. You're using way too many debugging GUIs, like [bng] or number boxes. Remove all of them that you don't see and optionally speedlimit the updates of those, that you want to see. [m_speedlimit] from rj (http://github.com/rjdj/rjlib) can be used for speedlimiting. In general, never patch debuigging stuff like this: [...] | [0\ - a numberbox | [...] or this: [...] | [bng] - a GUI bang | [...] Instead always put the debugging GUIs into their own path like here: [...] |\ | [0\ - a numberbox | [...] This way it's easier to remove them later, when you're finished debugging your patch. Make that a habit. Ciao -- Frank Barknecht Do You RjDj.me? _ __footils.org__ ___ 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] GEM 0.92 font support ubuntu jaunty
Thanks, Hans. I went back to that page and tried to install again all packages, but I do already have all of them, except libavcodec-dev because it has a couple of unsatisfied dependencies. mmm, anybody has an hint? cheers, M On Tue, Jul 27, 2010 at 11:35 PM, Hans-Christoph Steiner h...@at.or.atwrote: That means you probably didn't install one of the libraries, check the Debian page on the developer docs on puredata.info and try adding them all. .hc Marco Donnarumma wrote: Hi, I can't use [text2d] or 3d because GEM has been compiled without FONT support (I noticed the topic has been already discussed). I searched the archive but couldn't find anything more recent than these threads below (2006/2007). Should I compile GEM and the other stuff mentioned in those threads or the issue could be related to something different? Ubuntu Jaunt,y pd-ex 42.5 rc5 compiled manually from auto-build farm, GEM 0.92. Thanks, http://www.mail-archive.com/pd-list@iem.at/msg02272.html http://www.mail-archive.com/pd-list@iem.at/msg02593.html http://www.mail-archive.com/pd-list@iem.at/msg01148.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Marco Donnarumma aka TheSAD Independent New Media Arts Professional, Performer, Teacher - 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] GEM 0.92 font support ubuntu jaunty
On 08/02/2010 01:38 PM, Marco Donnarumma wrote: Thanks, Hans. I went back to that page and tried to install again all packages, but I do already have all of them, except libavcodec-dev because it has a couple of unsatisfied dependencies. mmm, anybody has an hint? for font support you need ftgl-dev (nowadays often called libftgl-dev) a good start on debian (and clones, like ubuntu) is to install all the build-dependencies for the regular gem package by issuing # apt-get build-dep gem (or for those feeble at heart: % sudo apt-get build-dep gem dfmas IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CPU saving strategies
updating some numberboxes shouldnt cause audio interrupts, this is really the downside of PD. Is there any hope to rectify this situation to make it behave better in low latency conditions? I know it basically mean a rewrite of the whole thing but are there any initiatives? Cheers, Malte -- media art + development http://www.block4.com new on iTunes: Notstandskomitee Automatenmusik http://itunes.apple.com/us/album/automatenmusik/id383400418 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM 0.92 font support ubuntu jaunty
Thanks IOhannes, apt-get build-dep GEM solved the problem. Just for collective info apt-get build-dep GEM prompted for the removal of Pd-extended in order to install updates. I recompiled and re-installed, everything works, although on creation of [text2d] Pd complains: [text2d]: cannot find font-file '/usr/lib/pd-extended/extra/Gem/vera.ttf' Then I need to manually open a font, and it works fine. Can I set the correct path to my fonts folder? or I had to do it beforehand... M 2010/8/2 IOhannes zmölnig zmoel...@iem.at On 08/02/2010 01:38 PM, Marco Donnarumma wrote: Thanks, Hans. I went back to that page and tried to install again all packages, but I do already have all of them, except libavcodec-dev because it has a couple of unsatisfied dependencies. mmm, anybody has an hint? for font support you need ftgl-dev (nowadays often called libftgl-dev) a good start on debian (and clones, like ubuntu) is to install all the build-dependencies for the regular gem package by issuing # apt-get build-dep gem (or for those feeble at heart: % sudo apt-get build-dep gem dfmas IOhannes -- Marco Donnarumma aka TheSAD Independent New Media Arts Professional, Performer, Teacher - 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] howto get pool
Hi,... Am Mittwoch, den 28.07.2010, 13:36 -0400 schrieb Hans-Christoph Steiner: own Pd-extended. It would be great if you could document how you did it on the pure-data wiki. You could create a new page off of this one: Done. I can expand it with setting up JACK together with Pulseaudio on Fedora 13, if someone is interested. (This setup works much better, as using padsp or pasuspender.) best regards stefan -- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CPU saving strategies
On Mon, 2 Aug 2010, Malte Steiner wrote: updating some numberboxes shouldnt cause audio interrupts, this is really the downside of PD. Is there any hope to rectify this situation to make it behave better in low latency conditions? I know it basically mean a rewrite of the whole thing but are there any initiatives? sounds like you are not using the -rt option in your startup flags ? can you get it to work ?... (you have to restart pd after you saved the settings) be careful with this feature. _ _ __ ___ _ _ _ ... | 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] abstraction setting its own arguments
On Mon, 2 Aug 2010, Jonathan Wilkes wrote: « error: [args hello (world a 42) *] inlet 0 method loadbang: can't send init-messages, because object has no [inlet] » No, it just crashes. I suppose you can also find other situations in which GF crashes instead of reporting an error message ? But my bigger point is that it's really confusing behavior for messages to be coming out an inlet at loadbang time when nothing is actually connected to that inlet. It's confusing while you don't expect it. Once it's expected, it's not any more confusing than receive-symbols hidden inside IEMGUI properties dialogues. Why did you choose to do that? Because [args] used to have a right outlet to be connected to the top left [inlet] and it would always go across the whole patch in some ugly way. I could have made it left outlet instead, but figured out that if I could save a bit of boilerplate (usually a [t a] and two more wires) in every abstraction, I'd have that much less in every abstraction, and I wouldn't have to verify all abstractions to make sure that they support the init-commas. Exactly. The clean patching solution for multiple loadbangs is pretty easy: [loadbang]-[t b b b etc.] . (I actually used that even before thinking about the problem of [loadbang] order because it just seemed like a simple, readable way to do it.) That's not the only well-ordered one : you can do clear-looking partial ordering of loadbangs by using subpatches (with nesting or not). All subpatch [loadbang]s are guaranteed to be finished before their immediate parent's [loadbang]s. Maybe you could have another object with a different name like [getargs] that doesn't do the loadbang. I may as well do search-and-replace on all of GridFlow. I shouldn't care so much about backwards-compatibility when not only other people don't contribute abstractions to GF, but also, there's no one even saying something like « I use [args] ». Then why bother. But at this point, my idea of it is to make it a comma-option in [args] : [args foo bar *, noloadbang] and then think some more before getting into anything not backwards-compatible. The word anything seems sometimes to be used in opposition to the list message, to refer to a multi-element message with a selector other than list (or a single-element message with selector other than bang, symbol, float, or pointer). bang is not a single-element message : it has no $1. At other times it seems to mean any message that would be accepted by the anything-method, which includes list messages as well as the other pd built-ins. (like [any], [send], [spigot], etc. ) What does that case exclude ?... only loadbang and dsp ? (but then, not even necessarily). And at further other times, it seems like it means other than x/y/z, anything, as in, other than 11 reserved selectors, you can send anything to [bng] and it will trigger a bang. this is why method any appears last, for a given inlet or outlet. Do any of these fit your definition of anything? No. The one I mean here is more like : if you put $@ alone in a message box, you'll get an anything in the sense that the possible values of $@ make most any message possible. This includes the case where the value of $1 is list, in which case the $1 of the output will be the $2 of the input. (In effect, this would be a shortcut of [list trim].) Whereas you get a list if you write list $@ in it because you can only make list-messages that way. Why are [args] and [setargs] two separate objects? Didn't really think about it. Any ideas ? I suppose that there would be a point soon when I will have a better idea about what to do, but I only _started_ using [setargs] very recently, so, I don't know yet. _ _ __ ___ _ _ _ ... | 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] abstraction setting its own arguments
--- On Mon, 8/2/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Monday, August 2, 2010, 6:09 PM On Mon, 2 Aug 2010, Jonathan Wilkes wrote: « error: [args hello (world a 42) *] inlet 0 method loadbang: can't send init-messages, because object has no [inlet] » No, it just crashes. I suppose you can also find other situations in which GF crashes instead of reporting an error message ? That's the only I've seen so far. I haven't used GF much yet. But my bigger point is that it's really confusing behavior for messages to be coming out an inlet at loadbang time when nothing is actually connected to that inlet. It's confusing while you don't expect it. Once it's expected, it's not any more confusing than receive-symbols hidden inside IEMGUI properties dialogues. But IEMGUI receive-symbols don't make any assumptions about whether or not there is an inlet in a particular canvas. What if the abstraction in question doesn't have any xlets, but the user wants to use key/value pairs? Actually there's a particular doc-related example I have in mind that would benefit from key/values in the args but doesn't have xlets. It might be something relevant to the GFDP, so I'll send it to you after I flesh it out. Why did you choose to do that? Because [args] used to have a right outlet to be connected to the top left [inlet] and it would always go across the whole patch in some ugly way. I could have made it left outlet instead, but figured out that if I could save a bit of boilerplate (usually a [t a] and two more wires) in every abstraction, I'd have that much less in every abstraction, and I wouldn't have to verify all abstractions to make sure that they support the init-commas. Exactly. The clean patching solution for multiple loadbangs is pretty easy: [loadbang]-[t b b b etc.] . (I actually used that even before thinking about the problem of [loadbang] order because it just seemed like a simple, readable way to do it.) That's not the only well-ordered one : you can do clear-looking partial ordering of loadbangs by using subpatches (with nesting or not). All subpatch [loadbang]s are guaranteed to be finished before their immediate parent's [loadbang]s. Maybe you could have another object with a different name like [getargs] that doesn't do the loadbang. I may as well do search-and-replace on all of GridFlow. I shouldn't care so much about backwards-compatibility when not only other people don't contribute abstractions to GF, but also, there's no one even saying something like « I use [args] ». Then why bother. But at this point, my idea of it is to make it a comma-option in [args] : [args foo bar *, noloadbang] and then think some more before getting into anything not backwards-compatible. The word anything seems sometimes to be used in opposition to the list message, to refer to a multi-element message with a selector other than list (or a single-element message with selector other than bang, symbol, float, or pointer). bang is not a single-element message : it has no $1. Right. Other messages consisting of only a selector are part of this definition, too. At other times it seems to mean any message that would be accepted by the anything-method, which includes list messages as well as the other pd built-ins. (like [any], [send], [spigot], etc. ) What does that case exclude ?... only loadbang and dsp ? (but then, not even necessarily). It includes those messages (well, maybe not dsp with signal objects-- that's special). And at further other times, it seems like it means other than x/y/z, anything, as in, other than 11 reserved selectors, you can send anything to [bng] and it will trigger a bang. this is why method any appears last, for a given inlet or outlet. Ok. I just explain it explicitly for those objects that require it. Do any of these fit your definition of anything? No. The one I mean here is more like : if you put $@ alone in a message box, you'll get an anything in the sense that the possible values of $@ make most any message possible. This includes the case where the value of $1 is list, in which case the $1 of the output will be the $2 of the input. (In effect, this would be a shortcut of [list trim].) How is your definition different than my 2nd one above? Whereas you get a list if you write list $@ in it because you can only make list-messages that way. Why are [args] and [setargs] two separate objects? Didn't really think about it. Any ideas ? An [args] that does both setting and getting would be somewhat analogous to a luxury message box. You use all the same messages to set the content, and sending a bang would output the content. The big difference I guess is that
[PD] PD NO JACK OUTPUT
I don't know if this is a problem with PD or with JACK but... I have jack 1.9.5 (package from planet-ccrma fedora 13/64bit) and PD compiled from source (miller puckette website). I compiled PD with ./configure --enable-jack=yes --enable-alsa=yes When I start JACK and then PD with pd -jack I get: jack_client_new: deprecated Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started It works OK with ALSA if I start with just pd. But nothing with JACK. Any idea what goes wrong here..? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD NO JACK OUTPUT
(yes, when I start pd jack is already running :-) 2010/8/3 Bernardo Barros bernardobarr...@gmail.com: I don't know if this is a problem with PD or with JACK but... I have jack 1.9.5 (package from planet-ccrma fedora 13/64bit) and PD compiled from source (miller puckette website). I compiled PD with ./configure --enable-jack=yes --enable-alsa=yes When I start JACK and then PD with pd -jack I get: jack_client_new: deprecated Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started It works OK with ALSA if I start with just pd. But nothing with JACK. Any idea what goes wrong here..? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
