Re: [PD] canvas path
Okay, here's a first pass to outline what's going on with Pd's library loader(s): http://www.jonathanwilkes.net/2014/10/loading-a-library-in-pure-data/ I don't cover the interaction between global and canvas-local searchpaths, nor how exactly the libdir loader from Pd-extended does its thing. If anyone finds errors let me know and I'll correct them. -Jonathan On Monday, October 20, 2014 5:43 PM, katja wrote: Thanks for demonstrating [declare -path .], Frank. Food for thought. On Mon, Oct 20, 2014 at 8:54 PM, Frank Barknecht wrote: Hi, > >here's some more food for thought: How to deal with library abstractions that >load other objects whose name is set at runtime? This is actually pretty >common, for example in abstractions that decorate other abstraction with e.g. >polyphony, or when writing soundfile/score loading objects. > >I attached a test case that illustrates various combinations one may meet in >this case. > >Please start Pd in the directory "metaprog" and open: > >01_loadhere.pd >02_loadhere-declare-mylib.pd >03_loadhere-declare-dot.pd > >Ciao >-- >Frank > > > >On Mon, Oct 20, 2014 at 08:34:13AM -0700, Miller Puckette wrote: >> Hi all, >> >> I think it might work simply to maintain a per-patch list of "externs" >> currently loaded. New patches would start out with an empty list, which >> would >> then get filled in by that patch's own search procedures. >> >> There might be some complicated problems to resove about such searche within >> abstractions (indeed, there are already severe problems the way that is set >> up that I want to try to fix.) >> >> cheers >> Miller >> >> Oe Sun, Oct 19, 2014 at 11:21:15AM -0700, Jonathan Wilkes via Pd-list wrote: >> > Hi list, >> > Let me describe a typical way to use Pd: >> > 1) patch author makes a patch >> > 2) >> > patch author abstracts out certain functions into Pd abstractions >> > 3) patch author makes a self-contained collection of these abstractions >> > (and maybe some helper abstractions) >> > 4) patch author takes every _reasonable_ step to make their collection >> > portable-- that is, to ensure that their abstractions and nested >> > abstractions create correctly on any version of Pd and don't collide with >> > anything in the standard library path. >> > >> > Currently a patch author cannot achieve this. Pure data forces them to >> > care about what names pre-existing externals might have (which is probably >> > why many externals make a common name prefix part of the name of each >> > object). The reason is that an abstraction's directory is not the first >> > place to be searched for externals or abstractions to be loaded. It is >> > superceded by the searchpath set by [declare] for all of that >> > abstraction's parent canvases. >> > >> > If any of those parent canvases declare a path which >> > has an external or abstraction by the same name as one of the helper >> > abstractions, the object in that path will get created instead of the >> > helper abstraction. Furthermore, if any of those parent canvases declare >> > a path that happens to have the same name as the subdirectory containing >> > the helper abstraction, then "path/objectname" will override >> > "subdirectory/helper". This is even true if you use >> > "./subdirectory/helper". >> > >> > This means that if the patch author wants to grope toward portability they >> > have to do this, too: >> > 5) read/search all the libnames and object names in pd-extended, and all >> > the other widely used libs and objects scattered about the internet. Then >> > come up with a name that is human readable, but also unique enough to >> > prevent collisions with anything else out there. >> > >> > I think #5 is unreasonable, especially because creating a little zipped >> > directory with abstractions (or even externals) is such a common way of >> > making ostensibly portable libraries in Pd. Essentially we're asking >> > users to do their own name-mangling. >> > >> > So why isn't an abstraction's directory the _first_ one to be searched by >> > default in Pd? I understand katja and Matt Barber's reasons for using >> > [declare] to infect an entire running instance with different path >> > priorities, but I think that's the exception rather than the rule. Can we >> > give abstraction directories precedence in the loading scheme, and maybe >> > use a startup flag to trigger Pd's current behavior? >> > >> > -Jonathan >> >> > ___ >> > Pd-list@lists.iem.at mailing list >> > UNSUBSCRIBE and account-management -> >> > http://lists.puredata.info/listinfo/pd-list >> >> >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > >-- > Frank Barknecht _ __footils.org__ > >___ >Pd-list@lists.iem.at mailing li
Re: [PD] canvas path
Thanks for demonstrating [declare -path .], Frank. Food for thought. On Mon, Oct 20, 2014 at 8:54 PM, Frank Barknecht wrote: > Hi, > > here's some more food for thought: How to deal with library abstractions > that > load other objects whose name is set at runtime? This is actually pretty > common, for example in abstractions that decorate other abstraction with > e.g. > polyphony, or when writing soundfile/score loading objects. > > I attached a test case that illustrates various combinations one may meet > in > this case. > > Please start Pd in the directory "metaprog" and open: > > 01_loadhere.pd > 02_loadhere-declare-mylib.pd > 03_loadhere-declare-dot.pd > > Ciao > -- > Frank > > > On Mon, Oct 20, 2014 at 08:34:13AM -0700, Miller Puckette wrote: > > Hi all, > > > > I think it might work simply to maintain a per-patch list of "externs" > > currently loaded. New patches would start out with an empty list, which > would > > then get filled in by that patch's own search procedures. > > > > There might be some complicated problems to resove about such searche > within > > abstractions (indeed, there are already severe problems the way that is > set > > up that I want to try to fix.) > > > > cheers > > Miller > > > > Oe Sun, Oct 19, 2014 at 11:21:15AM -0700, Jonathan Wilkes via Pd-list > wrote: > > > Hi list, > > > Let me describe a typical way to use Pd: > > > 1) patch author makes a patch > > > 2) > > > patch author abstracts out certain functions into Pd abstractions > > > 3) patch author makes a self-contained collection of these > abstractions (and maybe some helper abstractions) > > > 4) patch author takes every _reasonable_ step to make their collection > portable-- that is, to ensure that their abstractions and nested > abstractions create correctly on any version of Pd and don't collide with > anything in the standard library path. > > > > > > Currently a patch author cannot achieve this. Pure data forces them > to care about what names pre-existing externals might have (which is > probably why many externals make a common name prefix part of the name of > each object). The reason is that an abstraction's directory is not the > first place to be searched for externals or abstractions to be loaded. It > is superceded by the searchpath set by [declare] for all of that > abstraction's parent canvases. > > > > > > If any of those parent canvases declare a path which > > > has an external or abstraction by the same name as one of the helper > abstractions, the object in that path will get created instead of the > helper abstraction. Furthermore, if any of those parent canvases declare a > path that happens to have the same name as the subdirectory containing the > helper abstraction, then "path/objectname" will override > "subdirectory/helper". This is even true if you use > "./subdirectory/helper". > > > > > > This means that if the patch author wants to grope toward portability > they have to do this, too: > > > 5) read/search all the libnames and object names in pd-extended, and > all the other widely used libs and objects scattered about the internet. > Then come up with a name that is human readable, but also unique enough to > prevent collisions with anything else out there. > > > > > > I think #5 is unreasonable, especially because creating a little > zipped directory with abstractions (or even externals) is such a common way > of > > > making ostensibly portable libraries in Pd. Essentially we're asking > users to do their own name-mangling. > > > > > > So why isn't an abstraction's directory the _first_ one to be searched > by default in Pd? I understand katja and Matt Barber's reasons for using > [declare] to infect an entire running instance with different path > priorities, but I think that's the exception rather than the rule. Can we > give abstraction directories precedence in the loading scheme, and maybe > use a startup flag to trigger Pd's current behavior? > > > > > > -Jonathan > > > > > ___ > > > Pd-list@lists.iem.at mailing list > > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > > ___ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > -- > Frank Barknecht _ __footils.org__ > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] canvas path
Hi Frank, Let's take your demos one abstraction at a time: 01_loadhere.pd: [mylib/metaload here] -- doesn't load [$1], because you didn't supply any search paths anywhere. So all the ce_path entries are empty, which means that Pd tries to load "here" in the directory of the metaload abstraction. That directory doesn't contain here.pd, and so it fails to load. [mylib/metaload there] -- creates under the same logic outlined above. "there.pd" is in metaload's directory. Success. [mylib/metaload mylib/there] -- The [metaload] abstraction's directory doesn't contain a subdirectory "mylib", so this fails. [mylib/metaload nbx] and [mylib/metaload hsl] -- these are pointless. [nbx] and [hsl] are internal objects, which means Pd finds them in the objectmaker method table before it even searches for libs to load. Though I guess Hans wants them not to create by default in your situation. Btw-- you forgot to include [mylib/metaload both] (which would create the both.pd from "mylib" since that's the abstraction's directory and it exists there) and [mylib/metaload mylib/both] (which would fail to create [$1] because [metaload]'s directory doesn't contain a subdirectory "mylib"). 02_loadhere-declare-mylib.pd - [declare -path mylib] will go down and "infect" each abstraction's path. (In fact Pd just searches it first when attempting to open the abstractions.) The [declare] relative logic-- if you feed a relative path to declare, you'll get the concatenation of the toplevel patch's directory with the relative path specified to declare. So in this patch, you'll get /mylib. (After that I [mylib/metaload here] -- still doesn't create because there's no "here.pd" file inside "mylib" [mylib/metaload there] -- creates, using the same logic [mylib/metaload mylib/there] -- won't create because there's no mylib directory inside mylib [mylib/metaload both] and [metaload both] -- both create /mylib/both.pd since it exists Also, notice that [metaload] creates because of [declare -path mylib]. If you didn't have that it'd fail. Then why does [mylib/metaload] create? Because after Pd _fails_ to find /mylib/mylib/metaload, it falls back to searching inside the directory of the patch, which would be / + mylib/metaload, which successfully creates. 03_loadhere-declare-dot.pd [declare -path .] concatenates with "." and gives that path precedence for all its objects plus infecting all objects inside the abstractions with that as the first path to search. [mylib/metaload here] = [/./mylib/metaload here]. [$1] is searched first in the path from [declare], which would be /./here, which creates successfully. [mylib/metaload there] = [/./mylib/metaload there]. [$1] is searched first as above, which fails, _but_ then Pd tries the abstraction's directory which holds "there.pd". Success on 2nd try. [mylib/metaload both] = [/./mylib/metaload]. [$1] is searched as above, and the toplevel patch's directory has a "both.pd" so that one succeeds. (Thus one in the abstraction's dir is never searched.) [metaload both] = [/./metaload both]. "metaload.pd" isn't in the patch's main directory so this fails to create *** Do notice that Pd-l2ork's *info objects (or iemguts and hcs externals) are indispensable to figure out exactly what is going on here. Pd Vanilla has no tools to actually see what's going on under the hood, so all you can do is pen-test and hope something meaningful comes out of that. Also, note that [declare -path .] is not the same as my suggestion for implicit path precendence for the abstraction's directory. This is because any [declare] in a parent of the abstraction will take precedence. At least that's what it looks like is happening inside canvas_open of g_canvas.c. Finally, you're implicitly doing your own namespacing/namemangling by choosing the subdirectory name "mylib". If you choose a subdir name that's the same as a loaded external library (or even an unloaded one that's in the global path), it will take precedence over your abstractions in the subdir. -Jonathan On Monday, October 20, 2014 2:58 PM, Frank Barknecht wrote: Hi, here's some more food for thought: How to deal with library abstractions that load other objects whose name is set at runtime? This is actually pretty common, for example in abstractions that decorate other abstraction with e.g. polyphony, or when writing soundfile/score loading objects. I attached a test case that illustrates various combinations one may meet in this case. Please start Pd in the directory "metaprog" and open: 01_loadhere.pd 02_loadhere-declare-mylib.pd 03_loadhere-declare-dot.pd Ciao -- Frank On Mon, Oct 20, 2014 at 08:34:13AM -0700, Miller Puckette wrote: > Hi all, > > I think it might work simply to maintain a per-patch list of "externs" > currently loaded. New patches would start out with an empty list, which would > then get filled in by that patch's own search procedures. > > Th
Re: [PD] canvas path
Hi Miller, Well, currently it works like this: "If I put my stuff in the folder with my abstraction, and the person using my abstraction doesn't happen to use [declare] to set a path containing stuff that aliases the name of my abstraction or stuff that aliases the libdir/name of my subdir/abstraction, then my abstraction will load the stuff from my folder, _except_ for cases where my folder contains an abstraction aliased by an external binary found either in the global path or the aforementioned coincidental use of [declare] in a parent patch. The only sensible thing I can think of is giving the abstraction's directory implicit precedence. "If I put my stuff in the folder with my abstraction, then my abstraction will load the stuff from my folder." -Jonathan On Monday, October 20, 2014 11:34 AM, Miller Puckette wrote: Hi all, I think it might work simply to maintain a per-patch list of "externs" currently loaded. New patches would start out with an empty list, which would then get filled in by that patch's own search procedures. There might be some complicated problems to resove about such searche within abstractions (indeed, there are already severe problems the way that is set up that I want to try to fix.) cheers Miller Oe Sun, Oct 19, 2014 at 11:21:15AM -0700, Jonathan Wilkes via Pd-list wrote: > Hi list, > Let me describe a typical way to use Pd: > 1) patch author makes a patch > 2) > patch author abstracts out certain functions into Pd abstractions > 3) patch author makes a self-contained collection of these abstractions (and maybe some helper abstractions) > 4) patch author takes every _reasonable_ step to make their collection > portable-- that is, to ensure that their abstractions and nested abstractions > create correctly on any version of Pd and don't collide with anything in the > standard library path. > > Currently a patch author cannot achieve this. Pure data forces them to care > about what names pre-existing externals might have (which is probably why > many externals make a common name prefix part of the name of each object). > The reason is that an abstraction's directory is not the first place to be > searched for externals or abstractions to be loaded. It is superceded by the > searchpath set by [declare] for all of that abstraction's parent canvases. > > If any of those parent canvases declare a path which > has an external or abstraction by the same name as one of the helper > abstractions, the object in that path will get created instead of the helper > abstraction. Furthermore, if any of those parent canvases declare a path > that happens to have the same name as the subdirectory containing the helper > abstraction, then "path/objectname" will override "subdirectory/helper". > This is even true if you use "./subdirectory/helper". > > This means that if the patch author wants to grope toward portability they > have to do this, too: > 5) read/search all the libnames and object names in pd-extended, and all the > other widely used libs and objects scattered about the internet. Then come > up with a name that is human readable, but also unique enough to prevent > collisions with anything else out there. > > I think #5 is unreasonable, especially because creating a little zipped directory with abstractions (or even externals) is such a common way of > making ostensibly portable libraries in Pd. Essentially we're asking users > to do their own name-mangling. > > So why isn't an abstraction's directory the _first_ one to be searched by > default in Pd? I understand katja and Matt Barber's reasons for using > [declare] to infect an entire running instance with different path > priorities, but I think that's the exception rather than the rule. Can we > give abstraction directories precedence in the loading scheme, and maybe use > a startup flag to trigger Pd's current behavior? > > -Jonathan > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] canvas path
Hi, here's some more food for thought: How to deal with library abstractions that load other objects whose name is set at runtime? This is actually pretty common, for example in abstractions that decorate other abstraction with e.g. polyphony, or when writing soundfile/score loading objects. I attached a test case that illustrates various combinations one may meet in this case. Please start Pd in the directory "metaprog" and open: 01_loadhere.pd 02_loadhere-declare-mylib.pd 03_loadhere-declare-dot.pd Ciao -- Frank On Mon, Oct 20, 2014 at 08:34:13AM -0700, Miller Puckette wrote: > Hi all, > > I think it might work simply to maintain a per-patch list of "externs" > currently loaded. New patches would start out with an empty list, which would > then get filled in by that patch's own search procedures. > > There might be some complicated problems to resove about such searche within > abstractions (indeed, there are already severe problems the way that is set > up that I want to try to fix.) > > cheers > Miller > > Oe Sun, Oct 19, 2014 at 11:21:15AM -0700, Jonathan Wilkes via Pd-list wrote: > > Hi list, > > Let me describe a typical way to use Pd: > > 1) patch author makes a patch > > 2) > > patch author abstracts out certain functions into Pd abstractions > > 3) patch author makes a self-contained collection of these abstractions > > (and maybe some helper abstractions) > > 4) patch author takes every _reasonable_ step to make their collection > > portable-- that is, to ensure that their abstractions and nested > > abstractions create correctly on any version of Pd and don't collide with > > anything in the standard library path. > > > > Currently a patch author cannot achieve this. Pure data forces them to > > care about what names pre-existing externals might have (which is probably > > why many externals make a common name prefix part of the name of each > > object). The reason is that an abstraction's directory is not the first > > place to be searched for externals or abstractions to be loaded. It is > > superceded by the searchpath set by [declare] for all of that abstraction's > > parent canvases. > > > > If any of those parent canvases declare a path which > > has an external or abstraction by the same name as one of the helper > > abstractions, the object in that path will get created instead of the > > helper abstraction. Furthermore, if any of those parent canvases declare a > > path that happens to have the same name as the subdirectory containing the > > helper abstraction, then "path/objectname" will override > > "subdirectory/helper". This is even true if you use > > "./subdirectory/helper". > > > > This means that if the patch author wants to grope toward portability they > > have to do this, too: > > 5) read/search all the libnames and object names in pd-extended, and all > > the other widely used libs and objects scattered about the internet. Then > > come up with a name that is human readable, but also unique enough to > > prevent collisions with anything else out there. > > > > I think #5 is unreasonable, especially because creating a little zipped > > directory with abstractions (or even externals) is such a common way of > > making ostensibly portable libraries in Pd. Essentially we're asking > > users to do their own name-mangling. > > > > So why isn't an abstraction's directory the _first_ one to be searched by > > default in Pd? I understand katja and Matt Barber's reasons for using > > [declare] to infect an entire running instance with different path > > priorities, but I think that's the exception rather than the rule. Can we > > give abstraction directories precedence in the loading scheme, and maybe > > use a startup flag to trigger Pd's current behavior? > > > > -Jonathan > > > ___ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Frank Barknecht _ __footils.org__ metaprog.tgz Description: GNU Unix tar archive ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] canvas path
Hi all, I think it might work simply to maintain a per-patch list of "externs" currently loaded. New patches would start out with an empty list, which would then get filled in by that patch's own search procedures. There might be some complicated problems to resove about such searche within abstractions (indeed, there are already severe problems the way that is set up that I want to try to fix.) cheers Miller Oe Sun, Oct 19, 2014 at 11:21:15AM -0700, Jonathan Wilkes via Pd-list wrote: > Hi list, > Let me describe a typical way to use Pd: > 1) patch author makes a patch > 2) > patch author abstracts out certain functions into Pd abstractions > 3) patch author makes a self-contained collection of these abstractions (and > maybe some helper abstractions) > 4) patch author takes every _reasonable_ step to make their collection > portable-- that is, to ensure that their abstractions and nested abstractions > create correctly on any version of Pd and don't collide with anything in the > standard library path. > > Currently a patch author cannot achieve this. Pure data forces them to care > about what names pre-existing externals might have (which is probably why > many externals make a common name prefix part of the name of each object). > The reason is that an abstraction's directory is not the first place to be > searched for externals or abstractions to be loaded. It is superceded by the > searchpath set by [declare] for all of that abstraction's parent canvases. > > If any of those parent canvases declare a path which > has an external or abstraction by the same name as one of the helper > abstractions, the object in that path will get created instead of the helper > abstraction. Furthermore, if any of those parent canvases declare a path > that happens to have the same name as the subdirectory containing the helper > abstraction, then "path/objectname" will override "subdirectory/helper". > This is even true if you use "./subdirectory/helper". > > This means that if the patch author wants to grope toward portability they > have to do this, too: > 5) read/search all the libnames and object names in pd-extended, and all the > other widely used libs and objects scattered about the internet. Then come > up with a name that is human readable, but also unique enough to prevent > collisions with anything else out there. > > I think #5 is unreasonable, especially because creating a little zipped > directory with abstractions (or even externals) is such a common way of > making ostensibly portable libraries in Pd. Essentially we're asking users > to do their own name-mangling. > > So why isn't an abstraction's directory the _first_ one to be searched by > default in Pd? I understand katja and Matt Barber's reasons for using > [declare] to infect an entire running instance with different path > priorities, but I think that's the exception rather than the rule. Can we > give abstraction directories precedence in the loading scheme, and maybe use > a startup flag to trigger Pd's current behavior? > > -Jonathan > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Get room impulse response
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I don't know a lot of things in this domain. I just know that reflected source signals are sensitive to the environment geometry and materials and I would like to get the room impulse response. Is there good informations about this topic somewhere (web or help patch) ? Is there an existing (simple) patch I can use to understand the process ? Thanx. ++ Jack -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJURSqHAAoJEOuluecjw8GULj4H/Rq84KRWuwTcvLEacWDPB+2W Xeo+9BC9HclSLbeh4zETdR5uY/NcFArlWFFV+gcKCH02Q6SEPxoO4L4d/av3/NP5 ijYtMwW29lXISQ8ZNbetHDXRfSlKD1BwMpq7zQPypH4fZjJ5jssweBgTMBRA5vJ2 yVBgX8AAViiRaSDq7WiddFCs33JSVa0lkHt7LjNvoJ4C7KDGG6yNWoAoNpszhE0z uB3CaxfpAIJK8mLcKJI4oTeO+rFEX9UE7pGDLggD6QWC63G5dj1dmGtcu7KLsgN6 Mn03cZFf2tDbY54nuyx+gU/VjO+9BVLgF+ssLgramyz4fBwcoskpsT0DualnTt0= =2lWH -END PGP SIGNATURE- ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Razor AHRS via comport: 4byte float?
Hi Martin, * Martin Peach [2014-10-20 05:38]: > In the Pd svn I have an external [b2f] which probably does what you want. > Not sure if it made in into Pd-extended yet as there don't seem to be many > recent builds available, but it should be straightforward to compile. Thanks, this looks good. I am just wondering how to compile it. I am on Linux and have a fresh svn checkout of the externals directory. mrpeach/serializer/ does not have a Makefile though, and the directory above it has a Makefile, which I can't get to work to compile the serializer. I must admit that I never really got fluent with what was once called the "new" build system for externals... What could be a good way to do it in this case here? Thank you so much! Peter ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem and 3D printers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Cyrille, I have been able to export my 3D curve with obj-rectangle and export it in .stl. Thanx for your help ! ++ Jack Le 20/10/2014 12:29, Cyrille Henry a écrit : > hello, > > Le 20/10/2014 12:13, Jack a écrit : Hello, > > Is there someone who has already print object with 3D printer > using Gem and obj-exporter (or something else) > >> yes, that why obj-exporter was created. > > > If yes, what was the process ? >> 1. create a .obj file. 2. open if in blender or similar, scale it >> to fit the printer unit, and export this file to .stl 3. send >> the stl file to the printer. > > > > I am looking for a way to print a curved surface (like a wave with > depth). I think, with obj-exporter, i will need a lot of obj-cube > (or obj-cuboid) to make a smooth surface ? > >> obj-exporter did not have lot's of primitives. but you can make >> your own primitive that fit your need. (and add it to >> obj-exporter). It would not be very complicated to create a >> primitive based on a curve3d. > >> or you can use juste a lot's of triangle or square... > > > >> cheers c > > > ++ > > Jack > >> >> ___ >> Pd-list@lists.iem.at mailing list UNSUBSCRIBE and >> account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > ___ > Pd-list@lists.iem.at mailing list UNSUBSCRIBE and > account-management -> http://lists.puredata.info/listinfo/pd-list -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJURQg0AAoJEOuluecjw8GU57EH/1BaXbRJJrXuj6VrqKs0HqSS ylRVJJ/njZvOfH6XaPawcMPCatoNk0bZi0Dd666BLgO+1rYJuzST9VcWGgsAaUJ/ HzZjdnlHhjjDB0QxLvmUt/mfzLZ6ZhR0U2aUDLJfbcBTBeHcscuZ1qz0VUH9jutt D3ZwiLLknrEQ+JNv0iot50nbODCEmsNL5ehYbiy57eTNAx1AGKph6PZpNbcaTZPk tPT8HvQe2a8fNltAsiXtVoB/qWG/87gvBoIZbxKEaYPt+KSeXCzVgyIgeocets7q kTCNQ13SZOAfOYrhG1Q1JRzhmjDMCjroqCmc9R+Q0Q7lbE92VyDQy7iVEMtNih4= =+Qdh -END PGP SIGNATURE- ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem and 3D printers
hello, Le 20/10/2014 12:13, Jack a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Is there someone who has already print object with 3D printer using Gem and obj-exporter (or something else) yes, that why obj-exporter was created. If yes, what was the process ? 1. create a .obj file. 2. open if in blender or similar, scale it to fit the printer unit, and export this file to .stl 3. send the stl file to the printer. I am looking for a way to print a curved surface (like a wave with depth). I think, with obj-exporter, i will need a lot of obj-cube (or obj-cuboid) to make a smooth surface ? obj-exporter did not have lot's of primitives. but you can make your own primitive that fit your need. (and add it to obj-exporter). It would not be very complicated to create a primitive based on a curve3d. or you can use juste a lot's of triangle or square... cheers c ++ Jack -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUROBEAAoJEOuluecjw8GUpIUH/jPvfijqpTuRbKVxWopj0Xhn ctKTgYsrBq3WBSIH7tI5wILxiPjO8sf5wfMaoVQVjnLyg55jsa5ql170c39JX3cK CYUkhBUWLJi+c1ykWgrrZXqfwffo/ftAQxxiGkaUkhE7N6bgCS8+PAXN+p65jnxG 96MyD8AjY2GqsrEVKAz+vzOvSh51PlfGIpaogGytD8ENhpAqgAS9Xkn1HlLshq0A ZL/gh0JUy0mXpbSPFHra4BiX9g0fr+/heBW2EzpBYmXnCcE3fsikCfnq97KP/Igf 2FKeceYp2qCaD9GJWXsOfaKhu5rxs0Ov/xunNSKmy5EjMa0/C/IKJrxJiioQ06M= =bKhG -END PGP SIGNATURE- ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Gem and 3D printers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Is there someone who has already print object with 3D printer using Gem and obj-exporter (or something else) ? If yes, what was the process ? I am looking for a way to print a curved surface (like a wave with depth). I think, with obj-exporter, i will need a lot of obj-cube (or obj-cuboid) to make a smooth surface ? ++ Jack -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUROBEAAoJEOuluecjw8GUpIUH/jPvfijqpTuRbKVxWopj0Xhn ctKTgYsrBq3WBSIH7tI5wILxiPjO8sf5wfMaoVQVjnLyg55jsa5ql170c39JX3cK CYUkhBUWLJi+c1ykWgrrZXqfwffo/ftAQxxiGkaUkhE7N6bgCS8+PAXN+p65jnxG 96MyD8AjY2GqsrEVKAz+vzOvSh51PlfGIpaogGytD8ENhpAqgAS9Xkn1HlLshq0A ZL/gh0JUy0mXpbSPFHra4BiX9g0fr+/heBW2EzpBYmXnCcE3fsikCfnq97KP/Igf 2FKeceYp2qCaD9GJWXsOfaKhu5rxs0Ov/xunNSKmy5EjMa0/C/IKJrxJiioQ06M= =bKhG -END PGP SIGNATURE- ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
