Re: [PD] Keystone correction
hello, you have to manually adjust the position of the 4 vertices defining the corned of the primitive in order to spacially adjust them. then, you have to adjust the position of the teture in this point (it's an option that you don't really need). here it is adjusted in a neutral position. cheers Cyrille Le 27/03/2012 23:23, Charles Goyard a écrit : Hi Cyrille, Cyrille Henry wrote: you can render anything on a framebuffer, then using it as a texture to the polygon. look at gem example: Gem/examples/12.multi_screen_projection/02.nfp-help.pd it's a bit more complex than what you want to do, but you'll may find it interesting. Thanks, that's very helpful. Now I have a texture with an in-circle pix, and that texture is mapped into a polygon. However, the result is a bit weird. It looks like the point of view is rotated by 90 degrees and with a bit angled Z-axis. I don't understand the camera object. How can I get back to something more frontal ? Cheers, 02.nfp-help_flat.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keystone correction
On Tue, Mar 27, 2012 at 5:23 PM, Charles Goyard wrote: > > However, the result is a bit weird. It looks like the point of view is > rotated by 90 degrees and with a bit angled Z-axis. I don't understand > the camera object. How can I get back to something more frontal ? > I have done some extreme "keystoning" in the past using raw OpenGL in GEM (i.e. you build your polyon out of vertices) and using the combination of rotation and moving each vertex individually around. I had a quick look on my computer but cannot find the code right now but I hope that this can at least give some leads. ./MiS ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
- Original Message - > From: Ivica Ico Bukvic > To: Jonathan Wilkes ; 'Mathieu Bouchard' > > Cc: "pd-list@iem.at" > Sent: Tuesday, March 27, 2012 6:57 PM > Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now > available > > > > Jonathan Wilkes wrote: > >> - Original Message - >> >>> From: Ivica Ico Bukvic >>> To: 'Mathieu Bouchard' >>> Cc: pd-list@iem.at >>> Sent: Tuesday, March 27, 2012 2:32 PM >>> Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote >> external now available >>> Curiously, I would have said exactly that about your fontsize >> thing. I would say that true zooming is the only way to go, and anything >> else distracts by creating bigger complications. >>> >>> Well, code-wise it is not. I simply change font size and automate >> stretch values >>> and don't worry about GOP objects because GOP design is in part >> conceived >>> around specific pixel size. Resizing them could potentially wreak >> complete havoc >>> on the organization of visual data inside them. >>> >>> To complicate matters further, tcl/tk treats canvas text differently >> than canvas >>> objects (vectors), so a true zoom can be never achieved completely >> accurately. >>> Imagine for instance having an iemgui object that has a label with a >> font size >>> of 16 and the rest of the patch using font size 10. When you resize >> things one >>> step up (since you are limited by what font sizes are feasible, >> meaning zoom >>> factor is restricted to workable font sizes) from 10 to 12, you are >> still >>> severely limited by tcl/tk--while the increase in 120% can easily >> translate to >>> vectors using canvas scale call, it does not account for images, or >> outlier font >>> sizes (120% of a font size 16 is 19.2 and unless I am missing >> something there is >>> no such font size possible inside tcl/tk). So, I do think this is the >> most >>> sensible way of dealing with this until pd-l2ork shifts to a >> different toolkit >>> altogether that is not so font-centric. >> >> What does font-centric mean? > > It means that zoom levels news to be driven by integer font sizes as tcl/tk > canvas is incapable of displaying non-int font sizes. This is why the pd > object > drawing mechanism first queries font width and height to decide how big of a > box > to draw. It is simply incapable of doing out the other way around. Ah, I understand. I forgot about that aspect of tk. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Gem polygon + buffer 1
Hello, is it possible that [polygon] does not work in buffer 1 mode? (it does not appear in buffer 1 mode, while it does in buffer 0) I do not have this problem with other objects. there is no error message pd-extended 0.43-1, ubuntu 11.10 thanks, Tim ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keystone correction
Evtoolkit? Patrick Pagano B.S.,M.F.A Digital Media Engineer UF Digital Worlds Institute (352)294-2020 On Mar 27, 2012, at 6:18 PM, "Charles Goyard" wrote: > Hi Cyrille, > > Cyrille Henry wrote: >> you can render anything on a framebuffer, then using it as a texture to the >> polygon. >> look at gem example: >> Gem/examples/12.multi_screen_projection/02.nfp-help.pd >> it's a bit more complex than what you want to do, but you'll may find it >> interesting. > > Thanks, that's very helpful. Now I have a texture with an in-circle pix, > and that texture is mapped into a polygon. > > However, the result is a bit weird. It looks like the point of view is > rotated by 90 degrees and with a bit angled Z-axis. I don't understand > the camera object. How can I get back to something more frontal ? > > Cheers, > > -- > Charlot > > ___ > 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] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Jonathan Wilkes wrote: > > > > >- Original Message - >> From: Mathieu Bouchard >> To: Ivica Ico Bukvic >> Cc: pd-list@iem.at >> Sent: Tuesday, March 27, 2012 11:45 AM >> Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote >external now available >> >> Le 2012-03-06 à 00:42:00, Ivica Ico Bukvic a écrit : >> >>> Font based zooming simply changes font sizes and repositions all >objects to >> be still in the same relation to each other. True zooming (ala >desiredata), >> while desireable (no pun intended) >> >> Well, in desiredata, puns were intended. The name was made from >> desiderata, a latin word to allude to todo-lists and wish-lists. >> >>> is at this point IMO too much work for too little gain. >> >> Curiously, I would have said exactly that about your fontsize thing. >I would say >> that true zooming is the only way to go, and anything else distracts >by creating >> bigger complications. > >I don't agree. The pd-extended/vanilla font dialog is good for >choosing an initial >font size, and _nearly_ useless for changing font sizes. Pd-l2ork font >dialog >is good for choosing an initial font size, perfectly fine for changing >font sizes when >normal text objects are all that is in the patch, somewhat useful for >changing font >size in a patch mixed with text objects and iemguis, and only >completely useless >when changing font size for a patch in which only iemguis are visible. But even this is debatable if you consider that the zoom tool is actually a patcher font size change tool (not gui zoom tool) that can be misrepresented as a zoom tool. In this case it makes no sense to resize iemgui objects when they are explicitly designed as gui objects whose properties are adjusted independently of core fonts. This is why also true zooming is impossible to do on tcl/tk canvas that has both vectors and fonts. And this is exactly why I chose not to bother with this feature. > >This isn't just theoretical. I wanted to read a help patch in a larger >font, and on >pd-l2ork I just increased the font size and stretched the patch window >to be >bigger. On pd-extended/vanilla the text objects would have collided >with a bigger >font and would have been illegible. > >-Jonathan > >> >>> we really need 2 instances. One that is based essentially off of >libpd and >> another that is a robust editor with none of the convoluted client >server model >> between the editor and the engine itself that has made improving on >the code so >> cumbersome… >> >> You want to replace the current client-server model by what exactly ? >Most >> likely another kind of client-server model ? >> >> >__ >> | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, >QC >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Jonathan Wilkes wrote: >- Original Message - > >> From: Ivica Ico Bukvic >> To: 'Mathieu Bouchard' >> Cc: pd-list@iem.at >> Sent: Tuesday, March 27, 2012 2:32 PM >> Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote >external now available >> >>> Curiously, I would have said exactly that about your fontsize >thing. I >>> would say that true zooming is the only way to go, and anything >else >>> distracts by creating bigger complications. >> >> Well, code-wise it is not. I simply change font size and automate >stretch values >> and don't worry about GOP objects because GOP design is in part >conceived >> around specific pixel size. Resizing them could potentially wreak >complete havoc >> on the organization of visual data inside them. >> >> To complicate matters further, tcl/tk treats canvas text differently >than canvas >> objects (vectors), so a true zoom can be never achieved completely >accurately. >> Imagine for instance having an iemgui object that has a label with a >font size >> of 16 and the rest of the patch using font size 10. When you resize >things one >> step up (since you are limited by what font sizes are feasible, >meaning zoom >> factor is restricted to workable font sizes) from 10 to 12, you are >still >> severely limited by tcl/tk--while the increase in 120% can easily >translate to >> vectors using canvas scale call, it does not account for images, or >outlier font >> sizes (120% of a font size 16 is 19.2 and unless I am missing >something there is >> no such font size possible inside tcl/tk). So, I do think this is the >most >> sensible way of dealing with this until pd-l2ork shifts to a >different toolkit >> altogether that is not so font-centric. > >What does font-centric mean? It means that zoom levels news to be driven by integer font sizes as tcl/tk canvas is incapable of displaying non-int font sizes. This is why the pd object drawing mechanism first queries font width and height to decide how big of a box to draw. It is simply incapable of doing out the other way around. > >> >> BTW, Pd-l2ork currently has a way to resize everything that is >disabled because >> resizing of the aforesaid issue, as well as the fact that everything >on >> tcl/tk's side of things does not account for all the changes >necessary on C >> side of things that would require updating each object's location and >size >> and updating its C-based structs that contain that info. This is why >in part >> client-server separation (for the editor) makes little sense when so >much of the >> client is already contained inside the server... >> >>> >>> > we really need 2 instances. One that is based essentially off of >libpd >>> > and another that is a robust editor with none of the convoluted >client >>> > server model between the editor and the engine itself that has >made >>> > improving on the code so cumbersome… >>> >>> You want to replace the current client-server model by what >exactly ? >>> Most >>> likely another kind of client-server model ? >> >> Yes, but one that does not use sockets to communicate critical data >and as such >> is severely limited in its performance, nor is it severely limited by >the >> toolkit. >> >> Best wishes, >> >> Ico >> >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keystone correction
Hi Cyrille, Cyrille Henry wrote: > you can render anything on a framebuffer, then using it as a texture to the > polygon. > look at gem example: > Gem/examples/12.multi_screen_projection/02.nfp-help.pd > it's a bit more complex than what you want to do, but you'll may find it > interesting. Thanks, that's very helpful. Now I have a texture with an in-circle pix, and that texture is mapped into a polygon. However, the result is a bit weird. It looks like the point of view is rotated by 90 degrees and with a bit angled Z-axis. I don't understand the camera object. How can I get back to something more frontal ? Cheers, -- Charlot ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keystone correction
hello Charles, you can render anything on a framebuffer, then using it as a texture to the polygon. look at gem example: Gem/examples/12.multi_screen_projection/02.nfp-help.pd it's a bit more complex than what you want to do, but you'll may find it interesting. cheers Cyrille Le 27/03/2012 21:50, Charles Goyard a écrit : Hi list, this is very basic, in fact so basic no one ever asked it seems :) I need to correct the trapezoidal/keystone deformation of a video. The beamer I use can't correct enough, so I need to do that with GEM. I heard of a keystone library but could not find it. I tried various rotate/scale/translate without getting good enough results. So I thought I could have a polygon with a texture mapped on it, and the stretch the corners. The problem I have is that my patch is as follows: [pix_image test.png] | [pix_texture] | [circle 4] (The circle is used to make a mask so the video boundaries are round.) Adding a polygon after the circle does not seem to work. Any advice welcome. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Keystone correction
Hi list, this is very basic, in fact so basic no one ever asked it seems :) I need to correct the trapezoidal/keystone deformation of a video. The beamer I use can't correct enough, so I need to do that with GEM. I heard of a keystone library but could not find it. I tried various rotate/scale/translate without getting good enough results. So I thought I could have a polygon with a texture mapped on it, and the stretch the corners. The problem I have is that my patch is as follows: [pix_image test.png] | [pix_texture] | [circle 4] (The circle is used to make a mask so the video boundaries are round.) Adding a polygon after the circle does not seem to work. Any advice welcome. -- Charlot ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] list-abs and externals [was: Re: [pd] tables as patch storage]
- Original Message - > From: Frank Barknecht > To: pd-list@iem.at > Cc: > Sent: Tuesday, March 27, 2012 11:45 AM > Subject: [PD] list-abs and externals [was: Re: [pd] tables as patch storage] > > On Tue, Mar 27, 2012 at 11:21:15AM -0400, Mathieu Bouchard wrote: >> list-abs was designed to only use pd's builtins, no externs, which >> makes it more like academic exercises of proving that anything can >> be done with a Turing tape machine, rather than being designed in a >> pragmatic way. > > Actually I consider list-abs to be very pragmatic *because* it only uses > builtins. This makes it highly portable and trivial to use > everywhere, even without installing it globally. > > If you treat list-abs as an interface or API, it also is very easy to > optimize the objects by using externals inside of the > list-abs-abstractions without having to change the surrounding patches. There's actually a much bigger potential benefit to using abstractions to build a common interface, which is that _anyone_ in the community can build the interface, and the guts (which may very well be filled with externals) can get replaced later as the internal objects necessary to support them get added to core Pd. For example, I could make a symbol manipulation library, similar to all the subcommands of the tcl [string] command, and fill the guts either with externals or a crazy symbol-splitting hack using only vanilla objects (so that vanilla users can at least try out the interface). Then the interface could get commented upon, tweaked, and changed (maybe using a different model than tcl) until it looks very good, and during this process, or at any point in the future when Pd's symbol stuff gets improved one can just change the guts of the interface to improve the performance/usefulness of the library. But I find it interesting that you only imagine the guts of list-abs getting replaced with externals in order to improve the performance, and not with new core objects. I think this is because the process of getting stuff included in core Pd is so badly broken that it's not even worth mentioning-- unfortunate since the abstraction interface-building I describe would be a really nice development model. -Jonathan > > I already sketched this approach four years ago: > http://lists.puredata.info/pipermail/pd-list/2008-12/066571.html > > Ciao > -- > Frank > > ___ > 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] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
- Original Message - > From: Ivica Ico Bukvic > To: 'Mathieu Bouchard' > Cc: pd-list@iem.at > Sent: Tuesday, March 27, 2012 2:32 PM > Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now > available > >> Curiously, I would have said exactly that about your fontsize thing. I >> would say that true zooming is the only way to go, and anything else >> distracts by creating bigger complications. > > Well, code-wise it is not. I simply change font size and automate stretch > values > and don't worry about GOP objects because GOP design is in part conceived > around specific pixel size. Resizing them could potentially wreak complete > havoc > on the organization of visual data inside them. > > To complicate matters further, tcl/tk treats canvas text differently than > canvas > objects (vectors), so a true zoom can be never achieved completely > accurately. > Imagine for instance having an iemgui object that has a label with a font > size > of 16 and the rest of the patch using font size 10. When you resize things > one > step up (since you are limited by what font sizes are feasible, meaning zoom > factor is restricted to workable font sizes) from 10 to 12, you are still > severely limited by tcl/tk--while the increase in 120% can easily translate > to > vectors using canvas scale call, it does not account for images, or outlier > font > sizes (120% of a font size 16 is 19.2 and unless I am missing something there > is > no such font size possible inside tcl/tk). So, I do think this is the most > sensible way of dealing with this until pd-l2ork shifts to a different > toolkit > altogether that is not so font-centric. What does font-centric mean? > > BTW, Pd-l2ork currently has a way to resize everything that is disabled > because > resizing of the aforesaid issue, as well as the fact that everything on > tcl/tk's side of things does not account for all the changes necessary on C > side of things that would require updating each object's location and size > and updating its C-based structs that contain that info. This is why in part > client-server separation (for the editor) makes little sense when so much of > the > client is already contained inside the server... > >> >> > we really need 2 instances. One that is based essentially off of libpd >> > and another that is a robust editor with none of the convoluted client >> > server model between the editor and the engine itself that has made >> > improving on the code so cumbersome… >> >> You want to replace the current client-server model by what exactly ? >> Most >> likely another kind of client-server model ? > > Yes, but one that does not use sockets to communicate critical data and as > such > is severely limited in its performance, nor is it severely limited by the > toolkit. > > Best wishes, > > Ico > > > > ___ > 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] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
- Original Message - > From: Mathieu Bouchard > To: Ivica Ico Bukvic > Cc: pd-list@iem.at > Sent: Tuesday, March 27, 2012 11:45 AM > Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now > available > > Le 2012-03-06 à 00:42:00, Ivica Ico Bukvic a écrit : > >> Font based zooming simply changes font sizes and repositions all objects to > be still in the same relation to each other. True zooming (ala desiredata), > while desireable (no pun intended) > > Well, in desiredata, puns were intended. The name was made from > desiderata, a latin word to allude to todo-lists and wish-lists. > >> is at this point IMO too much work for too little gain. > > Curiously, I would have said exactly that about your fontsize thing. I would > say > that true zooming is the only way to go, and anything else distracts by > creating > bigger complications. I don't agree. The pd-extended/vanilla font dialog is good for choosing an initial font size, and _nearly_ useless for changing font sizes. Pd-l2ork font dialog is good for choosing an initial font size, perfectly fine for changing font sizes when normal text objects are all that is in the patch, somewhat useful for changing font size in a patch mixed with text objects and iemguis, and only completely useless when changing font size for a patch in which only iemguis are visible. This isn't just theoretical. I wanted to read a help patch in a larger font, and on pd-l2ork I just increased the font size and stretched the patch window to be bigger. On pd-extended/vanilla the text objects would have collided with a bigger font and would have been illegible. -Jonathan > >> we really need 2 instances. One that is based essentially off of libpd and > another that is a robust editor with none of the convoluted client server > model > between the editor and the engine itself that has made improving on the code > so > cumbersome… > > You want to replace the current client-server model by what exactly ? Most > likely another kind of client-server model ? > > __ > | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
> Curiously, I would have said exactly that about your fontsize thing. I > would say that true zooming is the only way to go, and anything else > distracts by creating bigger complications. Well, code-wise it is not. I simply change font size and automate stretch values and don't worry about GOP objects because GOP design is in part conceived around specific pixel size. Resizing them could potentially wreak complete havoc on the organization of visual data inside them. To complicate matters further, tcl/tk treats canvas text differently than canvas objects (vectors), so a true zoom can be never achieved completely accurately. Imagine for instance having an iemgui object that has a label with a font size of 16 and the rest of the patch using font size 10. When you resize things one step up (since you are limited by what font sizes are feasible, meaning zoom factor is restricted to workable font sizes) from 10 to 12, you are still severely limited by tcl/tk--while the increase in 120% can easily translate to vectors using canvas scale call, it does not account for images, or outlier font sizes (120% of a font size 16 is 19.2 and unless I am missing something there is no such font size possible inside tcl/tk). So, I do think this is the most sensible way of dealing with this until pd-l2ork shifts to a different toolkit altogether that is not so font-centric. BTW, Pd-l2ork currently has a way to resize everything that is disabled because resizing of the aforesaid issue, as well as the fact that everything on tcl/tk's side of things does not account for all the changes necessary on C side of things that would require updating each object's location and size and updating its C-based structs that contain that info. This is why in part client-server separation (for the editor) makes little sense when so much of the client is already contained inside the server... > > > we really need 2 instances. One that is based essentially off of libpd > > and another that is a robust editor with none of the convoluted client > > server model between the editor and the engine itself that has made > > improving on the code so cumbersome > > You want to replace the current client-server model by what exactly ? > Most > likely another kind of client-server model ? Yes, but one that does not use sockets to communicate critical data and as such is severely limited in its performance, nor is it severely limited by the toolkit. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] tables as patch storage
- Original Message - > From: Mathieu Bouchard > To: Jonathan Wilkes > Cc: Frank Barknecht ; "pd-list@iem.at" > Sent: Tuesday, March 27, 2012 11:21 AM > Subject: Re: [PD] [pd] tables as patch storage > > Le 2012-03-27 à 08:04:00, Jonathan Wilkes a écrit : > >> Anythings aren't really free-form, either. "float my boat" > isn't a valid message in Pd. > > I mean as free-form as storable Anythings can be. I not talking about atoms > that > are not storable, nor about non-atoms, pink elephants and winged pigs. > >> But even if you're reading a Pd file with [textfile]-- which as far as > I know doesn't ever start with the word "float"-- > > selector float can always be implied, so it needs not be written. This is > because of what binbuf_eval does. Right but you can't help it being written in a Pd file, and thus the tools Pd vanilla gives you to read/write/parse a textfile-- the [textfile] object and [route]-- cannot even be used to parse the software's own file format. You have to either use list-abs [sroute] or build your own workaround to avoid the "bad argument" error with impunity. > >>> (Of course, there are externals, but they're not the kind of thing > used by the kind of people who come up with list-abs.) >> >> I don't know what that means. What does that mean? > > list-abs was designed to only use pd's builtins, no externs, which makes it > more like academic exercises of proving that anything can be done with a > Turing > tape machine, rather than being designed in a pragmatic way. There's not > enough basic functionality in the language, to be able to make abstractions > that > are both simple enough and fast enough. Well, yes, that's obviously true just by the fact that there isn't a (sensible) way to get an abstraction's arguments using the core objects. Question is: what needs to be added to make abstraction use simpler and faster? I found that the "get" method I added to canvas opened a lot of doors, even providing a quick way to get better locality in Pd (and the coding only took about 30 mins for that). I'm sure there's a lot more that I'm missing, though. -Jonathan > > __ > | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] for any other questions about GridFlow
On Tue, 2012-03-27 at 12:10 -0400, Mathieu Bouchard wrote: > This is my last post (apart from pd-announce posts). Will you still be on #dataflow? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] tables as patch storage
On Tue, 2012-03-27 at 11:21 -0400, Mathieu Bouchard wrote: > Le 2012-03-27 à 08:04:00, Jonathan Wilkes a écrit : > > > Anythings aren't really free-form, either. "float my boat" isn't a valid > > message in > > Pd. > > I mean as free-form as storable Anythings can be. I not talking about > atoms that are not storable, nor about non-atoms, pink elephants and > winged pigs. > > > But even if you're reading a Pd file with [textfile]-- which as far as I > > know doesn't ever start with the word "float"-- > > selector float can always be implied, so it needs not be written. This is > because of what binbuf_eval does. > > >> (Of course, there are externals, but they're not the kind of thing used by > >> the kind of people who come up with list-abs.) > > > > I don't know what that means. What does that mean? > > list-abs was designed to only use pd's builtins, no externs, which makes > it more like academic exercises of proving that anything can be done with > a Turing tape machine I can only speak for myself (your opinion obviously differs), but I actually find the list-abs library pretty useful. Though, I am sometimes not using it directly, but copy&pasting stuff from it to my patches. And sometimes I really use it as a library. I find the goal of it being only vanilla rather a pragmatic than an academic one. I also expect Frank not to have made it only for academia's sake. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] for any other questions about GridFlow
On 03/27/12 18:10, Mathieu Bouchard wrote: This is my last post (apart from pd-announce posts). again? fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] new pure data music
I'm having issues listening to your stuff. Choppy with the loading bar jumping around. Not sure if anyone else on Chrome browser on Ubuntu is having same issues. On Tue, Mar 27, 2012 at 2:31 AM, Julian Brooks wrote: > Oh yeah, of course. > > Cheers Roman. > > > > > On 27 March 2012 09:31, Roman Haefeli wrote: > >> On Tue, 2012-03-27 at 09:09 +0100, Julian Brooks wrote: >> > Hi Billy, >> > >> > Geocities link gives a '404'. >> > >> >> The link was somehow posted twice without a whitespace in between. This >> should work: >> >> http://www.geocities.ws/billy_stiltner/music/aahh.html >> >> Roman >> >> >> >> ___ >> 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
[PD] for any other questions about GridFlow
For any questions about GridFlow and related work, please write on gridflow-...@artengine.ca instead of pd-list. http://lists.artengine.ca/cgi-bin/mailman/listinfo/gridflow-dev This is my last post (apart from pd-announce posts). __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] exit (was: list-abs and externals)
Le 2012-03-27 à 17:45:00, Frank Barknecht a écrit : Actually I consider list-abs to be very pragmatic *because* it only uses builtins. I just mean that Pd's builtins are too deficient to make your approach worth it. Miller has another fifteen years to spare to figure out what will be the five next [list] builtins. But lists in pd aren't as inefficient as pd-list. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available
Le 2012-03-06 à 00:42:00, Ivica Ico Bukvic a écrit : Font based zooming simply changes font sizes and repositions all objects to be still in the same relation to each other. True zooming (ala desiredata), while desireable (no pun intended) Well, in desiredata, puns were intended. The name was made from desiderata, a latin word to allude to todo-lists and wish-lists. is at this point IMO too much work for too little gain. Curiously, I would have said exactly that about your fontsize thing. I would say that true zooming is the only way to go, and anything else distracts by creating bigger complications. we really need 2 instances. One that is based essentially off of libpd and another that is a robust editor with none of the convoluted client server model between the editor and the engine itself that has made improving on the code so cumbersome… You want to replace the current client-server model by what exactly ? Most likely another kind of client-server model ? __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] tables as patch storage
On Tue, Mar 27, 2012 at 11:38:13AM -0400, Mathieu Bouchard wrote: > Le 2012-03-27 à 17:37:00, Frank Barknecht a écrit : > > >On Tue, Mar 27, 2012 at 08:04:37AM -0700, Jonathan Wilkes wrote: > >>>From: Mathieu Bouchard > >>>(Of course, there are externals, but they're not the kind of thing used by > >>>the kind of people who come up with list-abs.) > >> > >>I don't know what that means. What does that mean? > > > >Matju is teasing me as maintainer of list-abs as a vanilla-based library, > >deliberatly jumping to the wrong conclusion I would despise externals. > >But I ignored the remark. Or actually now I didn't. > > Well, by calling it « teasing » you're avoiding the point of my > remark, which is essentially ignoring it. I think that you're > deliberately jumping to the wrong conclusions about my mail, too. I have 6 minutes left on my battery and won't leave the warm garden sun to jump to other conclusions. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] list-abs and externals [was: Re: [pd] tables as patch storage]
On Tue, Mar 27, 2012 at 11:21:15AM -0400, Mathieu Bouchard wrote: > list-abs was designed to only use pd's builtins, no externs, which > makes it more like academic exercises of proving that anything can > be done with a Turing tape machine, rather than being designed in a > pragmatic way. Actually I consider list-abs to be very pragmatic *because* it only uses builtins. This makes it highly portable and trivial to use everywhere, even without installing it globally. If you treat list-abs as an interface or API, it also is very easy to optimize the objects by using externals inside of the list-abs-abstractions without having to change the surrounding patches. I already sketched this approach four years ago: http://lists.puredata.info/pipermail/pd-list/2008-12/066571.html Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] tables as patch storage
Le 2012-03-27 à 17:37:00, Frank Barknecht a écrit : On Tue, Mar 27, 2012 at 08:04:37AM -0700, Jonathan Wilkes wrote: From: Mathieu Bouchard (Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.) I don't know what that means. What does that mean? Matju is teasing me as maintainer of list-abs as a vanilla-based library, deliberatly jumping to the wrong conclusion I would despise externals. But I ignored the remark. Or actually now I didn't. Well, by calling it « teasing » you're avoiding the point of my remark, which is essentially ignoring it. I think that you're deliberately jumping to the wrong conclusions about my mail, too. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] tables as patch storage
On Tue, Mar 27, 2012 at 08:04:37AM -0700, Jonathan Wilkes wrote: > > From: Mathieu Bouchard > > (Of course, there are externals, but they're not the kind of thing used by > > the kind of people who come up with list-abs.) > > I don't know what that means. What does that mean? Matju is teasing me as maintainer of list-abs as a vanilla-based library, deliberatly jumping to the wrong conclusion I would despise externals. But I ignored the remark. Or actually now I didn't. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] tables as patch storage
Le 2012-03-27 à 08:04:00, Jonathan Wilkes a écrit : Anythings aren't really free-form, either. "float my boat" isn't a valid message in Pd. I mean as free-form as storable Anythings can be. I not talking about atoms that are not storable, nor about non-atoms, pink elephants and winged pigs. But even if you're reading a Pd file with [textfile]-- which as far as I know doesn't ever start with the word "float"-- selector float can always be implied, so it needs not be written. This is because of what binbuf_eval does. (Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.) I don't know what that means. What does that mean? list-abs was designed to only use pd's builtins, no externs, which makes it more like academic exercises of proving that anything can be done with a Turing tape machine, rather than being designed in a pragmatic way. There's not enough basic functionality in the language, to be able to make abstractions that are both simple enough and fast enough. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] tables as patch storage
- Original Message - > From: Mathieu Bouchard > To: Frank Barknecht > Cc: pd-list@iem.at > Sent: Tuesday, March 27, 2012 9:45 AM > Subject: Re: [PD] [pd] tables as patch storage > > Le 2012-03-27 à 12:50:00, Frank Barknecht a écrit : >> On Mon, Mar 26, 2012 at 12:20:51PM +0200, Charles Goyard wrote: >>> Billy Stiltner wrote: why havent i seen more usage of tables as patch storage? >>> Maybe because you can only store numbers, not strings. >>> A textfile seems more versatile. >> Or a message box. Miller's help-files are crammed full with message > boxes used as patch storage. Patch-level storga it nice for toplevel patches, > but often not really useful in abstractions, when each abstraction instance > needs a different state, although they all share the same patch file. > > [textfile] fakes being a filehandle or linked-list in the way it has a > sequential interface instead of a random-access interface, even though it's > really stored in RAM as a binbuf. > > arrays ([table]) don't have that limitation, but have other limitations. > This creates unnecessary decisions in Pd, as people have to pick between > free-form anythings that have to be iterated through, or direct access to > items > that have to be floats, and they can't have both advantages at once. Anythings aren't really free-form, either. "float my boat" isn't a valid message in Pd. But even if you're reading a Pd file with [textfile]-- which as far as I know doesn't ever start with the word "float"-- you're limited in what you can do with it if you use the vanilla objects. The obvious choice to filter messages, [route], will choke on data structure definitions like [struct foo float bar] and give you an error if you happen to [route foo]. > > (Of course, there are externals, but they're not the kind of thing used by > the kind of people who come up with list-abs.) I don't know what that means. What does that mean? -Jonathan > > __ > | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] tables as patch storage
Le 2012-03-27 à 12:50:00, Frank Barknecht a écrit : On Mon, Mar 26, 2012 at 12:20:51PM +0200, Charles Goyard wrote: Billy Stiltner wrote: why havent i seen more usage of tables as patch storage? Maybe because you can only store numbers, not strings. A textfile seems more versatile. Or a message box. Miller's help-files are crammed full with message boxes used as patch storage. Patch-level storga it nice for toplevel patches, but often not really useful in abstractions, when each abstraction instance needs a different state, although they all share the same patch file. [textfile] fakes being a filehandle or linked-list in the way it has a sequential interface instead of a random-access interface, even though it's really stored in RAM as a binbuf. arrays ([table]) don't have that limitation, but have other limitations. This creates unnecessary decisions in Pd, as people have to pick between free-form anythings that have to be iterated through, or direct access to items that have to be floats, and they can't have both advantages at once. (Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.) __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] connecting Pd to LEDs
hi i did a project last year controlling a led-wall for displaying the fft-analysis of the sound which actually happens on the stage of the theater behind. its a 24/7 installation with 1280 led´s white and dimmable. we did it through udp and the serial porta driver was made for costum made led-controllers. it works well since 1 1/2 years. any questions? markus Zitat von "Jim Hickcox" : Hey there. I am working on an architectural installation with a guy and part of the goal is to control some dim lighting from Pd. Does anyone have any experience with the steps for taking the midi output and making that control some LEDs? Any recommended workflows? I was thinking about trying to build something with an arduino, but maybe there's something more time-efficient, since I only sort of know what I am doing. Any suggestions would be appreciated. -Jim ___ 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] connecting Pd to LEDs
On Tue, Mar 27, 2012 at 14:57, Martin Peach wrote: > The DMXUSBPro works well for me with Pd. I set the [comport] baud rate to > 25 but I don't think it's necessary. > Well, how many lights are you controlling? :) I think for architectural lighting, the number of DMX channels used can go up pretty fast. And you probably want at least 30 packets, per channel, per second ... RGB lights usually have 4 channels ... It gets quite expensive :) -- Regards, buZz ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] connecting Pd to LEDs
On 2012-03-27 05:07, Bastiaan van den Berg wrote: On Tue, Mar 27, 2012 at 09:41, Pierre-Olivier Boulant mailto:po.boul...@free.fr>> wrote: Hi, You can make a USB to DMX interface really easily with an Arduino. FYI, USB is pretty slow for DMX stuff. It's faster than DMX though. It's the arduino that can't read fast enough, its maximum baud rate seems to be 115200 without going into assembler. The DMXUSBPro works well for me with Pd. I set the [comport] baud rate to 25 but I don't think it's necessary. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] tables as patch storage
On Mon, Mar 26, 2012 at 12:20:51PM +0200, Charles Goyard wrote: > Hi, > > Billy Stiltner wrote: > > why havent i seen more usage of tables as patch storage? > > Maybe because you can only store numbers, not strings. > > A textfile seems more versatile. Or a message box. Miller's help-files are crammed full with message boxes used as patch storage. Patch-level storga it nice for toplevel patches, but often not really useful in abstractions, when each abstraction instance needs a different state, although they all share the same patch file. 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
[PD] pure-data as SourceForge featured project, week of March 26
Nice one!! > We're on the font page of Sourceforge this week! > > https://sourceforge.net/ > > .hc > > -- Marco Donnarumma New Media + Sonic Arts Practitioner, Performer, Teacher, Director. ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK ~ Portfolio: http://marcodonnarumma.com Research: http://res.marcodonnarumma.com | http://www.thesaddj.com | http://www.flxer.net Director: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] new pure data music
Oh yeah, of course. Cheers Roman. On 27 March 2012 09:31, Roman Haefeli wrote: > On Tue, 2012-03-27 at 09:09 +0100, Julian Brooks wrote: > > Hi Billy, > > > > Geocities link gives a '404'. > > > > The link was somehow posted twice without a whitespace in between. This > should work: > > http://www.geocities.ws/billy_stiltner/music/aahh.html > > Roman > > > > ___ > 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] connecting Pd to LEDs
On Tue, Mar 27, 2012 at 09:41, Pierre-Olivier Boulant wrote: > Hi, > > You can make a USB to DMX interface really easily with an Arduino. FYI, USB is pretty slow for DMX stuff. You rather want an external controller that runs all the controlling logic. Something like http://lanbox.com/ which I've used a couple of times for similar projects. -- Regards, buZz ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] new pure data music
On Tue, 2012-03-27 at 09:09 +0100, Julian Brooks wrote: > Hi Billy, > > Geocities link gives a '404'. > The link was somehow posted twice without a whitespace in between. This should work: http://www.geocities.ws/billy_stiltner/music/aahh.html Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] new pure data music
Hi Billy, Geocities link gives a '404'. Cheers, Julian ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] connecting Pd to LEDs
For the archives, I had emailed my brother in law Pete about the potential of using an arduino chip to process the midi and send the signals to the LEDs, and his response was fairly enlightening as well, so here's that in case it's helpful for the future: The "analog" outputs of the arduino are in fact pulse width modulated (PWM) digital signals. These are easy to convert into an analog voltage with a filter but you dont have to worry about that. The best way to dim an LED is with PWM. What this means is that the LED turns on and off really fast. The brightness is a result of the ratio of ON to OFF per cycle, thats pulse width. The arduino makes this really easy. When you assign a value to an analog output it translates that into a PWM ratio. So with a little midi translation you should easily be able to take midi data and make it into a value between 0 and 256 which you can send to a few analog outputs. BUT you cant drive high power LEDs directly from the arduino. A regular LED draws about 15mA. The arduino outputs can drive (I think) around 20mA each. A high power LED or LED array can draw at least a full AMP (1000mA). The solution to this is a simple transistor based LED driver. A driver is an amplifier and an isolator. It essentially takes very low current from the arduino and outputs high current to the LEDs. The kind of driver you use and the amount of current it supplies will depend on the LED array you want to drive. On Tue, Mar 27, 2012 at 1:45 AM, Jim Hickcox wrote: > Thank you all for getting back to me. > > Patrick: > I actually tried to call Enttec today, but both of their sales people > were on an airplane, and they should get back to me tomorrow I guess. > But what do you need? They have a usb to dmx, right? And then you need > the driver, and then just the lights? That seems pretty > straightforward. > > Max: > That udmx looks awesome, if it's a functional thing. > > Jean-Marie/Björn: > Thanks for the heads up on interface-z. I'd never heard of them. Looks > easy enough. > > Charles: > I guess I don't know how to just do a dmx output. Although, now I seem > to have some options. > > Again, thanks all. > > -Jim > > > > 2012/3/26 Björn Eriksson : >> Found this when as suggested doing some googling on Interface-Z - on this >> page some test pd patches and more... >> http://www.interface-z.com/produits/act054_8_trans-puiss.htm >> and a vid: >> http://www.youtube.com/watch?v=JAjILa4MOu8 >> >> /Björn Eriksson >> >> >> On Mon, Mar 26, 2012 at 9:35 PM, Jean-Marie Adrien >> wrote: >>> >>> hi >>> if you're in a hurry, google interface-z >>> jmadrien >>> >>> Le 26 mars 2012 à 20:02, Jim Hickcox a écrit : >>> >>> > Hey there. >>> > >>> > I am working on an architectural installation with a guy and part of >>> > the goal is to control some dim lighting from Pd. >>> > Does anyone have any experience with the steps for taking the midi >>> > output and making that control some LEDs? >>> > Any recommended workflows? >>> > I was thinking about trying to build something with an arduino, but >>> > maybe there's something more time-efficient, since I only sort of know >>> > what I am doing. >>> > >>> > Any suggestions would be appreciated. >>> > >>> > -Jim >>> > >>> > ___ >>> > 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 >> ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
