Re: [PD] gemlist into gemframebuffer?
hello, You can use gemlist to render in a framebuffer. the examle 07.texture/11... show how to use multiple gemhead in the same framebuffer. you can do the same with gemlist. but that did not solve the problem that you receive value in between frames. I don't understand how you can render anything in between frame. are you in single buffer mode? since rendering in the frambuffer should be made at specific moment, you have to store the values (in tables), and do a loop (using repeat or until/gemlist) to render whatever you wish using this values. cheers c Le 23/03/2013 20:54, John Harrison a écrit : As I continue my conversation with myself. :-) I realize that the solution I posted doesn't work for the current problem I have: I have values coming in for where to put the spheres which come in between frames I am rendering. I don't have all of the values at once. Currently every time a new value comes in, I bang the gemlist. To do this without gemlist I need a way to store a gemstate/gpointer until the next value comes in. I can't find any way to store such a beast since it isn't supported by [pack] and there is no variable type for it. Is there some way to store the gpointer that I am missing? On Sat, Mar 23, 2013 at 2:16 PM, John Harrison mailto:john.harri...@alum.mit.edu>> wrote: Solved it by making a loop instead of using gemlist. Sorry for the noise. See attached for a demo of the solution if you are curious or if you might have a better/alternative solution. -John On Sat, Mar 23, 2013 at 11:47 AM, John Harrison mailto:john.harri...@alum.mit.edu>> wrote: I have about 100 spheres I generate with a gemlist which currently display into a gem window. I'd like to instead put them into a gemframebuffer. Is there a way to do this? It seems that gemlist is hardcoded to display in the window? I can think of workarounds i.e. make 100 abstractions of my sphere but that seems clumsy and perhaps inefficient. ___ 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] some issues with dynamic patching
On Sam, 2013-03-23 at 15:39 +0200, Alexandros Drymonitis wrote: > Concerning [loadbang] you should use [initbang] instead AFAIK. But > that's not vanilla. There are two separate issues to be considered: [initbang] should be used when you dynamically create xlets within an abstraction, so that those are created before the connections of the parent are drawn. I think what OP means is that [loadbang]s in dynamically created abstractions do not fire too late, but not at all. Whether this is a feature or a bug is not clear to me, but it is the current behavior which has been discussed many times on this list. To me this behavior actually makes sense. It allows you to first create many instances of the abstraction dynamically and only then let them loadbang by sending a 'loadbang' message to their canvasses. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Large File Support on Linux
Hi Miller, Yes I am on 32bit linux. For what I understand on 64 bits Linux LFS is out of the box. The problem stands only for 32 bits hosts it seems. I can follow a branch on git and test for you if you wish. Alternatively I recall there's debian package to host a 32 bits linux in a 64 bits linux. Thanks Charles Miller Puckette wrote: > OK... now I'm trying to fix the bug but I can't reproduce it. I made a > 5 GB soundfile (wave format, 60 channels, 4-bit floats, 450 seconds long) > and opened and am reading it using readsf~. This is on a 64 bit linux > box. > > Question for Charles Goyard: were you on a 32-bit linux machine? Or did > you do something else besides just read the file from its beginning? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] some issues with dynamic patching
Many thanks to you all, [initbang] seems just what I was looking for. As for individual, dynamic firing with [loadbang], the problem with [loadbang( | [send pd-foo.pd] is that I have several foo abstractions and I would like to fire them individually. So, by now [initbang] seems the way to go. Josep M > From: reduz...@gmail.com > To: pd-list@iem.at > Date: Sun, 24 Mar 2013 12:25:35 +0100 > Subject: Re: [PD] some issues with dynamic patching > > On Sam, 2013-03-23 at 15:39 +0200, Alexandros Drymonitis wrote: > > Concerning [loadbang] you should use [initbang] instead AFAIK. But > > that's not vanilla. > > There are two separate issues to be considered: > > [initbang] should be used when you dynamically create xlets within an > abstraction, so that those are created before the connections of the > parent are drawn. > > I think what OP means is that [loadbang]s in dynamically created > abstractions do not fire too late, but not at all. Whether this is a > feature or a bug is not clear to me, but it is the current behavior > which has been discussed many times on this list. To me this behavior > actually makes sense. It allows you to first create many instances of > the abstraction dynamically and only then let them loadbang by sending a > 'loadbang' message to their canvasses. > > 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] Large File Support on Linux
No worries I'll just go crank up an old 32 bit linux box myself :) M On Sun, Mar 24, 2013 at 04:07:12PM +0100, Charles Goyard wrote: > Hi Miller, > > Yes I am on 32bit linux. For what I understand on 64 bits Linux LFS is > out of the box. The problem stands only for 32 bits hosts it seems. > > I can follow a branch on git and test for you if you wish. > > Alternatively I recall there's debian package to host a 32 bits linux in > a 64 bits linux. > > Thanks > Charles > > > Miller Puckette wrote: > > OK... now I'm trying to fix the bug but I can't reproduce it. I made a > > 5 GB soundfile (wave format, 60 channels, 4-bit floats, 450 seconds long) > > and opened and am reading it using readsf~. This is on a 64 bit linux > > box. > > > > Question for Charles Goyard: were you on a 32-bit linux machine? Or did > > you do something else besides just read the file from its beginning? > > > ___ > 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] some issues with dynamic patching
- Original Message - > From: Roman Haefeli > To: pd-list@iem.at > Cc: > Sent: Sunday, March 24, 2013 7:25 AM > Subject: Re: [PD] some issues with dynamic patching > > On Sam, 2013-03-23 at 15:39 +0200, Alexandros Drymonitis wrote: >> Concerning [loadbang] you should use [initbang] instead AFAIK. But >> that's not vanilla. > > There are two separate issues to be considered: > > [initbang] should be used when you dynamically create xlets within an > abstraction, so that those are created before the connections of the > parent are drawn. > > I think what OP means is that [loadbang]s in dynamically created > abstractions do not fire too late, but not at all. Whether this is a > feature or a bug is not clear to me, but it is the current behavior > which has been discussed many times on this list. To me this behavior > actually makes sense. It allows you to first create many instances of > the abstraction dynamically and only then let them loadbang by sending a > 'loadbang' message to their canvasses. And in most instances it's much easier to just use [initbang] to initialize the abstraction in the way the user expects it to happen. Unless the abstraction initialization is sending a message to an outlet there is no need to manually send loadbangs. [initbang] will do the right thing here. -Jonathan > > 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] vanilla replacement for polygate~ ?
On 22/03/13 22:35, Jonathan Wilkes wrote: From: Patrick Pagano To: pd-list@iem.at Sent: Friday, March 22, 2013 3:57 PM Subject: [PD] vanilla replacement for polygate~ ? Hello I was wondering if anyone had an idea for a Vanilla replacement for polygate~, which is listed as a switch between multiple signal inputs. I would like to make a patch for IPAD/MOBmuPLat that has this in the patch but i am wondering what a good vanilla substitute might be for it? You can't. Or-- you can, but it will be a cheap imitation that either a) always has some maximum number of inlets, or b) uses nonlocal receive names to make up for the fact that you cannot dynamically instantiate inlets inside an abstraction because the [loadbang] It would be relatively easy instead if one could dynamically set the name for [send~] (like for [receive~]) in vanilla. Lorenzo. inside will only fire after the connections in the parent patch have finished. (I.e., you'll get broken connections if you save the patch and open it again.) You need [initbang] to create the [inlet]s before the parent tries to make the connections. The [initbang] object is in Pd-extended and Pd-l2ork, but not Pd-Vanilla. There is no process or plan to get it in to Pd-Vanilla, so if you are bound to using Pd Vanilla only you are quite simply stuck. -Jonathan polygate~ switch between multiple signal inputs variable fade rate both linear & equal power ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] vanilla replacement for polygate~ ?
dynamicly? Zitat von "Lorenzo Sutton" : On 22/03/13 22:35, Jonathan Wilkes wrote: From: Patrick Pagano To: pd-list@iem.at Sent: Friday, March 22, 2013 3:57 PM Subject: [PD] vanilla replacement for polygate~ ? Hello I was wondering if anyone had an idea for a Vanilla replacement for polygate~, which is listed as a switch between multiple signal inputs. I would like to make a patch for IPAD/MOBmuPLat that has this in the patch but i am wondering what a good vanilla substitute might be for it? You can't. Or-- you can, but it will be a cheap imitation that either a) always has some maximum number of inlets, or b) uses nonlocal receive names to make up for the fact that you cannot dynamically instantiate inlets inside an abstraction because the [loadbang] It would be relatively easy instead if one could dynamically set the name for [send~] (like for [receive~]) in vanilla. Lorenzo. inside will only fire after the connections in the parent patch have finished. (I.e., you'll get broken connections if you save the patch and open it again.) You need [initbang] to create the [inlet]s before the parent tries to make the connections. The [initbang] object is in Pd-extended and Pd-l2ork, but not Pd-Vanilla. There is no process or plan to get it in to Pd-Vanilla, so if you are bound to using Pd Vanilla only you are quite simply stuck. -Jonathan polygate~ switch between multiple signal inputs variable fade rate both linear & equal power ___ 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
