Re: [PD] variable receive objects?
- Original Message - > From: yvan volochine > To: pd-list > Cc: > Sent: Saturday, May 12, 2012 8:17 PM > Subject: Re: [PD] variable receive objects? > > On 05/12/2012 10:29 PM, Jonathan Wilkes wrote: >> However, there comes a point when making a serious user interface that >> wires start to get in the way, esp. on some of the more complex interfaces > people >> have made in Pd for sequencing, real-time performance, etc. I'd say at > the level >> where the author is designing for user's who don't necessarily need > to know the ins >> and outs of Pd's dataflow paradigm, wires become a hindrance. >> >> Of course that doesn't mean one can't do normal Pd patching using > only GUI objects. > > just to add my 2 cents.. > if a patch needs a GUI, I really like when its top-level canvas contain only > the > GUI and only patchers (read: *no wires* when opening the patch) > > using GUI send|receive instead of wires is a very good idea. > it also encourage putting things where they should be, i.e. separate the > logic > from the GUI (à la maxmsp 'presentation mode'). > > then somewhere in your subpatches: > [s GUI-to-vol] [r GUI-from-vol] [s GUI-to-mute] etc.. > > much cleaner IMHO > > or even better, only: > [pd init] > [pd audio] > [pd GUI] > on the top-level and some key triggers opening [pd GUI] > > BTW I'd _love_ to be able to do that: > [hslider sendSymbol receiveSymbol] Supercollider-style any-order keyword args would be nice. -Jonathan > > now that would save some time :) > > cheers, > y > > -- > yvan.voloch...@gmail.com > http://yvanvolochine.com > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
On 05/12/2012 10:29 PM, Jonathan Wilkes wrote: However, there comes a point when making a serious user interface that wires start to get in the way, esp. on some of the more complex interfaces people have made in Pd for sequencing, real-time performance, etc. I'd say at the level where the author is designing for user's who don't necessarily need to know the ins and outs of Pd's dataflow paradigm, wires become a hindrance. Of course that doesn't mean one can't do normal Pd patching using only GUI objects. just to add my 2 cents.. if a patch needs a GUI, I really like when its top-level canvas contain only the GUI and only patchers (read: *no wires* when opening the patch) using GUI send|receive instead of wires is a very good idea. it also encourage putting things where they should be, i.e. separate the logic from the GUI (à la maxmsp 'presentation mode'). then somewhere in your subpatches: [s GUI-to-vol] [r GUI-from-vol] [s GUI-to-mute] etc.. much cleaner IMHO or even better, only: [pd init] [pd audio] [pd GUI] on the top-level and some key triggers opening [pd GUI] BTW I'd _love_ to be able to do that: [hslider sendSymbol receiveSymbol] now that would save some time :) cheers, y -- yvan.voloch...@gmail.com http://yvanvolochine.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
- Original Message - > From: Frank Barknecht > To: pd-list@iem.at > Cc: > Sent: Saturday, May 12, 2012 2:23 PM > Subject: Re: [PD] variable receive objects? > > Hi Jörn, > > On Sat, May 12, 2012 at 01:20:45PM +0200, Jörn Nettingsmeier wrote: >> is there a way to generate a variable receive object similar to a send >> via message box, whose source is defined at load time? > > Attached is a common idiom that can be used in this kind of situation. It > basically works by using one single global send/receive name for everything, > thereby reducing the risk of nameclashes. That actually increases the risk of name clashes, as any other set of abstractions using this common idiom will leak data to the other set. > You could pass $0 as argument to both > abstraction to make it a bit local or better yet: Use [inlet]s to make it as > local as it gets in Pd. Inlets rock! I agree about the inlets. I find that people are too quick to make a lot of things nonlocal when they start working with gop gui abstractions. However, there comes a point when making a serious user interface that wires start to get in the way, esp. on some of the more complex interfaces people have made in Pd for sequencing, real-time performance, etc. I'd say at the level where the author is designing for user's who don't necessarily need to know the ins and outs of Pd's dataflow paradigm, wires become a hindrance. Of course that doesn't mean one can't do normal Pd patching using only GUI objects. I think Ivica is doing this with a special version of Pd with a limited set of user-friendly GUI objects-- there, it's still important to use wires to show the path the signal takes. (Just like in a DAW the user wants to know the order in which the signal gets processed by a series of filters.) -Jonathan > > Then each message you pass along gets prefixed by a certain tag (a number > "id" > in the example) in the sender and routed accordingly at the receive side. > This basically moves the actual receive name into the message you send. > > The example requires Pd 0.43 with settable [route] objects, but it's > possible > to clone a settable route with [select], check out the sroute.pd example in > the > [list]-abs collection. > > 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] variable receive objects?
Hi Jörn, On Sat, May 12, 2012 at 01:20:45PM +0200, Jörn Nettingsmeier wrote: > is there a way to generate a variable receive object similar to a send > via message box, whose source is defined at load time? Attached is a common idiom that can be used in this kind of situation. It basically works by using one single global send/receive name for everything, thereby reducing the risk of nameclashes. You could pass $0 as argument to both abstraction to make it a bit local or better yet: Use [inlet]s to make it as local as it gets in Pd. Inlets rock! Then each message you pass along gets prefixed by a certain tag (a number "id" in the example) in the sender and routed accordingly at the receive side. This basically moves the actual receive name into the message you send. The example requires Pd 0.43 with settable [route] objects, but it's possible to clone a settable route with [select], check out the sroute.pd example in the [list]-abs collection. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ rs-set.pd Description: application/puredata r-set.pd Description: application/puredata s-set.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
- Original Message - > From: Claude Heiland-Allen > To: pd-list@iem.at > Cc: > Sent: Saturday, May 12, 2012 8:16 AM > Subject: Re: [PD] variable receive objects? > > On 12/05/12 12:20, Jörn Nettingsmeier wrote: > [snip] >> is there a way to generate a variable receive object similar to a send >> via message box, whose source is defined at load time? > [snip] >> or maybe i'm totally up the wrong alley, and someone can suggest a more >> idiomatic way to deal with this issue? > > I think more idiomatic is identifier flow from outside in (rather than trying > to > get the insides out). > > Use $1 in the player and the controller, instead of their own local $0. > > Pass the same value in as the player and controller(s) arguments. > > Possibly passing in something based on the local $0 of their common parent > patch > if they have one, otherwise pick a magic name that is hopefully unique enough. > > I find it quite common to add layers of $ when nesting abstractions, perhaps > with a pattern similar to: > #1 Quick: Someone other than Claude: how long does it take you to figure out what gets printed? > patch: [nbx]--[s $0-r] [foo $0] [r $0-s]--[print] > foo: [r $1-r]--[s $0-$1-r] [bar $0-$1] [r $0-$1-s]--[s $1-s] > bar: [r $1-r]--[s $0-$1-r] [baz $0-$1] [r $0-$1-s]--[s $1-s] > baz: [r $1-r]--[+ 1]--[s $1-s] Note: my [to]/[from] wrappers take a numeric arg to specify parent level. #2 Quick: Someone other than me: how long does it take you to figure out what gets printed? patch: [nbx]--[to r] [foo] [from s]--[print] foo: [bar] bar: [baz] baz: [from r 3]-[+ 1]--[to s 3] -Jonathan > > > Claude > > ___ > 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] variable receive objects?
- Original Message - > From: Marian Weger > To: pd-list@iem.at > Cc: > Sent: Saturday, May 12, 2012 8:09 AM > Subject: Re: [PD] variable receive objects? > > hi! > >> is there a way to generate a variable receive object similar to a send via > message box, whose source is defined at load time? > > use iem_receive / iem_r from iemlib. Wow, that is classic Pd development style-- add a tiny feature to an object, but don't actually improve _that_ object. No, rewrite the entire class, prefix the original class name with something else, and add it to the growing pile of externals that duplicate the function of an internal while adding a tiny feature. I'm not making fun of that decision-- I've certainly used that method to improve the help docs. It's just such a huge waste of time and effort-- I bet Pd-extended includes within itself at least 3 forks of Pd. -Jonathan > > cheers, > marian > > ___ > 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] variable receive objects?
- Original Message - > From: Jörn Nettingsmeier > To: pd-list@iem.at > Cc: > Sent: Saturday, May 12, 2012 7:20 AM > Subject: [PD] variable receive objects? > > hi *! > > > i'm playing around with a theatre cue player written around readanysf, which > i will post on the web as soon as i'm sure it's not going to be too > embarrassing - need to pick up some more pd idioms first... > > > so far, i've been able to create a nice gui using graph-on-parent, and all > gui events are messages sent to receive objects, internally. for instance, > hitting the "play" bang button will send the bang to > cfPlayer$0SetPlay. > > the idea is that everybody can grab this event, not just the readanysf~ > object. > > now i've painted myself into a corner: i want to create a midi controller > abstraction which is separate from the player and gui. > > to that end, i have added an outlet to my player that contains the player's > unique id $0. this outlet is connected to the controller object, which can > now > happily send messages back to the player, using message boxes: > > |inlet| <-- gets the parent player's $0 ID > |set $1( > | ( > |; cfPlayer$1SetPlay bang( > > that gives me nice separation. the problem is that i want the controller > object > to be able to _listen_ to player events as well as generate them, so that the > midi controller always reflects the current state, even if it was initiated > elsewhere, such as via the gui or by loading a playlist item. > > is there a way to generate a variable receive object similar to a send via > message box, whose source is defined at load time? > something like this: > |inlet| <-- gets the parent player's $0 ID > |set $1( > | ( > |receive cfPlayer$1GetPlay( [inlet] | [list append $0 | [clear, obj 20 20 receive cfPlayer$1GetPlay, obj 20 80 send $2-out, connect 0 0 1 0( | [s pd-$0-dynamic-subpatch] [pd $0-dynamic-subpatch] [r $0-out] | [outlet] <-- all messages to cfPlayer$1GetPlay will go here > > which, of course, doesn't work. > > > or maybe i'm totally up the wrong alley, and someone can suggest a more > idiomatic way to deal with this issue? There isn't because Pd sucks at specifying scope for the symbol name associated with an object. Thus you are sending messages through wires so that your abstractions can build their own notion of "library" level scope. I made a source code patch that would make stuff like this easier. Instead of passing around $0 among the abstractions of a library, I made a [to]/[from] wrapper around [s]/[r] that takes an additional argument to specify the scope. I'm still figuring out what the best interface is, but for the purposes of this thread let's say "library" scope is specified by adding the argument "mylib" after the send name. This scope is shared among all the abstractions that are located in the same directory. That means you can just do this: | [to GetPlay mylib] The [to] object does this: 1. prefixes "GetPlay" with the path of the abstraction's directory (using my patch to the source) 2. possibly prefixes that with "__" or something (not sure if that's necessary) 3. sets an internal [s] object with that send-symbol [from GetPlay mylib] does similarly, and at the end creates a [r] object with that same symbol as an arg. Thus you can send and receive messages without wires to any of the abstractions in your library, without using $0, and with a very low likelihood of running into namespace clashes (since it is unlikely that a [s] or [r] in some other random abstraction or patch will be using a receive name prefixed with the path of your library.) The other nice thing about the [to]/[from] wrapper is that it defaults to canvas-local scope-- that is, if you just want [s $0-foo] you type [to foo], which 95% of the time is what you want anyway (look at how many of Miller's help patches have a "Put" menu array named "array1"!) It's trivial to wrap [s~]/[r~], [throw~]/[catch~], and any others that I'm missing. Drawback is this doesn't jibe with message box nonlocal sends which are inescapably global in scope, nor with the iemguis (which could easily have a dialog option added to define scope), nor garrays (which could, too, except that there are tons of internals/externals that specify array name with a single symbolic arg, so to be consistent with this interface you'd have to set the array symbol with a message, and now we're back to the same ugliness of sending a $0 to a message box...). -Jonathan > > what i want is this: > > player doesn't know or care who's controlling it. > > controller can (and does) have knowledge of the player event model. > > this way, i can easily add OSC or playlist controllers later, keeping the > main > player nice and simple. > > best, > > > jörn > > > -- Jörn Nettingsmeier > Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 > > Meister für Veranstaltungstechnik (Bühne/Studio) > Tonmeister VDT > > http://stac
Re: [PD] variable receive objects?
On 12/05/12 12:20, Jörn Nettingsmeier wrote: [snip] is there a way to generate a variable receive object similar to a send via message box, whose source is defined at load time? [snip] or maybe i'm totally up the wrong alley, and someone can suggest a more idiomatic way to deal with this issue? I think more idiomatic is identifier flow from outside in (rather than trying to get the insides out). Use $1 in the player and the controller, instead of their own local $0. Pass the same value in as the player and controller(s) arguments. Possibly passing in something based on the local $0 of their common parent patch if they have one, otherwise pick a magic name that is hopefully unique enough. I find it quite common to add layers of $ when nesting abstractions, perhaps with a pattern similar to: patch:[nbx]--[s $0-r] [foo $0] [r $0-s]--[print] foo: [r $1-r]--[s $0-$1-r] [bar $0-$1] [r $0-$1-s]--[s $1-s] bar: [r $1-r]--[s $0-$1-r] [baz $0-$1] [r $0-$1-s]--[s $1-s] baz: [r $1-r]--[+ 1]--[s $1-s] Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
hi! is there a way to generate a variable receive object similar to a send via message box, whose source is defined at load time? use iem_receive / iem_r from iemlib. cheers, marian ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] variable receive objects?
hi *! i'm playing around with a theatre cue player written around readanysf, which i will post on the web as soon as i'm sure it's not going to be too embarrassing - need to pick up some more pd idioms first... so far, i've been able to create a nice gui using graph-on-parent, and all gui events are messages sent to receive objects, internally. for instance, hitting the "play" bang button will send the bang to cfPlayer$0SetPlay. the idea is that everybody can grab this event, not just the readanysf~ object. now i've painted myself into a corner: i want to create a midi controller abstraction which is separate from the player and gui. to that end, i have added an outlet to my player that contains the player's unique id $0. this outlet is connected to the controller object, which can now happily send messages back to the player, using message boxes: |inlet| <-- gets the parent player's $0 ID |set $1( | ( |; cfPlayer$1SetPlay bang( that gives me nice separation. the problem is that i want the controller object to be able to _listen_ to player events as well as generate them, so that the midi controller always reflects the current state, even if it was initiated elsewhere, such as via the gui or by loading a playlist item. is there a way to generate a variable receive object similar to a send via message box, whose source is defined at load time? something like this: |inlet| <-- gets the parent player's $0 ID |set $1( | ( |receive cfPlayer$1GetPlay( which, of course, doesn't work. or maybe i'm totally up the wrong alley, and someone can suggest a more idiomatic way to deal with this issue? what i want is this: player doesn't know or care who's controlling it. controller can (and does) have knowledge of the player event model. this way, i can easily add OSC or playlist controllers later, keeping the main player nice and simple. best, jörn -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [GEM] PS3eye in Ubuntu 12.04?
hi all, does anyone have experience with the ps3eye in ubuntu using pd/gem? I am trying out ubuntu for one of my systems and have the following issue. I am able to control the frame rate, autogain and several other features of the PS3eye camera from GUVCViewer, but I cannot do it from GEM. In GEM, when I open device 0 i get: videoctl: device 0 info: proplist numread 13 info: proplist read Auto Gain float 1 info: proplist read Auto White Balance float 1 info: proplist read Brightness float 255 info: proplist read Contrast float 255 info: proplist read Exposure float 255 info: proplist read HFlip float 1 info: proplist read Light Frequency Filter float 1 info: proplist read Main Gain float 63 info: proplist read Sharpness float 63 info: proplist read VFlip float 1 info: proplist read bus_info symbol usb-:00:1d.7-5 info: proplist read card symbol USB Camera-B4.09.24.1 info: proplist read driver symbol ov534 info: proplist numwrite 10 info: proplist write Auto Gain float 1 info: proplist write Auto White Balance float 1 info: proplist write Brightness float 255 info: proplist write Contrast float 255 info: proplist write Exposure float 255 info: proplist write HFlip float 1 info: proplist write Light Frequency Filter float 1 info: proplist write Main Gain float 63 info: proplist write Sharpness float 63 info: proplist write VFlip float 1 v4l2: GEM: pix_video: Opened video connection 0xE Could anyone suggest a way of controlling the camera so that GEM can use higher frame rates? best, J -- Jaime E Oliver LR jo2...@columbia.edu www.jaimeoliver.pe 858 750 0924 (cel) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
