From rch at umail.ucsb.edu Tue Jul 3 00:29:18 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Tue Jul 3 00:29:21 2007 Subject: [Tdg] Mint meet Message-ID: <4689FACE.5040208@umail.ucsb.edu> Hi all. Does anyone know when Wes gets back? Should we wait for him, or hold this big meeting anyway? Rama From jkm at create.ucsb.edu Tue Jul 3 00:41:32 2007 From: jkm at create.ucsb.edu (JoAnn Kuchera-Morin) Date: Tue Jul 3 00:41:44 2007 Subject: [Tdg] Mint meet In-Reply-To: <4689FACE.5040208@umail.ucsb.edu> References: <4689FACE.5040208@umail.ucsb.edu> Message-ID: <5af624d7a90bc8c084441e1c2cd0b2a5@create.ucsb.edu> Hi Rama, I can meet. Just keep me posted...... On Jul 3, 2007, at 12:29 AM, Rama Hoetzlein wrote: > Hi all. Does anyone know when Wes gets back? > Should we wait for him, or hold this big meeting anyway? > > Rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > -- Dr. JoAnn Kuchera-Morin Director, Allosphere Research Laboratory Media Arts and Technology Initiatives, MAT-CNSI Media Arts and Technology, California Nanosystems Institute Professor, Graduate Program in Media Arts and Technology Professor of Composition, Department of Music Director, Center for Research in Electronic Art Technology University of California, Santa Barbara http://www.mat.ucsb.edu/allosphere http://www.mat.ucsb.edu http://www.create.ucsb.edu ? From wesley.hoke at gmail.com Tue Jul 3 01:25:42 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Tue Jul 3 01:25:53 2007 Subject: [Tdg] Mint meet In-Reply-To: <4689FACE.5040208@umail.ucsb.edu> References: <4689FACE.5040208@umail.ucsb.edu> Message-ID: <1079b050707030125kd4897edgd71740ab1a1b5f48@mail.gmail.com> I get back at the end of july. wes On 7/3/07, Rama Hoetzlein wrote: > Hi all. Does anyone know when Wes gets back? > Should we wait for him, or hold this big meeting anyway? > > Rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From ljputnam at umail.ucsb.edu Tue Jul 3 09:52:25 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Tue Jul 3 09:52:38 2007 Subject: [Tdg] Mint meet In-Reply-To: <4689FACE.5040208@umail.ucsb.edu> References: <4689FACE.5040208@umail.ucsb.edu> Message-ID: <20070703095225.z7nt0jfnwg4so40s@webaccess.umail.ucsb.edu> I think we should meet this week. Lance Rama Hoetzlein wrote: > Hi all. Does anyone know when Wes gets back? > Should we wait for him, or hold this big meeting anyway? > > Rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From brent.oster at create.ucsb.edu Tue Jul 3 09:55:53 2007 From: brent.oster at create.ucsb.edu (Brent Oster) Date: Tue Jul 3 09:56:06 2007 Subject: [Tdg] Mint meet In-Reply-To: <20070703095225.z7nt0jfnwg4so40s@webaccess.umail.ucsb.edu> Message-ID: <001501c7bd93$05738f10$6ddd6f80@AcerLaptop> My schedule is pretty open. When would you like to get together? -----Original Message----- From: tdg-bounces@mat.ucsb.edu [mailto:tdg-bounces@mat.ucsb.edu] On Behalf Of Lance J. Putnam Sent: Tuesday, July 03, 2007 9:52 AM To: tdg@mat.ucsb.edu Subject: Re: [Tdg] Mint meet I think we should meet this week. Lance Rama Hoetzlein wrote: > Hi all. Does anyone know when Wes gets back? > Should we wait for him, or hold this big meeting anyway? > > Rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu _______________________________________________ Tdg mailing list Tdg@mat.ucsb.edu http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From ljputnam at umail.ucsb.edu Tue Jul 3 10:03:43 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Tue Jul 3 10:03:56 2007 Subject: [Tdg] Mint meet In-Reply-To: <001501c7bd93$05738f10$6ddd6f80@AcerLaptop> References: <001501c7bd93$05738f10$6ddd6f80@AcerLaptop> Message-ID: <20070703100343.4e025n57sw408w8w@webaccess.umail.ucsb.edu> Thursday @ 11? Brent Oster wrote: > My schedule is pretty open. When would you like to get together? > > -----Original Message----- > From: tdg-bounces@mat.ucsb.edu [mailto:tdg-bounces@mat.ucsb.edu] On Behalf > Of Lance J. Putnam > Sent: Tuesday, July 03, 2007 9:52 AM > To: tdg@mat.ucsb.edu > Subject: Re: [Tdg] Mint meet > > I think we should meet this week. Lance > > Rama Hoetzlein wrote: > >> Hi all. Does anyone know when Wes gets back? >> Should we wait for him, or hold this big meeting anyway? >> >> Rama >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > -- > Lance Putnam > Graduate Student > Electronic Music and Sound Design > Media Arts and Technology / UCSB > ljputnam@umail.ucsb.edu > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From rch at umail.ucsb.edu Tue Jul 3 10:49:02 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Tue Jul 3 10:49:06 2007 Subject: [Tdg] Mint meet Message-ID: <468A8C0E.7010008@umail.ucsb.edu> Thurs 11 works for me. Tim recently asked for summarizing paragraphs of our projects. I've attempted a first pass for Mint: MINT is an open source interdisciplinary tool to enable new media art, digital music and scientific research in a single unified framework through a consistent, efficient programming interface for real time video, graphics, synthesized audio and external devices. MINT enables collaboration by providing central control for tools in various disciplines along with an open architecture for growth. Precise event timing, spatialized audio, network rendering, and customizable graphics widgets are available in MINT through an interface for both novice and expert developers with consistent behavior on Mac, Windows and Linux. The goal of MINT is to eliminate the technical groundwork and data connectivity necessary to engage in advanced interdisciplinary research. Any suggestions or changes? -rama From alex at neisis.net Tue Jul 3 14:10:53 2007 From: alex at neisis.net (Alex Norman) Date: Tue Jul 3 14:11:07 2007 Subject: [Tdg] Mint meet In-Reply-To: <468A8C0E.7010008@umail.ucsb.edu> References: <468A8C0E.7010008@umail.ucsb.edu> Message-ID: <20070703211053.GK10674@silverninja.net> Thurs at 11 would probably work for me.. though Wednesday is the 4th and who knows.. I'd take out the "real time", it might not be correct and doesn't quite work with "external devices". "MINT enables collaboration by providing central control for tools in various disciplines along with an open architecture for growth." "central control"? what is that? .. I don't understand this sentence. besides that it looks pretty good to me. ('cept I'd put Linux first in the list :) ) -Alex On 0, Rama Hoetzlein wrote: > Thurs 11 works for me. > > Tim recently asked for summarizing paragraphs of our projects. > > I've attempted a first pass for Mint: > > MINT is an open source interdisciplinary tool to enable new media art, > digital music and scientific research in a single unified framework > through a consistent, efficient programming interface for real time > video, graphics, synthesized audio and external devices. MINT enables > collaboration by providing central control for tools in various > disciplines along with an open architecture for growth. Precise event > timing, spatialized audio, network rendering, and customizable graphics > widgets are available in MINT through an interface for both novice and > expert developers with consistent behavior on Mac, Windows and Linux. > The goal of MINT is to eliminate the technical groundwork and data > connectivity necessary to engage in advanced interdisciplinary research. > > Any suggestions or changes? > > -rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Tue Jul 3 16:09:14 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Tue Jul 3 16:09:25 2007 Subject: [Tdg] Mint meet thursday Message-ID: <468AD71A.4090400@umail.ucsb.edu> Ok.. Meeting is set for Thurs, 11am in CNSI 2nd fl. conference room. Open discussion to determine cross-disciplinary end of summer goals for Mint. Rama From stp at HeavenEverywhere.com Tue Jul 3 21:23:57 2007 From: stp at HeavenEverywhere.com (Stephen Travis Pope) Date: Tue Jul 3 21:24:14 2007 Subject: [SPAM] Re: [Tdg] Mint meet In-Reply-To: <20070703211053.GK10674@silverninja.net> References: <468A8C0E.7010008@umail.ucsb.edu> <20070703211053.GK10674@silverninja.net> Message-ID: <3B8EABB7-426F-4956-B940-576B94A2D24A@HeavenEverywhere.com> Thursday at 11 -- AOK by me -- where? About the description, I'd use the word "multimedia" early in the 1st sentence so it's obvious what it is, i.e., change "open source interdisciplinary tool" to "framework for developing multimedia software" -- I guess I don't know what an interdisciplinary tool is, and if a piece of software only has "open source" going for it, then I know it's not worth much. Mint is a framework, or a development/ delivery environment, or a comprehensive set of reusable software components and APIs (i.e., use all these phrases in the description). stp -- Stephen Travis Pope -- Santa Barbara, California, USA http://HeavenEverywhere.com http://FASTLabInc.com -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.tiff Type: image/tiff Size: 2442 bytes Desc: not available Url : http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070703/d9f16298/pastedGraphic-0001.tiff -------------- next part -------------- On Jul 3, 2007, at 2:10 PM, Alex Norman wrote: >> I've attempted a first pass for Mint: >> >> MINT is an open source interdisciplinary tool to enable new media >> art, >> digital music and scientific research in a single unified framework >> through a consistent, efficient programming interface for real time >> video, graphics, synthesized audio and external devices. MINT enables >> collaboration by providing central control for tools in various >> disciplines along with an open architecture for growth. Precise event >> timing, spatialized audio, network rendering, and customizable >> graphics >> widgets are available in MINT through an interface for both novice >> and >> expert developers with consistent behavior on Mac, Windows and Linux. >> The goal of MINT is to eliminate the technical groundwork and data >> connectivity necessary to engage in advanced interdisciplinary >> research. >> >> Any suggestions or changes? >> >> -rama >> From stp at HeavenEverywhere.com Tue Jul 3 21:33:40 2007 From: stp at HeavenEverywhere.com (Stephen Travis Pope) Date: Tue Jul 3 21:33:56 2007 Subject: [Tdg] Mint meeting (off-topic) In-Reply-To: <46833232.5030900@umail.ucsb.edu> References: <46833232.5030900@umail.ucsb.edu> Message-ID: <9131FF29-6AF6-4891-8D3F-321CC33795F3@HeavenEverywhere.com> Hi guys, I read this note, and just wanted to offer to talk with either or both of you about it. I'm cc'ing Tobias so that he's in the loop as the other "long-term" MINT team advisor. I like all of you very much, and appreciate the personal strength that each of you bring to the team, so it's distressing to learn of problems between team members. (Distressing, yes, rare, no) In a professional sense, as far as the MINT team operation goes, no Rama, you do not have the right to ask us to accommodate your not working with another one of the core team members. I can certainly say that, from my perspective, it is not in the interest of the MINT group to limit your involvement with Graham at all. If I can offer my services as a trained mediator, I'd be happy to help, but for the MINT team, we all work together, and I would ask you to keep your personal issues out of our work environment. I expect you both to participate in the meeting on Thursday. stp -- Stephen Travis Pope -- Santa Barbara, California, USA http://HeavenEverywhere.com http://FASTLabInc.com -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.tiff Type: image/tiff Size: 2442 bytes Desc: not available Url : http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070703/22c21a84/pastedGraphic.tiff -------------- next part -------------- On Jun 27, 2007, at 8:59 PM, Rama Hoetzlein wrote: > [...] > > On another note, there are personal reasons why I won't work with > Graham now. I am asking for all of your help on maintaining good > group communication and future direction of the project while > helping to limit my involvement with Graham. > > [...] > From rch at umail.ucsb.edu Wed Jul 4 01:12:02 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Wed Jul 4 01:12:18 2007 Subject: [Tdg] Mint meeting (off-topic) In-Reply-To: <9131FF29-6AF6-4891-8D3F-321CC33795F3@HeavenEverywhere.com> References: <46833232.5030900@umail.ucsb.edu> <9131FF29-6AF6-4891-8D3F-321CC33795F3@HeavenEverywhere.com> Message-ID: <468B5652.7090708@umail.ucsb.edu> > I can certainly say that, from my perspective, it is not in the > interest of the MINT group to limit your involvement with Graham at all. I agree that Mint will struggle with this temporarily. However, for my own sake it is necessary at this point. My request was a personal one to the group, which i think is a valid thing to ask.. When is work not also something personal. I regret that it became visible, but occassionally it does. I will not work (as much as possible) with those I can't trust, and that trust between us has been broken. But I do believe that we have developed a very strong project together, and I believe through group effort this need not be an issue. > I expect you both to participate in the meeting on Thursday. I had expected nothing less myself. I believe everyone should be as involved as they wish. I do not wish to limit anyone's involvement.. I had mentioned earlier to some that I will participate with Graham as much as I am capable and willing, and especially as needed in required joint meetings, publications, and presentations. I feel challenges are dealt with by doing the best job one is capable of under the circumstances, and I feel I am doing that. Sincerely, Rama From rch at umail.ucsb.edu Wed Jul 4 01:25:45 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Wed Jul 4 01:25:58 2007 Subject: [SPAM] Re: [Tdg] Mint meet In-Reply-To: <3B8EABB7-426F-4956-B940-576B94A2D24A@HeavenEverywhere.com> References: <468A8C0E.7010008@umail.ucsb.edu> <20070703211053.GK10674@silverninja.net> <3B8EABB7-426F-4956-B940-576B94A2D24A@HeavenEverywhere.com> Message-ID: <468B5989.7030104@umail.ucsb.edu> > > About the description, I'd use the word "multimedia" early in the 1st > sentence so it's obvious what it is, i.e., change "open source > interdisciplinary tool" to "framework for developing multimedia > software" -- I guess I don't know what an interdisciplinary tool is, > and if a piece of software only has "open source" going for it, then > I know it's not worth much. An interdisciplinary tool is one that enables work in multiple disciplines. I believe Mint is more than just a framework for multimedia software, as its goal is also to support research in other fields where multimedia may not be the primary factor - e.g. one could run Mint without any multimedia interface as a server for doing some calculation on data. However, i agree multimedia definitely should be included somewhere as that is one of its goals.. Anyone else have input on this? I don't think the exact wording is so critical, but I would like to see "interdisciplinary" mentioned. Rama From ljputnam at umail.ucsb.edu Wed Jul 4 10:24:37 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Wed Jul 4 10:24:48 2007 Subject: [SPAM] Re: [Tdg] Mint meet In-Reply-To: <3B8EABB7-426F-4956-B940-576B94A2D24A@HeavenEverywhere.com> References: <468A8C0E.7010008@umail.ucsb.edu> <20070703211053.GK10674@silverninja.net> <3B8EABB7-426F-4956-B940-576B94A2D24A@HeavenEverywhere.com> Message-ID: <20070704102437.1ywh9ya1440osw48@webaccess.umail.ucsb.edu> Stephen Travis Pope wrote: > > Thursday at 11 -- AOK by me -- where? > > About the description, I'd use the word "multimedia" early in the 1st > sentence so it's obvious what it is, i.e., change "open source > interdisciplinary tool" to "framework for developing multimedia > software" I agree. Multimedia by its nature is interdisciplinary. It's also a more specific term. > Mint is a framework, or a development/ > delivery environment, or a comprehensive set of reusable software > components and APIs (i.e., use all these phrases in the description). I think it would be wise to mention modularity. Can one use Mint's components individually (e.g. networking, timers)? Lance -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From wesley.hoke at gmail.com Wed Jul 4 10:35:47 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Jul 4 10:35:55 2007 Subject: [SPAM] Re: [Tdg] Mint meet In-Reply-To: <468B5989.7030104@umail.ucsb.edu> References: <468A8C0E.7010008@umail.ucsb.edu> <20070703211053.GK10674@silverninja.net> <3B8EABB7-426F-4956-B940-576B94A2D24A@HeavenEverywhere.com> <468B5989.7030104@umail.ucsb.edu> Message-ID: <1079b050707041035w179144c5i4e56cd75df9cb363@mail.gmail.com> I would agree that multimedia needs to be in there and that realtime, although one of our main things, is not necessarily a major thing. More important is precise timing. As for the "central control", it is probably too rough of a description of the structure of Mint for anyone aside from us to know what it means. Perhaps something along the lines of "MINT enables collaboration by interconnecting tools in various disciplines through its modular architecture and generalized event passing system." wes On 7/4/07, Rama Hoetzlein wrote: > > > > > About the description, I'd use the word "multimedia" early in the 1st > > sentence so it's obvious what it is, i.e., change "open source > > interdisciplinary tool" to "framework for developing multimedia > > software" -- I guess I don't know what an interdisciplinary tool is, > > and if a piece of software only has "open source" going for it, then > > I know it's not worth much. > > An interdisciplinary tool is one that enables work in multiple disciplines. > I believe Mint is more than just a framework for multimedia software, as > its goal is also to support research in other fields where multimedia > may not be the primary factor - e.g. one could run Mint without any > multimedia interface as a server for doing some calculation on data. > However, i agree multimedia definitely should be included somewhere as > that is one of its goals.. Anyone else have input on this? I don't think > the exact wording is so critical, but I would like to see > "interdisciplinary" mentioned. > > Rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From mail at grahamwakefield.net Thu Jul 5 12:32:48 2007 From: mail at grahamwakefield.net (Graham Wakefield) Date: Thu Jul 5 12:32:57 2007 Subject: [Tdg] Mint summer meet 1 Message-ID: <7C85795D-84A7-406C-A3DE-A3301DD8464C@grahamwakefield.net> Here are the notes I took from today, for the benefit of Wes & Dan etc: IGERT SUMMER MEET 01 Meet with JoAnn, Tobias, Stephen, Brent, Alex, Rama, Lance, Me HCI: multi-modal content driving technology MINT: we know what that is 594P: shorter term demo for sphere State of progress: - event model is designed, but not implemented - subsystems identified, but not implemented - network/distribution: conceptualized, not implemented. ALL: Discussion of different rendering frameworks & packages. Everyone in favor of modular / component / plugin architecture. RH: Distributed rendering 1-to-many by the end of Summer - not large data chunks, but control synchronization. TH: Need to identify demo applications. JKM: Visualization (Fluid dynamics, VMD, KITP, Allobrain, Biotech, MRI, Nano-electron stucture...) BO - good short term targets - make easy to plug in : Model visualization - Maya content - Molecular models Volume visualization - MRI - Fluid dynamics - Nano electron structure Then add control & audio. TH: Can use Amira to support many of the strange scientific data formats out there. Have (some) access to source, but hard code to leverage (very complex). LP: Ad-hoc approach has been fine for a while but not scalable; we need design philosophy, solid principle, emphasize modularity JKM/TH: need hardware configuration. LP: Audio easier to scale than graphics - not really a problem at that level. BO: Hardware config: HP's can drive two projectors, or can drive through an external Dell Quadruplex box to four graphics Quaddro 5600 cards to drive 8 projectors. NVidia also have CUDA Tesla box which we could consider for computing power - BO is asking to give us one - an experimental option. End of summer is a quad-display, but we'll also need to deal with vertex shader to adapt for spherical display (plus in stereographic). TH has a researcher interested in this, but not sure how it will pan out. STP: Every app is a list of services (graphics, audio, control etc), a control manager and a database server, the CRAM model. This one- button ability to configure, test and run Sphere apps would be great. Languages: C++ (minimal Obj-C just for some OSX-specific bits), optional scripting langauge support (SWIG, Python, Lua etc. ) LP: Goal to create a composition, graphics driven by audio. Good test of system! Further discussion about hardware, including welding etc. From rch at umail.ucsb.edu Thu Jul 5 16:22:17 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Thu Jul 5 16:22:28 2007 Subject: [Tdg] Igert meets Message-ID: <468D7D29.5060201@umail.ucsb.edu> In regards to Tim's last e-mail, next week I am not speaking about Mint but my own research. Tim asked if we would be interested in presenting some Mint-related work later in the month. I said it should be a problem. However, this is really a group decision (I should have said i'll ask the group). Is anyone else interested in presenting Mint-related work at an Igert meeting? Since most have already heard the Mint overview, this could be an opportunity to discuss our goals with more specific individual research. For example, I wouldn't mind mentioning some of the issues associated with network rendering. rama From rch at umail.ucsb.edu Fri Jul 6 12:31:46 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Fri Jul 6 12:31:54 2007 Subject: [Tdg] Igert meets In-Reply-To: <468D7D29.5060201@umail.ucsb.edu> References: <468D7D29.5060201@umail.ucsb.edu> Message-ID: <468E98A2.5030909@umail.ucsb.edu> > I said it should be a problem. However, this is really a group > decision (I should have said i'll ask the group). Sorry.. I meant "shouldn't" : ) rama > > Is anyone else interested in presenting Mint-related work at an Igert > meeting? > Since most have already heard the Mint overview, this could be an > opportunity to discuss our goals with more specific individual > research. For example, I wouldn't mind mentioning some of the issues > associated with network rendering. > > rama > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From stp at HeavenEverywhere.com Fri Jul 6 13:00:35 2007 From: stp at HeavenEverywhere.com (Stephen Travis Pope) Date: Fri Jul 6 13:00:52 2007 Subject: [SPAM] Re: [Tdg] Igert meets In-Reply-To: <468E98A2.5030909@umail.ucsb.edu> References: <468D7D29.5060201@umail.ucsb.edu> <468E98A2.5030909@umail.ucsb.edu> Message-ID: <77682A1F-4BE1-4AC7-9928-0FDDC6DDBC9F@HeavenEverywhere.com> I think that an IGERT seminar on the MINT design issues would be great! stp -- Stephen Travis Pope -- Santa Barbara, California, USA http://HeavenEverywhere.com http://FASTLabInc.com -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.tiff Type: image/tiff Size: 2442 bytes Desc: not available Url : http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070706/c2e7e9c9/pastedGraphic.tiff -------------- next part -------------- On Jul 6, 2007, at 12:31 PM, Rama Hoetzlein wrote: > >> I said it should be a problem. However, this is really a group >> decision (I should have said i'll ask the group). > > Sorry.. I meant "shouldn't" : ) > > rama > >> >> Is anyone else interested in presenting Mint-related work at an >> Igert meeting? >> Since most have already heard the Mint overview, this could be an >> opportunity to discuss our goals with more specific individual >> research. For example, I wouldn't mind mentioning some of the >> issues associated with network rendering. >> >> rama >> >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From rch at umail.ucsb.edu Mon Jul 9 11:46:48 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Mon Jul 9 12:06:04 2007 Subject: [Tdg] Graphics design Message-ID: <46928298.2080303@umail.ucsb.edu> I spent the weekend organizing my design notes for the graphics system. Attached is the resulting Excel spreadsheet. It includes notes on: - Graphics class hierarchy - Graphics events - Display configurations - Startup usage - Two case studies - Open questions - Differences with Chromium The open questions are probably of most importance to the group, since there are several issues which may impact general event handling. Some examples: 1. Memory pooling blocks of events 2. Handling blocks of events on queues 3. How to block user code while sub-systems start up 4. Multiplexing events. When do they get deleted? 5. Network transmission of events (will sub-systems have different ports?) 6. Ordering of events. Is this guaranteed? How do we guarantee when needed? The case studies are helpful as they show how system could actually operate. Comments welcome. -rama -------------- next part -------------- A non-text attachment was scrubbed... Name: render-design.xls Type: application/vnd.ms-excel Size: 53760 bytes Desc: not available Url : http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070709/b3d271a5/render-design-0001.xls From rch at umail.ucsb.edu Mon Jul 9 12:07:07 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Mon Jul 9 12:07:10 2007 Subject: [Tdg] References Message-ID: <4692875B.9040601@umail.ucsb.edu> Relevant papers on cluster rendering: http://graphics.stanford.edu/papers/wiregl/clust_papi.pdf http://graphics.stanford.edu/papers/mural_design/mural_design.pdf http://graphics.stanford.edu/papers/state_tracking/state_tracking.pdf http://graphics.stanford.edu/papers/clust_render/clust_render.pdf -R From rch at umail.ucsb.edu Mon Jul 9 13:26:51 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Mon Jul 9 13:26:58 2007 Subject: [Tdg] Nice comparison Message-ID: <46929A0B.5060206@umail.ucsb.edu> This is a really good comparison of OpenSG, Chromium, and VRJuggler for cluster rendering: http://graphics.cs.ucdavis.edu/~staadt/download/Staadt_EGVE03.pdf Figure 11 compares performance on dynamic data over a cluster. -R From ljputnam at umail.ucsb.edu Tue Jul 10 17:34:16 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Tue Jul 10 17:34:28 2007 Subject: [Tdg] Nice comparison In-Reply-To: <46929A0B.5060206@umail.ucsb.edu> References: <46929A0B.5060206@umail.ucsb.edu> Message-ID: <20070710173416.j5u0kxb28w0gwc40@webaccess.umail.ucsb.edu> Quick thought: how much bandwidth does it take to stream our raw sample data? Graphics: 1024 x 768 [px/f] x 40 [f/s] x 32 [bits/px] = 1,006,632,960 bits/s Audio: 44100 [sm/s] x 32 [bits/sm] = 1,411,200 bits/s Therefore, driving one graphics display is like streaming ~1,000 channels of audio. If we can figure out how to stream one graphics display's pixel frame buffer, then all of our audio problems are solved. Lance Rama Hoetzlein wrote: > This is a really good comparison of OpenSG, Chromium, and VRJuggler for > cluster rendering: > > http://graphics.cs.ucdavis.edu/~staadt/download/Staadt_EGVE03.pdf > > Figure 11 compares performance on dynamic data over a cluster. > > -R > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From ljputnam at umail.ucsb.edu Tue Jul 10 18:00:43 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Tue Jul 10 18:00:55 2007 Subject: [Tdg] Graphics design In-Reply-To: <46928298.2080303@umail.ucsb.edu> References: <46928298.2080303@umail.ucsb.edu> Message-ID: <20070710180043.3tbwqhbysogc0sw8@webaccess.umail.ucsb.edu> Wow, very thorough plan. I have just a few questions: Under Device, what is the difference btw Linux and Win GL? Isn't GL cross platform? What about OS X? If a Display is an abstraction of a monitor, then why does it need to know about DX or GL? What purpose do the WinArray* classes serve? The GraphicsSystem already has a vector of windows. Lance Rama Hoetzlein wrote: > I spent the weekend organizing my design notes for the graphics system. > > Attached is the resulting Excel spreadsheet. > > It includes notes on: > - Graphics class hierarchy > - Graphics events > - Display configurations > - Startup usage > - Two case studies > - Open questions > - Differences with Chromium > > The open questions are probably of most importance to the group, since > there are several issues which may impact general event handling. > Some examples: > 1. Memory pooling blocks of events > 2. Handling blocks of events on queues > 3. How to block user code while sub-systems start up > 4. Multiplexing events. When do they get deleted? > 5. Network transmission of events (will sub-systems have different ports?) > 6. Ordering of events. Is this guaranteed? How do we guarantee when needed? > > The case studies are helpful as they show how system could actually operate. > Comments welcome. > > -rama -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From ljputnam at umail.ucsb.edu Tue Jul 10 18:05:20 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Tue Jul 10 18:05:31 2007 Subject: [Tdg] References In-Reply-To: <4692875B.9040601@umail.ucsb.edu> References: <4692875B.9040601@umail.ucsb.edu> Message-ID: <20070710180520.am7osxpzc40gsocc@webaccess.umail.ucsb.edu> Here's another: http://www.equalizergraphics.com/documents/WhitePapers/ParallelRenderingSystems.pdf The author has his own framework for distributed rendering called Equalizer. http://www.equalizergraphics.com/index.html Lance Rama Hoetzlein wrote: > Relevant papers on cluster rendering: > > http://graphics.stanford.edu/papers/wiregl/clust_papi.pdf > http://graphics.stanford.edu/papers/mural_design/mural_design.pdf > http://graphics.stanford.edu/papers/state_tracking/state_tracking.pdf > http://graphics.stanford.edu/papers/clust_render/clust_render.pdf > > -R > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From ljputnam at umail.ucsb.edu Tue Jul 10 19:08:38 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Tue Jul 10 19:08:50 2007 Subject: [Tdg] content brainstorm Message-ID: <20070710190838.zux9m3p40ksko4s4@webaccess.umail.ucsb.edu> Hello, I just had an idea for a pilot application using Mint that I believe will challenge many aspects of the system and hopefully lead to some new insights. The idea is to interact with the following mathematical equation: x[n+1] = x[n] * c % 2^64 where x[0] != 0 and c is odd. This is the simplest and most elegant computational algorithm I have found that leads to highly complex output. It is a special case of what is known in mathematics as a multiplicative linear congruential generator. They have been extensively studied for pseudo-random number generation. In C, the algorithm would look something like this: unsigned long long x = 1; // intial value unsigned long long c = 3; // multiplier x *= c; // iterate... The challenge would be to develop some sort of intuition about the equation by perceiving it through visualization, sonification, and haptics and to control the perceptual mappings with physical sensing. The reason I like this idea is because it is really easy to explain to someone and its implications cross many disciplines. And also, because I think it's interesting. Comments? Lance -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From rch at umail.ucsb.edu Tue Jul 10 20:54:10 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Tue Jul 10 20:54:22 2007 Subject: [Tdg] Graphics design In-Reply-To: <20070710180043.3tbwqhbysogc0sw8@webaccess.umail.ucsb.edu> References: <46928298.2080303@umail.ucsb.edu> <20070710180043.3tbwqhbysogc0sw8@webaccess.umail.ucsb.edu> Message-ID: <46945462.3070204@umail.ucsb.edu> > Under Device, what is the difference btw Linux and Win GL? Isn't GL > cross platform? What about OS X? OpenGL is sort of cross-platform. You have to start the OpenGL context differently on Linux, Windows and OS X... Therefore, there is a DeviceWinGL, DeviceLinuxGL, DeviceMacGL -- these are the platform-specific contexts for the OpenGL device.. However, once its started, then you can use OpenGL cross-platform. Thus there is only one RenderGL. So.. - Multiple DeviceGLs for starting OpenGL contexts on different platform - One RenderGL because OpenGL is cross-platform > If a Display is an abstraction of a monitor, then why does it need to > know about DX or GL? Display is an abstraction, but the sub-classes are not. Each sub-classed display connects to a device with the technique suitable to it. For example, in DirectX you connect to a display by specifying its backbuffer to the DirectX Device.. Thus, the DisplayDX holds the handle to the DX backbuffer. (for OpenGL i think its a handle?). When you call the abstract Display::Connect function, all this is handled internally by the sub-classes. > What purpose do the WinArray* classes serve? The GraphicsSystem > already has a vector of windows. The WinArray treats windows as a spatially-cohesive group. It allows windows to nest in an array. Say you want to have a client with a single window, which is driving a windowed array over a network - where the large tiled array is set to mirror the smaller display (our most common scenario). With a flat list of windows this is not possible because the system cannot distinguish the source window from the tiled array. You need a WinArray which holds sub-windows to allow for this configuration. (WinArray also does specific things like clip and multiplex draw events to its sub-windows.) Then you can do: GraphicsSystem WinSingle WinArray WinClient WinClient WinSingle WinSingle Now that I found that comparison paper on OpenSG, Chromium and VRJuggler, the details of streaming graphics events are all subject to change (actually, everything is until its coded)... The approach in the design I sent out is a Chromium-type client-server approach.. I'm rethinking the issues to possibly allow for others. This only affects the Render classes. The Device, Display and Window connectivity - including automatic network detection - is the stuff I'm most certain of currently (relatively speaking). -R > > Lance > > Rama Hoetzlein wrote: > >> I spent the weekend organizing my design notes for the graphics system. >> >> Attached is the resulting Excel spreadsheet. >> >> It includes notes on: >> - Graphics class hierarchy >> - Graphics events >> - Display configurations >> - Startup usage >> - Two case studies >> - Open questions >> - Differences with Chromium >> >> The open questions are probably of most importance to the group, since >> there are several issues which may impact general event handling. >> Some examples: >> 1. Memory pooling blocks of events >> 2. Handling blocks of events on queues >> 3. How to block user code while sub-systems start up >> 4. Multiplexing events. When do they get deleted? >> 5. Network transmission of events (will sub-systems have different >> ports?) >> 6. Ordering of events. Is this guaranteed? How do we guarantee when >> needed? >> >> The case studies are helpful as they show how system could actually >> operate. >> Comments welcome. >> >> -rama > > > > From jkm at create.ucsb.edu Wed Jul 11 11:37:20 2007 From: jkm at create.ucsb.edu (JoAnn Kuchera-Morin) Date: Wed Jul 11 11:37:32 2007 Subject: [Tdg] content brainstorm In-Reply-To: <20070710190838.zux9m3p40ksko4s4@webaccess.umail.ucsb.edu> References: <20070710190838.zux9m3p40ksko4s4@webaccess.umail.ucsb.edu> Message-ID: Hi Lance, This sounds interesting, If you want to meet and discuss further, let me know.... On Jul 10, 2007, at 7:08 PM, Lance J. Putnam wrote: > Hello, > > I just had an idea for a pilot application using Mint that I believe > will challenge many aspects of the system and hopefully lead to some > new insights. > > The idea is to interact with the following mathematical equation: > > x[n+1] = x[n] * c % 2^64 > > where x[0] != 0 and c is odd. > > This is the simplest and most elegant computational algorithm I have > found that leads to highly complex output. It is a special case of > what is known in mathematics as a multiplicative linear congruential > generator. They have been extensively studied for pseudo-random > number generation. > > In C, the algorithm would look something like this: > > unsigned long long x = 1; // intial value > unsigned long long c = 3; // multiplier > x *= c; // iterate... > > The challenge would be to develop some sort of intuition about the > equation by perceiving it through visualization, sonification, and > haptics and to control the perceptual mappings with physical sensing. > > The reason I like this idea is because it is really easy to explain to > someone and its implications cross many disciplines. And also, > because I think it's interesting. > > Comments? > > Lance > > -- > Lance Putnam > Graduate Student > Electronic Music and Sound Design > Media Arts and Technology / UCSB > ljputnam@umail.ucsb.edu > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > -- Dr. JoAnn Kuchera-Morin Director, Allosphere Research Laboratory Media Arts and Technology Initiatives, MAT-CNSI Media Arts and Technology, California Nanosystems Institute Professor, Graduate Program in Media Arts and Technology Professor of Composition, Department of Music Director, Center for Research in Electronic Art Technology University of California, Santa Barbara http://www.mat.ucsb.edu/allosphere http://www.mat.ucsb.edu http://www.create.ucsb.edu ? From rch at umail.ucsb.edu Thu Jul 12 16:58:22 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Thu Jul 12 16:58:31 2007 Subject: [Tdg] content brainstorm In-Reply-To: <20070710190838.zux9m3p40ksko4s4@webaccess.umail.ucsb.edu> References: <20070710190838.zux9m3p40ksko4s4@webaccess.umail.ucsb.edu> Message-ID: <4696C01E.6070506@umail.ucsb.edu> Not sure I see how this would translate into a good 3D cluster rendering test, considering that it is a 1D function with random spatial characteristics (these equations are used as random number generators i believe). While easy to explain, I'm not sure its easy to predict or evaluate for initial testing. I like how the comparison paper used Conway's "Game of Life", because its also easy to implement and explain, plus, by rendering a simple sphere at every active cell it is easy with that system to measure the expected bandwith. Also, with Conway's game we could compare to what they already found. Rama Lance J. Putnam wrote: > Hello, > > I just had an idea for a pilot application using Mint that I believe > will challenge many aspects of the system and hopefully lead to some > new insights. > > The idea is to interact with the following mathematical equation: > > x[n+1] = x[n] * c % 2^64 > > where x[0] != 0 and c is odd. > > This is the simplest and most elegant computational algorithm I have > found that leads to highly complex output. It is a special case of > what is known in mathematics as a multiplicative linear congruential > generator. They have been extensively studied for pseudo-random > number generation. > > In C, the algorithm would look something like this: > > unsigned long long x = 1; // intial value > unsigned long long c = 3; // multiplier > x *= c; // iterate... > > The challenge would be to develop some sort of intuition about the > equation by perceiving it through visualization, sonification, and > haptics and to control the perceptual mappings with physical sensing. > > The reason I like this idea is because it is really easy to explain > to someone and its implications cross many disciplines. And also, > because I think it's interesting. > > Comments? > > Lance > From ljputnam at umail.ucsb.edu Thu Jul 12 18:26:42 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Thu Jul 12 18:26:55 2007 Subject: [Tdg] content brainstorm Message-ID: <20070712182642.s6swh09gcggcwcog@webaccess.umail.ucsb.edu> Well, the research problem is actually finding a form that is "random" enough statistically. Many outputs display chaotic and dimensionally correlated behavior. It's also a trivial task to make a 1-D function N-D by a technique called lagging. You basically use delayed versions of the output for the other dimensions. I should have been more clear when I mentioned challenging the system. I was mainly thinking in terms of high-bandwidth streaming, strict application state synchronization and orchestration of multiple modalities. BTW, here are the bit patterns of the first 100 iterations of x*=3 to show its not so random output. $ $$ $ $ $$ $$ $ $ $ $$$$ $$ $ $$ $$ $ $ $ $ $$ $$ $$ $ $ $ $$ $$$ $$ $$$ $$ $ $ $ $ $ $ $$ $$$$$$$ $$ $ $$ $$$$$$ $ $$ $ $ $$$$ $ $$ $ $ $$$$$ $$ $$$$ $ $$ $$ $ $$$$ $ $$ $ $$ $ $ $ $$ $ $$$ $ $ $$$$ $$ $ $ $ $$$ $$ $ $$$ $ $$$$ $ $ $ $ $ $ $ $ $ $$ $ $$ $$$$ $$ $$ $$ $$$$$$ $ $ $$ $$$ $ $ $ $$ $$$$ $$$$$ $ $ $ $ $$ $$ $$$ $ $$$ $$$ $ $$$$$ $$ $ $ $ $$$$ $ $$ $ $$$$ $$$ $ $ $ $$ $ $$$ $ $$$ $ $$$ $$$ $ $$ $ $ $ $$ $ $ $$ $ $ $ $ $ $$ $ $ $$$$$$ $ $$ $ $$$$$$$$$$ $ $ $$ $$$ $$$$ $$$$ $ $$$ $$$$$$$$ $$$ $$ $ $ $$ $$$ $$ $ $$ $ $$ $$$$$$$ $$ $ $$$$$ $$ $ $$ $ $ $ $$ $$$$$ $$ $ $$ $ $$$ $$ $ $$$ $$$$ $ $ $$$$ $ $$$ $ $ $$ $$$ $ $ $ $ $$ $ $$$$$ $$ $ $ $ $ $$ $$ $ $ $ $ $ $$$$$$$ $ $$$$ $$$$$ $ $ $ $$$ $$$$$$$$$ $$$$$ $ $$ $ $$ $ $ $$$ $$$ $$ $$$ $$ $$$$$$$$ $$$ $$$$ $$ $ $$ $ $ $ $ $ $$ $$ $$$$$$ $$ $$ $$ $$ $ $$ $ $ $$$$ $$ $$ $ $ $ $ $$$$$ $ $$ $ $ $$$ $ $$$ $$ $$ $ $ $$ $$$$$$$ $$$ $ $$ $ $$$ $ $ $ $$ $ $ $ $ $ $$$ $$ $ $ $ $$$$$$ $$ $$$$ $ $$$ $ $$$$$$$$$$$ $ $ $$ $ $$$ $$$$ $$ $ $ $$$ $ $$$ $ $$$$$$$$$$ $ $$ $ $ $ $ $$$ $ $$ $ $ $ $ $ $ $ $$$$$$$$ $ $ $ $$$$$ $ $ $ $ $$$ $$$$ $$ $$$$ $$ $ $$$$$$ $$$ $$ $$ $$$ $$$ $$$$$$ $ $ $$ $$$ $$ $$$ $ $$$$$ $ $ $ $ $ $ $$ $ $$ $$$$ $$ $ $ $ $ $ $ $ $$ $ $$$ $ $$$$ $$ $$$$ $$ $$ $ $$$ $ $$ $$$$$$$$$ $$ $$ $$$ $ $$$ $ $ $$$ $ $ $$ $ $ $$$$$$$ $ $ $ $ $ $ $ $ $$$ $ $ $$ $$$ $ $$$$$$ $ $$$$$ $$$$$ $$$ $$ $$$$ $$$ $ $$$$$$ $ $$ $$$$ $$ $$$$ $$$$ $ $ $ $ $$$ $ $ $ $$$$ $ $$ $ $ $$$ $ $ $$ $$ $$ $ $$$$$$$$$ $ $ $$$$ $$ $ $$$ $ $$$ $ $ $ $ $ $ $$$$$$$$ $$ $ $ $ $ $ $$ $ $ $$$$$$ $$ $$ $$ $ $$$$$$ $ $ $$$ $$$$ $$$$ $ $ $$$$$ $$$$ $ $ $ $ $$ $$$$ $$$ $$$ $$ $$ $ $ $$ $ $$ $$ $$$$ $$ $$$ $$$$ $$ $ $ $ $$$ $ $ $ $$ $$ $ $ $ $ $$ $$ $ $$ $$$ $$$$ $ $$ $ $ $$$ $$ $$ $$ $ $$$$ $$ $ $ $ $$ $ $ $ $$$$$ $ $ $ $ $ $$ $ $ $ $$ $$ $ $$$ $$ $$ $ $$$ $$$$$ $$ $$$$$ $ $$ $ $$$ $ $ $$ $ $ $ $ $$ $$$ $$ $ $$$ $$ $ $$ $ $ $ $ $ $$$$ $$ $$ $ $$ $$ $$$$ $$ $ $$ $ $$$$$$$ $$ $ $$$ $$ $$$$ $ $ $ $$$ $ $$ $ $ $$$ $$$$$ $ $ $ $$ $ $ $ $ $$ $$ $$$ $ $ $ $$$ $$$ $$ $$ $$$ $$$ $$ $$ $ $$$$$$$$$$ $ $ $ $$$ $$$$$ $ $$ $$ $ $$ $$ $$ $ $$$$ $$$$$$$$ $$$ $$$ $ $ $ $$$$ $ $ $$ $ $$ $ $$ $ $$$ $$$$$$$ $$ $ $ $$$$$ $$ $ $$ $$$ $ $$ $ $$ $ $ $$ $$$$$ $$ $ $$$$$ $$$ $ $ $$$ $ $$ $ $ $$ $$$$ $ $$ $ $ $$$$ $$ $$$$ $ $$$$$$ $ $$$$ $ $ $$ $ $$$ $ $$ $$$ $$ $ $ $ $ $$ $$ $$$$$ $$ $$$ $$ $ $ $$ $$ $$ $$$$$$ $ $ $ $$$ $ $ $ $ $ $ $ $$ $ $ $ $ $ $ $$$$ $ $$ $ $ $$$ $$$$ $$$$ $$ $$ $ $$ $$ $$$$ $ $$ $$$ $ $$$ $ $$ $$$ $$ $ $ $ $ $ $ $ $$ $$$ $ $ $ $ $$$ $ $ $$ $ $$ $ $$ $$$$$$$ $$ $$$$$$$ $ $ $ $$$$$ $ $$$$$$ $$$$ $ $$ $$$$$ $$ $ $ $$$$$ $$$ $$$$$ $$$ $ $ $$$$ $$ $$ $$$ $ $ $$$$ $ $$ $$$$ $$ $$$$ $ $$$ $$ $ $$$ $ $ $ $ $$$$$ $$ $ $ $ $ $$ $$ $$ $$ $$ $ $$ $ $ $ $$ $$ $$$$$ $$$$ $$$$$ $$ $ $$ $ $ $ $ $$$ $ $ $ $$$$ $$ $ $ $$$ $ $ $ $$ $ $$$ $$ $$$$ $ $ $ $$ $$ $$$ $$ $$ $ $ $$$$$ $$ $ $$$$ $$ $$ $$ $$ $ $ $ $$ $ $$$ $ $$$$ $ $$ $$$ $ $ $ $ $ $$ $$$$$ $ $$ $ $ $ $$ $ $$ $ $$ $ $ $ $$$$$$ $$ $$ $ $ $$$ $$ $$$$$$$ $ $ $$$$ $ $ $$$$$ $$$$$ $$ $ $$$$$ $$ $ $ $$$$$ $$$$$ $ $$ $ $$ $$$$ $$$ $ $ $ $$ $ $$$$ $ $$$ $$$$ $$$ $ $ $ $ $ $$ $$ $ $$$$$$ $$ $$ $ $$$ $ $ $ $$ $$ $ $$$$$ $$ $$ $ $ $$$$ $ $ $ $ $$$$ $$ $ $ $$$ $$ $ $ $ $$ $$ $ $$ $$$ $$ $$$$$ $$$ $ $$ $$ $ $$ $ $$ $$ $$ $ $$ $ $$ $ $$$$ $ $ $$ $ $ $$ $ $ $ $ $ $$ $ $ $$$ $ $$$ $$ $ $$$$$ $ $$$$ $ $ $$$$ $$ $$ $$ $$$ $$$ $ $$ $$ $ $$$ $ $$ $ $$ $$$ $$ $ $$ $$ $ $$ $ $$ $$ $ $ $ $$ $ $$ $$ $ $$ $ $ $$$ $ $ $$ $$ $ $$$$$ $$ $ $ $ $$$ $ $$ $$ $ $ $$$$ $ $ $ $$ $ $$$ $ $ $ $$ $$ $$$ $ $$ $ $ $ $$ $ $$ $$ $$ $ $$$ $$ $$ $ $$ $ $$ $ $$$$$$ $ $$$ $ $ $ $ $ $ $$ $ $$$$ $$$$ $ $$ $ $$$$ $ $$$ $ $$$ $$ $$ $$ $$$$ $ $ $$ $ $$ $$ $$ $ $$ $ $ $$ $$$ $ $$ $$ $ $ $ $$ $$$$ $ $ $ $ $ $$$$ $ $ $$ $ $ $ $$ $ $$$ $ $$ $ $$ $$ $$ $$ $ $$ $ $$$$$ $ $$ $$ $$$ $ $ $$$$ $$$$ $ $ $ $ $ $$ $ $ $$$ $ $$ $ $ $ $ $ $$ $ $$ $$ $$ $ $$$$$$ $$ $$$ $$$$$ $ $$ $ $$$$ $$$ $ $ $ $ $ $ $$$$$ $$ $ $$ $$$ $$ $ $ $$$ $ $ $$ $$$$$ $$ $$ $ $$$ $ $ $ $ $$ $ $$ $$ $ $ $ $$$$ $ $ $$$$ $ $$ $ $$$$$$$ $$$ $ $$ $ $$ $ $$ $ $$ $$ Rama Hoetzlein wrote: > Not sure I see how this would translate into a good 3D cluster > rendering test, considering that it is a 1D function with random > spatial characteristics (these equations are used as random number > generators i believe). While easy to explain, I'm not sure its easy to > predict or evaluate for initial testing. I like how the comparison > paper used Conway's "Game of Life", because its also easy to implement > and explain, plus, by rendering a simple sphere at every active cell it > is easy with that system to measure the expected bandwith. Also, with > Conway's game we could compare to what they already found. > > Rama > > Lance J. Putnam wrote: > >> Hello, >> >> I just had an idea for a pilot application using Mint that I >> believe will challenge many aspects of the system and hopefully >> lead to some new insights. >> >> The idea is to interact with the following mathematical equation: >> >> x[n+1] = x[n] * c % 2^64 >> >> where x[0] != 0 and c is odd. >> >> This is the simplest and most elegant computational algorithm I >> have found that leads to highly complex output. It is a special >> case of what is known in mathematics as a multiplicative linear >> congruential generator. They have been extensively studied for >> pseudo-random number generation. >> >> In C, the algorithm would look something like this: >> >> unsigned long long x = 1; // intial value >> unsigned long long c = 3; // multiplier >> x *= c; // iterate... >> >> The challenge would be to develop some sort of intuition about the >> equation by perceiving it through visualization, sonification, and >> haptics and to control the perceptual mappings with physical >> sensing. >> >> The reason I like this idea is because it is really easy to explain >> to someone and its implications cross many disciplines. And also, >> because I think it's interesting. >> >> Comments? >> >> Lance >> > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From jkm at create.ucsb.edu Sat Jul 14 10:46:31 2007 From: jkm at create.ucsb.edu (JoAnn Kuchera-Morin) Date: Sat Jul 14 10:46:46 2007 Subject: [Tdg] Fwd: [Sphere] FW: [4eyes] CAVE Message-ID: <3e9946484801a53ad87571a89e9c8bef@create.ucsb.edu> Dear All, We have the opportunity to visit the new RECVEB lab in Psych Thursday morning at 10 AM. We need to rsvp soon so that they can plan. Please be in touch, If you email Andy directly, please cc me so that I know he has the information. Thanks, JoAnn Begin forwarded message: > From: Jim Blascovich > Date: July 13, 2007 3:21:55 PM PDT > To: JoAnn Kuchera-Morin > Cc: blascovi@psych.ucsb.edu, beall@psych.ucsb.edu > Subject: Re: [Sphere] FW: [4eyes] CAVE > > Dear Allosphere Colleagues, > > You are all invited to experience our immersive system in our new > quarters in our new building (Psychology East--Basement---use south > stairway) on Thursday morning, July 19th at 10am. I will be out of > town, but my co-Director, Andy Beall, will be here. Meet him at the > south stairway to the basement. > > In order that we can plan appropriately, please RSVP to Andy Beall > (beall@psych.ucsb.edu). > > Best, > > Jim Blascovich > > > > JoAnn Kuchera-Morin wrote: >> Hi Jim, >> >> Great idea to visit the new RECVEB, we definitely want to come by >> asap. One of the important things to consider regarding the >> Allosphere. It is a scientific instrument, like a large digital >> microscope hooked up to a super computer. The social interaction >> among people in this lab environment is like a laboratory where a >> group of people are interacting with a piece of equipment that is >> multi user. The device happens to be immersive, and the feeling of >> immersion has very much impact in the Allosphere, but it's really >> not an immersive environment per say. That's what I think is >> compelling about the possible interactions Allosphere could have with >> RECVEB, especially if we are networked together and passing data from >> one facility to another. Tying in the Sage Center and the brain data >> as well. >> >> Best, >> JoAnn >> >> On Jul 13, 2007, at 11:28 AM, Jim Blascovich wrote: >> >>> Hi Matt, >>> >>> I think your idea to have Allosphere people experience other >>> immersive systems is a good idea. I've been to several CAVEs and >>> basically agree with Xavier about the vertices, and also have >>> concerns about actual physical movement space, point of view, and, >>> at least in a single CAVE the possibility for social interaction. I >>> enjoyed my experience in the Allosphere but have doubts about >>> studying social interaction within it. >>> >>> RECVEB has just moved into its new quarters in the basement of the >>> new Psychology East building. I welcome Allosphere people to come >>> over to check out our immersive experience, which to date and for >>> our purposes is basically the best I have seen. >>> >>> Thanks, >>> >>> Jim Blascovich >>> >>> I don't know how many of such individuals have been through RECVEB's >>> immersive demos and experiments. . Matthew Turk wrote: >>>> Thanks for the comments. I think it's really helpful to the >>>> Allosphere >>>> effort to experience the best of other immersive environments and to >>>> therefore be better equipped to articulate the similarities and >>>> differences, >>>> and to best leverage the Allosphere's strengths. So visits like >>>> this are >>>> really valuable. (I'll have to check out "Soarin' Over California", >>>> which I >>>> haven't seen!) >>>> >>>> Matthew >>>> >>>> -----Original Message----- >>>> From: Xavier Amatriain [mailto:xavier@create.ucsb.edu] Sent: >>>> Friday, July 13, 2007 2:06 AM >>>> To: Matthew Turk >>>> Cc: sphere@create.ucsb.edu >>>> Subject: Re: [Sphere] FW: [4eyes] CAVE >>>> >>>> Hi Matthew, >>>> >>>> Comparing a finished installation that has been perfected >>>> throughout many years with the Allosphere, which is not even 25% >>>> functional >>>> is a hard exercise, especially for someone like Cha who has not >>>> seen the different configurations we have tried (such as 4 >>>> projectors, 2 on each side; >>>> a single projector covering the top hemisphere...). >>>> >>>> I agree that we are going to lose the "walk-around" illusion but, >>>> having been also in CAVEs I would dare to say that the Allosphere >>>> is going >>>> to be *more* immersive than the CAVE. >>>> >>>> We can't deny the effect of the bridge (I wish it wasn't there and >>>> people could be hung from above :) but that effect is lost whenever >>>> the user >>>> moves to one side of the bridge and looks over the railing (I >>>> insist this is the way to look at the data, not laying back on the >>>> opposite railing). Having >>>> top and bottom projection will improve this immersion and we have >>>> already had the chance to experience that in some tests. >>>> >>>> The *kind* of immersion in the Allosphere will be different but not >>>> worse. Think about how much immersion you can feel in a simple >>>> Planetarium with no stereo or wrap-around projection. Have you been >>>> in the "Soarin' over California" Disney attraction in the >>>> California Adventure park [1]? You get an amazing sense of >>>> immersion again without 3D projection and it is not even a >>>> hemisphere in this case. >>>> >>>> Also, I don't think using wands or similar devices to navigate in >>>> the CAVEs improves the immersive experience, not to mention the >>>> tracking >>>> devices. Wands are great to move objects and manipulate scenes but >>>> for navigation I believe we should explore new paradigms and in the >>>> case >>>> of the Allosphere they should take advantage of the uniqueness of >>>> the space. >>>> >>>> I am surprised not to read any mention to the discontinuity problem >>>> in the corners of the CAVE, I have always felt that is a limiting >>>> factor in the >>>> sense of immersion in anything beyond the catchy wrap-around demos. >>>> >>>> I agree the Allosphere should not try to replicate CAVE's, among >>>> other things because these have not been so successful either and I >>>> believe this >>>> has never been in the roadmap. >>>> >>>> The way the bridge was designed is not ideal because of many >>>> factors related to cost, etc... and at some point it might need to >>>> be redesigned, >>>> but basing a report on this issue is missing many other issues that >>>> are hard to understand with the current set up. >>>> >>>> My 2c... >>>> >>>> [1] http://en.wikipedia.org/wiki/Soarin'_Over_California >>>> >>>> Matthew Turk wrote: >>>> >>>>> I thought I'd pass along Cha Lee's comments on a recent trip to >>>>> see a CAVE at UC Davis. >>>>> >>>>> Matthew >>>>> >>>>> ------------------------------------------------------------------- >>>>> ----- >>>>> >>>>> *From:* Cha Lee [mailto:chalee21@hotmail.com] >>>>> *Sent:* Wednesday, July 11, 2007 5:06 PM >>>>> *To:* mturk@cs.ucsb.edu >>>>> *Cc:* ilab@cs.ucsb.edu >>>>> *Subject:* RE: [4eyes] CAVE >>>>> >>>>> Hey Matthew, >>>>> >>>>> Brent and I specifically went to UC Davis to look at their CAVE to >>>>> get ideas for the Allosphere. >>>>> >>>>> 1) My immediate impressions were that the CAVE is going to be more >>>>> immersive than the Allosphere. In the CAVE, when well done, the >>>>> illusion is almost perfect. The Allosphere has the walkway which I >>>>> believe will distract observers from believing they co-exist in >>>>> the virtual environment. >>>>> >>>>> 2) For close interaction, I also believe the CAVE has a huge >>>>> advantage. Users can use an input device such as a wand to >>>>> navigate and interact with objects, OR walk around the objects. >>>>> Again the Allosphere is limited by the walkway. I found that >>>>> walking around is both intuitive in interaction and immersiveness. >>>>> Tasks such as examining medium sized objects, manipulating them, >>>>> and working with something in front of you is well suited for a >>>>> CAVE. >>>>> >>>>> 3) The Allosphere's advantage lies in its size, shape, and >>>>> resolution. We should exploit this. The resolution in the CAVE >>>>> wasn't that great and sometimes its size was limiting. this was >>>>> apparent when we were looking at a 3D map of california. >>>>> >>>>> My concern for the Allosphere right now is if it will be used >>>>> correctly. In my opinion, the walkway will be cumbersome and any >>>>> immersive application will have to take this into account. I'm >>>>> excited about the possibilities with visualization of large data >>>>> sets in the Allosphere though. If we can get it right, the >>>>> Allosphere will allow us to do things no else can. I don't believe >>>>> the Allosphere can replicate the CAVE in certain applications, and >>>>> we shouldn't try to make it one. >>>>> >>>>> -Cha >>>>> >>>>> ps: Live 3D video is FREAKING AWESOME! and kind of spooky. fyi: >>>>> project is based in Berkeley and Illinois. >>>>> >>>>> >>>>> >>>> -------------------------------------------------------------------- >>>> ---- >>>> >>>>> From: /"Matthew Turk" / >>>>> To: /"'Cha Lee'" / >>>>> CC: // >>>>> Subject: /RE: [4eyes] CAVE/ >>>>> Date: /Wed, 11 Jul 2007 14:56:34 -0700/ >>>>> >>>>> I wonder if you have thoughts about the relative >>>>> advantages/disadvantages of CAVE and Allosphere? >>>>> >>>>> Matthew >>>>> >>>>> >>>>> >>>> -------------------------------------------------------------------- >>>> ---- >>>> >>>>> *From:* ilab-users-bounces@lists.cs.ucsb.edu >>>>> [mailto:ilab-users-bounces@lists.cs.ucsb.edu] *On Behalf Of >>>>> *Cha Lee >>>>> *Sent:* Wednesday, July 11, 2007 12:17 PM >>>>> *To:* ilab@cs.ucsb.edu >>>>> *Subject:* [4eyes] CAVE >>>>> >>>>> I really encourage any of you who haven't seen a CAVE up front >>>>> to >>>>> see one. I was impressed by the immersiveness it produced, >>>>> besides >>>>> its other obvious uses. Just as a point, I'm not fond of >>>>> heights >>>>> and while using the system at UC Davis and running a Doom >>>>> simulation I was half scared of jumping off a ledge. When I >>>>> did, I >>>>> actually "felt" the gravity tugging on me while I was falling. >>>>> >>>>> Cool experience. >>>>> >>>>> -Cha >>>>> >>>>> ------------------------------------------------------------------- >>>>> ----- >>>>> >>>>> _______________________________________________ >>>>> Sphere mailing list >>>>> Sphere@create.ucsb.edu >>>>> http://www.create.ucsb.edu/mailman/listinfo/sphere >>>>> >>>> >>>> _______________________________________________ >>>> Sphere mailing list >>>> Sphere@create.ucsb.edu >>>> http://www.create.ucsb.edu/mailman/listinfo/sphere >>>> >>> >>> >>> _______________________________________________ >>> Sphere mailing list >>> Sphere@create.ucsb.edu >>> http://www.create.ucsb.edu/mailman/listinfo/sphere >>> >>> >> -- >> Dr. JoAnn Kuchera-Morin >> Director, Allosphere Research Laboratory >> Media Arts and Technology Initiatives, MAT-CNSI >> Media Arts and Technology, California Nanosystems Institute >> Professor, Graduate Program in Media Arts and Technology >> Professor of Composition, Department of Music >> Director, Center for Research in Electronic Art Technology >> University of California, Santa Barbara >> http://www.mat.ucsb.edu/allosphere >> http://www.mat.ucsb.edu >> http://www.create.ucsb.edu >> > > -- Dr. JoAnn Kuchera-Morin Director, Allosphere Research Laboratory Media Arts and Technology Initiatives, MAT-CNSI Media Arts and Technology, California Nanosystems Institute Professor, Graduate Program in Media Arts and Technology Professor of Composition, Department of Music Director, Center for Research in Electronic Art Technology University of California, Santa Barbara http://www.mat.ucsb.edu/allosphere http://www.mat.ucsb.edu http://www.create.ucsb.edu ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 11016 bytes Desc: not available Url : http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070714/1b8ee822/attachment-0001.bin From alex at neisis.net Sat Jul 14 13:17:04 2007 From: alex at neisis.net (Alex Norman) Date: Sat Jul 14 13:17:16 2007 Subject: [Tdg] basic working scheduler Message-ID: <20070714201704.GA4821@silverninja.net> So I have the very basics of a scheduler working for posix compliant systems (or at least Linux systems). what I have is here: http://x37v.info/drop/scheduler.tar.gz I used boost to give some smart pointers, so you'll need boost's intrusive pointer header. (we can discuss the trade offs of boost pointers later, but I'm thinking that these intrusive_ptrs are really awesome). Obviously everything here (the interface, etc) is up for debate, but I figured I'd send what I have so that we can start that discussion and move forward with the scheduler. I have separated out the "event_timer" from the rest because this itself could be useful in a lot of other projects [a cross platform event timer]. the "build" file shows you what I needed to build it on my machine, though there will definitely need to be changes for mac and windows. There are 2 platform specific things I think: 1) in the Time::now() function I call "gettimeofday", which, at least on linux boxes, has this signature: int gettimeofday(struct timeval *tv, struct timezone *tz); where struct timevals are: struct timeval { time_t tv_sec; /* seconds */ suseconds_t tv_usec; /* microseconds */ }; It looks like OsX provides that as well, but I figure we'll need a windows equivalent there. 2) The event timer, if someone would try to create the equivalent of the posix_event_timer for mac and windows that would be awesome. Basically we just need a timer that triggers at a regular interval [i am running it at its maximum resolution], we use this timer to wake ourselves up and check the schedule. btw, I've used (seconds, nanoseconds) for all of these functions, I most of the posix functions take seconds + nanoseconds so I just went with that. -Alex From wesley.hoke at gmail.com Sun Jul 15 09:09:27 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sun Jul 15 09:09:38 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <20070714201704.GA4821@silverninja.net> References: <20070714201704.GA4821@silverninja.net> Message-ID: <1079b050707150909q33986004o45665301f9fd3417@mail.gmail.com> I?ll take a stab at the OSX version today. wes On 7/14/07, Alex Norman wrote: > So I have the very basics of a scheduler working for posix compliant systems (or > at least Linux systems). > what I have is here: > http://x37v.info/drop/scheduler.tar.gz > > I used boost to give some smart pointers, so you'll need boost's intrusive > pointer header. (we can discuss the trade offs of boost pointers later, but I'm > thinking that these intrusive_ptrs are really awesome). > > Obviously everything here (the interface, etc) is up for debate, but I figured > I'd send what I have so that we can start that discussion and move forward with > the scheduler. > > I have separated out the "event_timer" from the rest because this itself could > be useful in a lot of other projects [a cross platform event timer]. > > the "build" file shows you what I needed to build it on my machine, though there > will definitely need to be changes for mac and windows. > > There are 2 platform specific things I think: > > 1) in the Time::now() function I call "gettimeofday", which, at least on linux > boxes, has this signature: > int gettimeofday(struct timeval *tv, struct timezone *tz); > where struct timevals are: > struct timeval { > time_t tv_sec; /* seconds */ > suseconds_t tv_usec; /* microseconds */ > }; > > It looks like OsX provides that as well, but I figure we'll need a windows > equivalent there. > > 2) The event timer, if someone would try to create the equivalent of the > posix_event_timer for mac and windows that would be awesome. > Basically we just need a timer that triggers at a regular interval [i am running > it at its maximum resolution], we use this timer to wake ourselves up and check > the schedule. > > btw, I've used (seconds, nanoseconds) for all of these functions, I most of the > posix functions take seconds + nanoseconds so I just went with that. > > -Alex > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From alex at neisis.net Sun Jul 15 11:15:09 2007 From: alex at neisis.net (Alex Norman) Date: Sun Jul 15 11:15:23 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <1079b050707150909q33986004o45665301f9fd3417@mail.gmail.com> References: <20070714201704.GA4821@silverninja.net> <1079b050707150909q33986004o45665301f9fd3417@mail.gmail.com> Message-ID: <20070715181509.GE4821@silverninja.net> Just so we don't lose our code I've added this stuff to the repo: mat/groups/tdg/svn/branches/scheduler so feel free to put your changes in there (I've already changed time slightly, though it doesn't actually change the functionality) once it is working I figure we'll merge it into the main mint "trunk" -Alex On 0, Wesley Smith wrote: > I?ll take a stab at the OSX version today. > > wes > > On 7/14/07, Alex Norman wrote: > >So I have the very basics of a scheduler working for posix compliant > >systems (or > >at least Linux systems). > >what I have is here: > >http://x37v.info/drop/scheduler.tar.gz > > > >I used boost to give some smart pointers, so you'll need boost's intrusive > >pointer header. (we can discuss the trade offs of boost pointers later, > >but I'm > >thinking that these intrusive_ptrs are really awesome). > > > >Obviously everything here (the interface, etc) is up for debate, but I > >figured > >I'd send what I have so that we can start that discussion and move forward > >with > >the scheduler. > > > >I have separated out the "event_timer" from the rest because this itself > >could > >be useful in a lot of other projects [a cross platform event timer]. > > > >the "build" file shows you what I needed to build it on my machine, though > >there > >will definitely need to be changes for mac and windows. > > > >There are 2 platform specific things I think: > > > >1) in the Time::now() function I call "gettimeofday", which, at least on > >linux > >boxes, has this signature: > >int gettimeofday(struct timeval *tv, struct timezone *tz); > >where struct timevals are: > > struct timeval { > > time_t tv_sec; /* seconds */ > > suseconds_t tv_usec; /* microseconds */ > > }; > > > >It looks like OsX provides that as well, but I figure we'll need a windows > >equivalent there. > > > >2) The event timer, if someone would try to create the equivalent of the > >posix_event_timer for mac and windows that would be awesome. > >Basically we just need a timer that triggers at a regular interval [i am > >running > >it at its maximum resolution], we use this timer to wake ourselves up and > >check > >the schedule. > > > >btw, I've used (seconds, nanoseconds) for all of these functions, I most > >of the > >posix functions take seconds + nanoseconds so I just went with that. > > > >-Alex > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Sun Jul 15 13:08:02 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Sun Jul 15 13:08:07 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <20070715181509.GE4821@silverninja.net> References: <20070714201704.GA4821@silverninja.net> <1079b050707150909q33986004o45665301f9fd3417@mail.gmail.com> <20070715181509.GE4821@silverninja.net> Message-ID: <469A7EA2.1080501@umail.ucsb.edu> Some comments and questions... - I noticed that Time::now creates and object and returns a TimePtr intrusive_ptr.. Perhps we can design this so that certain very general classes like Time don't require instrusive_ptrs (and don't create objects of themselves) as I would like to be able to use this general class anywhere with standard c pointers. Do you have to install the boost library to get intrusive_ptrs? I guess i'm raising the intrusive_ptr question. At the very least, I think we should put #ifdefs around the instrusive_ptr sections with the default being off for very generic classes people may want to use elsewhere. - Could we use a function pointer instead of a virtual function for the event_timer callback? (Or in addition to a virtual function?) This would allow users to create event_timers without having to write their own derived class. - The scheduler::run does an infinite loop. I'm confused.. On linux I thought we were going to have a timed OS-function callback to wake up the scheduler. Windows already has an inf. wake-up loop.. The scheduler won't be run in a seperate thread from the main thread, right? - I'd like to consider us using a modified-julian Time class (from GameX) for the representation of time in mint. It looks like it should be pretty easy to swap into the Time class. We can discuss this further. If there is a real reason, we can keep a second-nanosecond Time class around and supplement with a modified-julian Time class. However, this would result in a lot of type casting between the classes later... I'm am thinking forward to sending timestamps over the network, of measuring time across days, months. R Alex Norman wrote: >Just so we don't lose our code I've added this stuff to the repo: >mat/groups/tdg/svn/branches/scheduler > >so feel free to put your changes in there (I've already changed time slightly, >though it doesn't actually change the functionality) > >once it is working I figure we'll merge it into the main mint "trunk" > >-Alex > >On 0, Wesley Smith wrote: > > >>I?ll take a stab at the OSX version today. >> >>wes >> >>On 7/14/07, Alex Norman wrote: >> >> >>>So I have the very basics of a scheduler working for posix compliant >>>systems (or >>>at least Linux systems). >>>what I have is here: >>>http://x37v.info/drop/scheduler.tar.gz >>> >>>I used boost to give some smart pointers, so you'll need boost's intrusive >>>pointer header. (we can discuss the trade offs of boost pointers later, >>>but I'm >>>thinking that these intrusive_ptrs are really awesome). >>> >>>Obviously everything here (the interface, etc) is up for debate, but I >>>figured >>>I'd send what I have so that we can start that discussion and move forward >>>with >>>the scheduler. >>> >>>I have separated out the "event_timer" from the rest because this itself >>>could >>>be useful in a lot of other projects [a cross platform event timer]. >>> >>>the "build" file shows you what I needed to build it on my machine, though >>>there >>>will definitely need to be changes for mac and windows. >>> >>>There are 2 platform specific things I think: >>> >>>1) in the Time::now() function I call "gettimeofday", which, at least on >>>linux >>>boxes, has this signature: >>>int gettimeofday(struct timeval *tv, struct timezone *tz); >>>where struct timevals are: >>> struct timeval { >>> time_t tv_sec; /* seconds */ >>> suseconds_t tv_usec; /* microseconds */ >>> }; >>> >>>It looks like OsX provides that as well, but I figure we'll need a windows >>>equivalent there. >>> >>>2) The event timer, if someone would try to create the equivalent of the >>>posix_event_timer for mac and windows that would be awesome. >>>Basically we just need a timer that triggers at a regular interval [i am >>>running >>>it at its maximum resolution], we use this timer to wake ourselves up and >>>check >>>the schedule. >>> >>>btw, I've used (seconds, nanoseconds) for all of these functions, I most >>>of the >>>posix functions take seconds + nanoseconds so I just went with that. >>> >>>-Alex >>>_______________________________________________ >>>Tdg mailing list >>>Tdg@mat.ucsb.edu >>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >>> >>> >>> >>_______________________________________________ >>Tdg mailing list >>Tdg@mat.ucsb.edu >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> >> >_______________________________________________ >Tdg mailing list >Tdg@mat.ucsb.edu >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > From alex at neisis.net Sun Jul 15 14:17:16 2007 From: alex at neisis.net (Alex Norman) Date: Sun Jul 15 14:17:31 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <469A7EA2.1080501@umail.ucsb.edu> References: <20070714201704.GA4821@silverninja.net> <1079b050707150909q33986004o45665301f9fd3417@mail.gmail.com> <20070715181509.GE4821@silverninja.net> <469A7EA2.1080501@umail.ucsb.edu> Message-ID: <20070715211716.GG4821@silverninja.net> On 0, Rama Hoetzlein wrote: > Some comments and questions... > > - I noticed that Time::now creates and object and returns a TimePtr > intrusive_ptr.. Perhps we can design this so that certain very general > classes like Time don't require instrusive_ptrs (and don't create > objects of themselves) as I would like to be able to use this general > class anywhere with standard c pointers. Do you have to install the > boost library to get intrusive_ptrs? I guess i'm raising the > intrusive_ptr question. At the very least, I think we should put #ifdefs > around the instrusive_ptr sections with the default being off for very > generic classes people may want to use elsewhere. After reading your email and thinking about it for a second we can totally ditch intrusive_ptrs by making now() a non static function and just have it set a time to "now". Basically I like the idea of having a static function ::now() but as it would have to allocate memory I didn't want people to have to clean it up.. but if we just have a ::setNow() or something function that is non static then we're all set, so I'll do that in the next couple of hours. > > - Could we use a function pointer instead of a virtual function for the > event_timer callback? (Or in addition to a virtual function?) This would > allow users to create event_timers without having to write their own > derived class. writing a callback timer is super easy and I plan to have an example for the cross platform event timer library I intend to create [with the tdg group's help I hope]. Within mint there is really no point in having an "event_timer" once we have the scheduler, the scheduler can schedule events and users can use that to time things. [there is also a problem with only having a limited number of "signals" to work with, by default on Linux machines we're using the SIGRTMIN+3 signal. > > - The scheduler::run does an infinite loop. I'm confused.. On linux I > thought we were going to have a timed OS-function callback to wake up > the scheduler. Windows already has an inf. wake-up loop.. The scheduler > won't be run in a seperate thread from the main thread, right? well, the scheduler will run this infinite loop in its own thread, or maybe not.. we can talk about that, the infinite loop was just a way to get it to work for now :) .... the OS-function call back is the event_timer that I implemented (the OS signals us when the timer has expired, and we use that to wake up the scheduler (scheduler calls pause(), then after it wakes up it checks to see if the timer has ticked) > > - I'd like to consider us using a modified-julian Time class (from > GameX) for the representation of time in mint. It looks like it should > be pretty easy to swap into the Time class. We can discuss this further. > If there is a real reason, we can keep a second-nanosecond Time class > around and supplement with a modified-julian Time class. However, this > would result in a lot of type casting between the classes later... I'm > am thinking forward to sending timestamps over the network, of measuring > time across days, months. Yeah, I figured we'd probably make Time more complicated, but I do need to have seconds and nanoseconds in there.. maybe there should be a really simple "Time" like I have and a "DateTime" which is more complicated.. we can discuss this all further but we should have the ability to get the time of day quickly so we can do these comparisons for scheduling. -Alex > > R > > > Alex Norman wrote: > > >Just so we don't lose our code I've added this stuff to the repo: > >mat/groups/tdg/svn/branches/scheduler > > > >so feel free to put your changes in there (I've already changed time > >slightly, > >though it doesn't actually change the functionality) > > > >once it is working I figure we'll merge it into the main mint "trunk" > > > >-Alex > > > >On 0, Wesley Smith wrote: > > > > > >>I?ll take a stab at the OSX version today. > >> > >>wes > >> > >>On 7/14/07, Alex Norman wrote: > >> > >> > >>>So I have the very basics of a scheduler working for posix compliant > >>>systems (or > >>>at least Linux systems). > >>>what I have is here: > >>>http://x37v.info/drop/scheduler.tar.gz > >>> > >>>I used boost to give some smart pointers, so you'll need boost's > >>>intrusive > >>>pointer header. (we can discuss the trade offs of boost pointers later, > >>>but I'm > >>>thinking that these intrusive_ptrs are really awesome). > >>> > >>>Obviously everything here (the interface, etc) is up for debate, but I > >>>figured > >>>I'd send what I have so that we can start that discussion and move > >>>forward with > >>>the scheduler. > >>> > >>>I have separated out the "event_timer" from the rest because this itself > >>>could > >>>be useful in a lot of other projects [a cross platform event timer]. > >>> > >>>the "build" file shows you what I needed to build it on my machine, > >>>though there > >>>will definitely need to be changes for mac and windows. > >>> > >>>There are 2 platform specific things I think: > >>> > >>>1) in the Time::now() function I call "gettimeofday", which, at least on > >>>linux > >>>boxes, has this signature: > >>>int gettimeofday(struct timeval *tv, struct timezone *tz); > >>>where struct timevals are: > >>> struct timeval { > >>> time_t tv_sec; /* seconds */ > >>> suseconds_t tv_usec; /* microseconds */ > >>> }; > >>> > >>>It looks like OsX provides that as well, but I figure we'll need a > >>>windows > >>>equivalent there. > >>> > >>>2) The event timer, if someone would try to create the equivalent of the > >>>posix_event_timer for mac and windows that would be awesome. > >>>Basically we just need a timer that triggers at a regular interval [i am > >>>running > >>>it at its maximum resolution], we use this timer to wake ourselves up > >>>and check > >>>the schedule. > >>> > >>>btw, I've used (seconds, nanoseconds) for all of these functions, I most > >>>of the > >>>posix functions take seconds + nanoseconds so I just went with that. > >>> > >>>-Alex > >>>_______________________________________________ > >>>Tdg mailing list > >>>Tdg@mat.ucsb.edu > >>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > >>> > >>> > >>> > >>_______________________________________________ > >>Tdg mailing list > >>Tdg@mat.ucsb.edu > >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > >> > >> > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Sun Jul 15 16:11:37 2007 From: alex at neisis.net (Alex Norman) Date: Sun Jul 15 16:11:51 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <20070715211716.GG4821@silverninja.net> References: <20070714201704.GA4821@silverninja.net> <1079b050707150909q33986004o45665301f9fd3417@mail.gmail.com> <20070715181509.GE4821@silverninja.net> <469A7EA2.1080501@umail.ucsb.edu> <20070715211716.GG4821@silverninja.net> Message-ID: <20070715231137.GH4821@silverninja.net> okay, I've taken the intrusive_ptr out of Time, but it is still in the scheduler. I've committed my changes to the svn. It is not 100% necessary but I think they are really nice to work with, I think we should use them when we can.. basically, if you make your class a subclass of Object [which I have created] and then instead of using pointers you do: boost::intrusive_ptr blah; (or just typedef, as I have done... typedef boost::intrusive_ptr ScheduledFunctionPtr you can pass those around just as if they were pointers, you can cast them, etc [using boost's casting stuff], but you never have to deallocate them as they do reference counting internally [provided by the Object class that I created]. I assume installing boost is the easiest way to get this boost stuff, but you can probably just copy a couple of the header files as this stuff is all just templates. -Alex On 0, Alex Norman wrote: > On 0, Rama Hoetzlein wrote: > > Some comments and questions... > > > > - I noticed that Time::now creates and object and returns a TimePtr > > intrusive_ptr.. Perhps we can design this so that certain very general > > classes like Time don't require instrusive_ptrs (and don't create > > objects of themselves) as I would like to be able to use this general > > class anywhere with standard c pointers. Do you have to install the > > boost library to get intrusive_ptrs? I guess i'm raising the > > intrusive_ptr question. At the very least, I think we should put #ifdefs > > around the instrusive_ptr sections with the default being off for very > > generic classes people may want to use elsewhere. > > After reading your email and thinking about it for a second we can totally ditch > intrusive_ptrs by making now() a non static function and just have it set a time > to "now". Basically I like the idea of having a static function ::now() but as > it would have to allocate memory I didn't want people to have to clean it up.. > but if we just have a ::setNow() or something function that is non static then > we're all set, so I'll do that in the next couple of hours. > > > > > - Could we use a function pointer instead of a virtual function for the > > event_timer callback? (Or in addition to a virtual function?) This would > > allow users to create event_timers without having to write their own > > derived class. > > writing a callback timer is super easy and I plan to have an example for the > cross platform event timer library I intend to create [with the tdg group's help > I hope]. Within mint there is really no point in having an "event_timer" once > we have the scheduler, the scheduler can schedule events and users can use that > to time things. [there is also a problem with only having a limited number of > "signals" to work with, by default on Linux machines we're using the SIGRTMIN+3 > signal. > > > > > - The scheduler::run does an infinite loop. I'm confused.. On linux I > > thought we were going to have a timed OS-function callback to wake up > > the scheduler. Windows already has an inf. wake-up loop.. The scheduler > > won't be run in a seperate thread from the main thread, right? > > well, the scheduler will run this infinite loop in its own thread, or maybe > not.. we can talk about that, the infinite loop was just a way to get it to work > for now :) .... the OS-function call back is the event_timer that I implemented > (the OS signals us when the timer has expired, and we use that to wake up the > scheduler (scheduler calls pause(), then after it wakes up it checks to see if > the timer has ticked) > > > > > - I'd like to consider us using a modified-julian Time class (from > > GameX) for the representation of time in mint. It looks like it should > > be pretty easy to swap into the Time class. We can discuss this further. > > If there is a real reason, we can keep a second-nanosecond Time class > > around and supplement with a modified-julian Time class. However, this > > would result in a lot of type casting between the classes later... I'm > > am thinking forward to sending timestamps over the network, of measuring > > time across days, months. > > Yeah, I figured we'd probably make Time more complicated, but I do need to have > seconds and nanoseconds in there.. maybe there should be a really simple "Time" > like I have and a "DateTime" which is more complicated.. we can discuss this all > further but we should have the ability to get the time of day quickly so we can > do these comparisons for scheduling. > > -Alex > > > > > R > > > > > > Alex Norman wrote: > > > > >Just so we don't lose our code I've added this stuff to the repo: > > >mat/groups/tdg/svn/branches/scheduler > > > > > >so feel free to put your changes in there (I've already changed time > > >slightly, > > >though it doesn't actually change the functionality) > > > > > >once it is working I figure we'll merge it into the main mint "trunk" > > > > > >-Alex > > > > > >On 0, Wesley Smith wrote: > > > > > > > > >>I?ll take a stab at the OSX version today. > > >> > > >>wes > > >> > > >>On 7/14/07, Alex Norman wrote: > > >> > > >> > > >>>So I have the very basics of a scheduler working for posix compliant > > >>>systems (or > > >>>at least Linux systems). > > >>>what I have is here: > > >>>http://x37v.info/drop/scheduler.tar.gz > > >>> > > >>>I used boost to give some smart pointers, so you'll need boost's > > >>>intrusive > > >>>pointer header. (we can discuss the trade offs of boost pointers later, > > >>>but I'm > > >>>thinking that these intrusive_ptrs are really awesome). > > >>> > > >>>Obviously everything here (the interface, etc) is up for debate, but I > > >>>figured > > >>>I'd send what I have so that we can start that discussion and move > > >>>forward with > > >>>the scheduler. > > >>> > > >>>I have separated out the "event_timer" from the rest because this itself > > >>>could > > >>>be useful in a lot of other projects [a cross platform event timer]. > > >>> > > >>>the "build" file shows you what I needed to build it on my machine, > > >>>though there > > >>>will definitely need to be changes for mac and windows. > > >>> > > >>>There are 2 platform specific things I think: > > >>> > > >>>1) in the Time::now() function I call "gettimeofday", which, at least on > > >>>linux > > >>>boxes, has this signature: > > >>>int gettimeofday(struct timeval *tv, struct timezone *tz); > > >>>where struct timevals are: > > >>> struct timeval { > > >>> time_t tv_sec; /* seconds */ > > >>> suseconds_t tv_usec; /* microseconds */ > > >>> }; > > >>> > > >>>It looks like OsX provides that as well, but I figure we'll need a > > >>>windows > > >>>equivalent there. > > >>> > > >>>2) The event timer, if someone would try to create the equivalent of the > > >>>posix_event_timer for mac and windows that would be awesome. > > >>>Basically we just need a timer that triggers at a regular interval [i am > > >>>running > > >>>it at its maximum resolution], we use this timer to wake ourselves up > > >>>and check > > >>>the schedule. > > >>> > > >>>btw, I've used (seconds, nanoseconds) for all of these functions, I most > > >>>of the > > >>>posix functions take seconds + nanoseconds so I just went with that. > > >>> > > >>>-Alex > > >>>_______________________________________________ > > >>>Tdg mailing list > > >>>Tdg@mat.ucsb.edu > > >>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > >>> > > >>> > > >>> > > >>_______________________________________________ > > >>Tdg mailing list > > >>Tdg@mat.ucsb.edu > > >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > >> > > >> > > >_______________________________________________ > > >Tdg mailing list > > >Tdg@mat.ucsb.edu > > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > > > > > > > _______________________________________________ > > Tdg mailing list > > Tdg@mat.ucsb.edu > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Sun Jul 15 16:44:25 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sun Jul 15 16:44:33 2007 Subject: [Tdg] Graphics design In-Reply-To: <46945462.3070204@umail.ucsb.edu> References: <46928298.2080303@umail.ucsb.edu> <20070710180043.3tbwqhbysogc0sw8@webaccess.umail.ucsb.edu> <46945462.3070204@umail.ucsb.edu> Message-ID: <1079b050707151644x3678eeddy20ae39fc662f46a3@mail.gmail.com> Can you post the document as a PDF? I can't read excell documents. thanks, wes From rch at umail.ucsb.edu Sun Jul 15 16:52:33 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Sun Jul 15 16:52:38 2007 Subject: [Tdg] Graphics design Message-ID: <469AB341.9070805@umail.ucsb.edu> Ug.. Its a real pain to create PDFs from Excel spreadsheets. Isn't there an Excel viewer for Mac.. http://panergy.onerepublic.ws/icexcel-mac.html rama From wesley.hoke at gmail.com Sun Jul 15 17:07:38 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sun Jul 15 17:07:46 2007 Subject: [Tdg] Graphics design In-Reply-To: <469AB341.9070805@umail.ucsb.edu> References: <469AB341.9070805@umail.ucsb.edu> Message-ID: <1079b050707151707t6f7ae57bra2a630238d5fce7c@mail.gmail.com> can't you just print it and say "print to pdf" insted of sending it to an actual printer? wes On 7/16/07, Rama Hoetzlein wrote: > Ug.. Its a real pain to create PDFs from Excel spreadsheets. > Isn't there an Excel viewer for Mac.. > http://panergy.onerepublic.ws/icexcel-mac.html > > rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From rch at umail.ucsb.edu Sun Jul 15 17:08:34 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Sun Jul 15 17:08:39 2007 Subject: [Tdg] basic working scheduler Message-ID: <469AB702.10002@umail.ucsb.edu> What is Object? Is this like for "everything" in mint? Does this include user-created objects? While instrusive_ptrs seem useful, it seems rather restrictive to have users always work with these pointers instead of standard C pointers at such a high level. They look useful, so I think we should allow them.. I just don't think we should require people to use them on all objects. On the timing topic, what kind of accuracy are we going for with mint? Obviously, a periodic nanosecond event (and event that happens regularly every nanosecond) is going to be impossible on any system -- because, while you "might" be able to generate them that fast, no program could possibly handle events coming in that fast (the handling time would be longer than they are coming in). What is our goal for accurate periodic events? 1 ms? What kinds of guarantees do you get with Linux? Surely you can't wake a process every nanosecond. This is different from triggered event accuracy, which is how accurate +/-% a single-shot event is triggered. What is our goal for triggered event accuracy? It's not yet clear to me the best way to design the mint scheduler for Windows. The highest timer accuracy in Windows is 1 nanosecond, using QueryPerformanceTimer. This can be queried anytime your thread has control, so blocks of specific code can be timed to +/- nanosecond. The problem is you can't use the precision timer for thread control. In Windows, the highest thread wake-up accuracy is 1 ms... So, if you don't relinquish CPU, you get nanosecond event accuracy. If you do relinquish CPU, your periodic accuracy drops to 1 ms. If we go with the scheduler waking up every 1 ms, then not too challenging... There may be some tricks to play with threads that do better... I dunno: http://www.codeguru.com/cpp/w-p/system/timers/article.php/c5759/ -rama From wesley.hoke at gmail.com Sun Jul 15 17:19:49 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sun Jul 15 17:19:56 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <469AB702.10002@umail.ucsb.edu> References: <469AB702.10002@umail.ucsb.edu> Message-ID: <1079b050707151719p3c183d9fuc4dc5295b41d0b3b@mail.gmail.com> While we may not have thread control at the below millisecond level, we still want at least 1/44100 second timing accuracy of events. Systems (especially audio) will have a more accurate event processing system than app level control. wes On 7/16/07, Rama Hoetzlein wrote: > What is Object? Is this like for "everything" in mint? > Does this include user-created objects? > While instrusive_ptrs seem useful, it seems rather restrictive to have > users always work with these pointers instead of standard C pointers at > such a high level. They look useful, so I think we should allow them.. I > just don't think we should require people to use them on all objects. > > On the timing topic, what kind of accuracy are we going for with mint? > Obviously, a periodic nanosecond event (and event that happens regularly > every nanosecond) is going to be impossible on any system -- because, > while you "might" be able to generate them that fast, no program could > possibly handle events coming in that fast (the handling time would be > longer than they are coming in). What is our goal for accurate periodic > events? 1 ms? What kinds of guarantees do you get with Linux? Surely you > can't wake a process every nanosecond. > > This is different from triggered event accuracy, which is how accurate > +/-% a single-shot event is triggered. What is our goal for triggered > event accuracy? > > It's not yet clear to me the best way to design the mint scheduler for > Windows. The highest timer accuracy in Windows is 1 nanosecond, using > QueryPerformanceTimer. This can be queried anytime your thread has > control, so blocks of specific code can be timed to +/- nanosecond. The > problem is you can't use the precision timer for thread control. In > Windows, the highest thread wake-up accuracy is 1 ms... > > So, if you don't relinquish CPU, you get nanosecond event accuracy. If > you do relinquish CPU, your periodic accuracy drops to 1 ms. > If we go with the scheduler waking up every 1 ms, then not too > challenging... > There may be some tricks to play with threads that do better... I dunno: > http://www.codeguru.com/cpp/w-p/system/timers/article.php/c5759/ > > -rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From alex at neisis.net Sun Jul 15 17:29:16 2007 From: alex at neisis.net (Alex Norman) Date: Sun Jul 15 17:29:30 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <469AB702.10002@umail.ucsb.edu> References: <469AB702.10002@umail.ucsb.edu> Message-ID: <20070716002916.GJ4821@silverninja.net> On 0, Rama Hoetzlein wrote: > What is Object? Is this like for "everything" in mint? > Does this include user-created objects? > While instrusive_ptrs seem useful, it seems rather restrictive to have > users always work with these pointers instead of standard C pointers at > such a high level. They look useful, so I think we should allow them.. I > just don't think we should require people to use them on all objects. just because we use intrusive_ptrs doesn't mean you can't still create a Blah *. though for events I figure it is a good idea to use intrusive_ptrs instead of * for our functions, they make our interface easier to work with (and also make the "easy" interface easier).. I don't know what is so restrictive about this.... though, I figure we should talk to the rest of the people about this. just check out intrusive_ptr, my vote is for using them instead of * as much as we can and therefore having everything be a subclass of "Object". I like the idea of never calling delete and also not having memory leaks. > > On the timing topic, what kind of accuracy are we going for with mint? > Obviously, a periodic nanosecond event (and event that happens regularly > every nanosecond) is going to be impossible on any system -- because, > while you "might" be able to generate them that fast, no program could > possibly handle events coming in that fast (the handling time would be > longer than they are coming in). What is our goal for accurate periodic > events? 1 ms? What kinds of guarantees do you get with Linux? Surely you > can't wake a process every nanosecond. With linux you can "tune" your system to have various "wake up" accuracies. My system currently does 1ms but I might be able to get better, I'm not sure. We'll have to work with what the OSs can do, but yeah I figure 1ms is a good goal for periodic events. > > This is different from triggered event accuracy, which is how accurate > +/-% a single-shot event is triggered. What is our goal for triggered > event accuracy? > > It's not yet clear to me the best way to design the mint scheduler for > Windows. The highest timer accuracy in Windows is 1 nanosecond, using > QueryPerformanceTimer. This can be queried anytime your thread has > control, so blocks of specific code can be timed to +/- nanosecond. The > problem is you can't use the precision timer for thread control. In > Windows, the highest thread wake-up accuracy is 1 ms... > > So, if you don't relinquish CPU, you get nanosecond event accuracy. If > you do relinquish CPU, your periodic accuracy drops to 1 ms. > If we go with the scheduler waking up every 1 ms, then not too > challenging... > There may be some tricks to play with threads that do better... I dunno: > http://www.codeguru.com/cpp/w-p/system/timers/article.php/c5759/ With linux you can also get the time of day and have "nanosecond" accuracy, though I'm not sure if anything really is accurate to a nanosecond, but I don't like the idea of apps using 100% cpu ever, that is why I use this wake up timer. Earlier I told you about methods for getting more accurate timing by combining this "wake up" timer and a busy loop that checks the time.. basically if you know you want something to happen 2.5 ms from now you make you self wake up in 2 ms and then you do a busy loop for .5 ms.. Though I think for now, 1ms is pretty good. Functions (like graphics) can get the time of day to more accurately work with time, the audio callback has its own timing, I think we'll be fine.. -Alex > > -rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Sun Jul 15 17:33:59 2007 From: alex at neisis.net (Alex Norman) Date: Sun Jul 15 17:34:13 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <1079b050707151719p3c183d9fuc4dc5295b41d0b3b@mail.gmail.com> References: <469AB702.10002@umail.ucsb.edu> <1079b050707151719p3c183d9fuc4dc5295b41d0b3b@mail.gmail.com> Message-ID: <20070716003359.GK4821@silverninja.net> Well, this type of timing accuracy [at least for audio] can be achieved through timestamps, but I don't really see needing that type of accuracy for anything other than audio.. even if we're rendering graphics at 500 fps, that is 1 frame every 2ms. -Alex On 0, Wesley Smith wrote: > While we may not have thread control at the below millisecond level, > we still want at least 1/44100 second timing accuracy of events. > Systems (especially audio) will have a more accurate event processing > system than app level control. > > wes > > On 7/16/07, Rama Hoetzlein wrote: > >What is Object? Is this like for "everything" in mint? > >Does this include user-created objects? > >While instrusive_ptrs seem useful, it seems rather restrictive to have > >users always work with these pointers instead of standard C pointers at > >such a high level. They look useful, so I think we should allow them.. I > >just don't think we should require people to use them on all objects. > > > >On the timing topic, what kind of accuracy are we going for with mint? > >Obviously, a periodic nanosecond event (and event that happens regularly > >every nanosecond) is going to be impossible on any system -- because, > >while you "might" be able to generate them that fast, no program could > >possibly handle events coming in that fast (the handling time would be > >longer than they are coming in). What is our goal for accurate periodic > >events? 1 ms? What kinds of guarantees do you get with Linux? Surely you > >can't wake a process every nanosecond. > > > >This is different from triggered event accuracy, which is how accurate > >+/-% a single-shot event is triggered. What is our goal for triggered > >event accuracy? > > > >It's not yet clear to me the best way to design the mint scheduler for > >Windows. The highest timer accuracy in Windows is 1 nanosecond, using > >QueryPerformanceTimer. This can be queried anytime your thread has > >control, so blocks of specific code can be timed to +/- nanosecond. The > >problem is you can't use the precision timer for thread control. In > >Windows, the highest thread wake-up accuracy is 1 ms... > > > >So, if you don't relinquish CPU, you get nanosecond event accuracy. If > >you do relinquish CPU, your periodic accuracy drops to 1 ms. > >If we go with the scheduler waking up every 1 ms, then not too > >challenging... > >There may be some tricks to play with threads that do better... I dunno: > > http://www.codeguru.com/cpp/w-p/system/timers/article.php/c5759/ > > > >-rama > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Sun Jul 15 17:47:07 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sun Jul 15 17:47:15 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <20070716003359.GK4821@silverninja.net> References: <469AB702.10002@umail.ucsb.edu> <1079b050707151719p3c183d9fuc4dc5295b41d0b3b@mail.gmail.com> <20070716003359.GK4821@silverninja.net> Message-ID: <1079b050707151747r3290dfdej448e5fade0f70674@mail.gmail.com> Of course. The main scheduler will never run at > 1ms precision, but events should have much more accurate timestaps. wes On 7/16/07, Alex Norman wrote: > Well, this type of timing accuracy [at least for audio] can be achieved through > timestamps, but I don't really see needing that type of accuracy for anything > other than audio.. even if we're rendering graphics at 500 fps, that is 1 frame > every 2ms. > > -Alex > > On 0, Wesley Smith wrote: > > While we may not have thread control at the below millisecond level, > > we still want at least 1/44100 second timing accuracy of events. > > Systems (especially audio) will have a more accurate event processing > > system than app level control. > > > > wes > > > > On 7/16/07, Rama Hoetzlein wrote: > > >What is Object? Is this like for "everything" in mint? > > >Does this include user-created objects? > > >While instrusive_ptrs seem useful, it seems rather restrictive to have > > >users always work with these pointers instead of standard C pointers at > > >such a high level. They look useful, so I think we should allow them.. I > > >just don't think we should require people to use them on all objects. > > > > > >On the timing topic, what kind of accuracy are we going for with mint? > > >Obviously, a periodic nanosecond event (and event that happens regularly > > >every nanosecond) is going to be impossible on any system -- because, > > >while you "might" be able to generate them that fast, no program could > > >possibly handle events coming in that fast (the handling time would be > > >longer than they are coming in). What is our goal for accurate periodic > > >events? 1 ms? What kinds of guarantees do you get with Linux? Surely you > > >can't wake a process every nanosecond. > > > > > >This is different from triggered event accuracy, which is how accurate > > >+/-% a single-shot event is triggered. What is our goal for triggered > > >event accuracy? > > > > > >It's not yet clear to me the best way to design the mint scheduler for > > >Windows. The highest timer accuracy in Windows is 1 nanosecond, using > > >QueryPerformanceTimer. This can be queried anytime your thread has > > >control, so blocks of specific code can be timed to +/- nanosecond. The > > >problem is you can't use the precision timer for thread control. In > > >Windows, the highest thread wake-up accuracy is 1 ms... > > > > > >So, if you don't relinquish CPU, you get nanosecond event accuracy. If > > >you do relinquish CPU, your periodic accuracy drops to 1 ms. > > >If we go with the scheduler waking up every 1 ms, then not too > > >challenging... > > >There may be some tricks to play with threads that do better... I dunno: > > > http://www.codeguru.com/cpp/w-p/system/timers/article.php/c5759/ > > > > > >-rama > > >_______________________________________________ > > >Tdg mailing list > > >Tdg@mat.ucsb.edu > > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > > _______________________________________________ > > Tdg mailing list > > Tdg@mat.ucsb.edu > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From rch at umail.ucsb.edu Sun Jul 15 17:58:12 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Sun Jul 15 17:58:19 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <20070716002916.GJ4821@silverninja.net> References: <469AB702.10002@umail.ucsb.edu> <20070716002916.GJ4821@silverninja.net> Message-ID: <469AC2A4.7020603@umail.ucsb.edu> > >just because we use intrusive_ptrs doesn't mean you can't still create a Blah *. >though for events I figure it is a good idea to use intrusive_ptrs instead of * >for our functions, they make our interface easier to work with (and also make >the "easy" interface easier).. I don't know what is so restrictive about >this.... though, I figure we should talk to the rest of the people about this. >just check out intrusive_ptr, my vote is for using them instead of * as much as >we can and therefore having everything be a subclass of "Object". I like the >idea of never calling delete and also not having memory leaks. > > It sounds like you're suggesting all future system and user events requiring intrusive_ptrs. This means all users would have to adopt intrusive_ptrs if they want to work with the events they created. Even in their own seperate programs? Can you still just use a regular C pointer on them regardless? Does this add data to an event object? I thought we had already settled on an Event class design? How do intrusive_ptrs work? It seems in certain circumstances there might be a performance loss (e.g. you have a block of 100 events in a memory pool, just delete the whole block once). Overall, I'd like to hear more about the design impacts and discussion of intrusive_ptrs before we might adopt them.. Seems this might play a part in the memory pool design too. >With linux you can also get the time of day and have "nanosecond" accuracy, >though I'm not sure if anything really is accurate to a nanosecond, but I don't >like the idea of apps using 100% cpu ever, that is why I use this wake up timer. >Earlier I told you about methods for getting more accurate timing by combining >this "wake up" timer and a busy loop that checks the time.. basically if you >know you want something to happen 2.5 ms from now you make you self wake up in 2 >ms and then you do a busy loop for .5 ms.. Though I think for now, 1ms is >pretty good. Functions (like graphics) can get the time of day to more >accurately work with time, the audio callback has its own timing, I think we'll >be fine.. > > I like this design.. That would give you a periodic accuracy of 1 ms, and a triggered accuracy of ~nanoseconds. You basically sleep in 1 ms chunks. The only consequence is, to still relinquish CPU you could never do a <1 ms periodic event without having some dropped events somewhere. Assuming a thread control accuracy of 1 ms, I don't think there is any way around this though... The simple version, ~1 ms, sound like a good start. R >-Alex > > > >>-rama >>_______________________________________________ >>Tdg mailing list >>Tdg@mat.ucsb.edu >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> >> >_______________________________________________ >Tdg mailing list >Tdg@mat.ucsb.edu >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > From alex at neisis.net Sun Jul 15 18:57:30 2007 From: alex at neisis.net (Alex Norman) Date: Sun Jul 15 18:57:43 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <469AC2A4.7020603@umail.ucsb.edu> References: <469AB702.10002@umail.ucsb.edu> <20070716002916.GJ4821@silverninja.net> <469AC2A4.7020603@umail.ucsb.edu> Message-ID: <20070716015730.GL4821@silverninja.net> On 0, Rama Hoetzlein wrote: > > > > >just because we use intrusive_ptrs doesn't mean you can't still create a > >Blah *. > >though for events I figure it is a good idea to use intrusive_ptrs instead > >of * > >for our functions, they make our interface easier to work with (and also > >make > >the "easy" interface easier).. I don't know what is so restrictive about > >this.... though, I figure we should talk to the rest of the people about > >this. > >just check out intrusive_ptr, my vote is for using them instead of * as > >much as > >we can and therefore having everything be a subclass of "Object". I like > >the > >idea of never calling delete and also not having memory leaks. > > > > > It sounds like you're suggesting all future system and user events > requiring intrusive_ptrs. I'm suggesting that we talk about it, I think it'll be a good idea. These intrusive_ptrs do not affect memory allocation, you still use new, and delete is still called when objects fall out of scope for the last time, they really just affect memory deallocation. > This means all users would have to adopt > intrusive_ptrs if they want to work with the events they created. Even > in their own seperate programs? Can you still just use a regular C > pointer on them regardless? Does this add data to an event object? there is a reference count in the object class, so, there is an extra int per object. I don't know what you mean "use a regular C pointer on them", they replace C pointers, yes, you can create an Object *, but our functions can either except Object * or ObjectPtrs or both, we have to decide that. I've used other libraries that provide reference counting and so they don't accept normal "c pointers". Basically, using these intrusive_ptrs (which are just a type of "smart pointer" btw) makes our programming job (memory management) easier, though we have to think about synchronization [though maybe we can use volatile sig_atomic_t?] > I > thought we had already settled on an Event class design? How do intrusive_ptrs > work? It seems in certain circumstances there might be a performance loss > (e.g. you have a block of 100 events in a memory pool, just delete the whole > block once). Overall, I'd like to hear more about the design impacts and > discussion of intrusive_ptrs before we might adopt them.. Seems this might > play a part in the memory pool design too. Basically, instead of allocating data and assigning it to a Blah * you assign it to a boost::intrusive_ptr x, and instead of passing around Blah * you pass around boost::intrusive_ptr. every time a variable of type boost::intrusive_ptr points to some data it increments the reference associated with that data. Every time that variable falls out of scope (ie the block ends), the reference count is decremented.. once it reaches zero the memory is deallocated [or in our case would probably be put back into the associated memory pool]. Anyways, I figure these are worth a discussion, I like them, I'm going to be using them or some other smart pointer instead of c pointers as much as I can in my own projects in the future.. but if other people in the mint group aren't into them then that is fine.. I can change the scheduler easily, but I think you all should really check them out. > I like this design.. That would give you a periodic accuracy of 1 ms, > and a triggered accuracy of ~nanoseconds. You basically sleep in 1 ms > chunks. The only consequence is, to still relinquish CPU you could never > do a <1 ms periodic event without having some dropped events somewhere. > Assuming a thread control accuracy of 1 ms, I don't think there is any > way around this though... The simple version, ~1 ms, sound like a good > start. yeah, I figure the simple version is good for now and will get us going, if we find that we need something more hardcore we'll change things up then. -Alex From wesley.hoke at gmail.com Sun Jul 15 19:12:05 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sun Jul 15 19:12:13 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <20070716015730.GL4821@silverninja.net> References: <469AB702.10002@umail.ucsb.edu> <20070716002916.GJ4821@silverninja.net> <469AC2A4.7020603@umail.ucsb.edu> <20070716015730.GL4821@silverninja.net> Message-ID: <1079b050707151912n4c09afd8q770d6b8074279a01@mail.gmail.com> Are you suggesting using them for memory management with events? wes On 7/16/07, Alex Norman wrote: > On 0, Rama Hoetzlein wrote: > > > > > > > >just because we use intrusive_ptrs doesn't mean you can't still create a > > >Blah *. > > >though for events I figure it is a good idea to use intrusive_ptrs instead > > >of * > > >for our functions, they make our interface easier to work with (and also > > >make > > >the "easy" interface easier).. I don't know what is so restrictive about > > >this.... though, I figure we should talk to the rest of the people about > > >this. > > >just check out intrusive_ptr, my vote is for using them instead of * as > > >much as > > >we can and therefore having everything be a subclass of "Object". I like > > >the > > >idea of never calling delete and also not having memory leaks. > > > > > > > > It sounds like you're suggesting all future system and user events > > requiring intrusive_ptrs. > > I'm suggesting that we talk about it, I think it'll be a good idea. > > These intrusive_ptrs do not affect memory allocation, you still use new, and > delete is still called when objects fall out of scope for the last time, they > really just affect memory deallocation. > > > This means all users would have to adopt > > intrusive_ptrs if they want to work with the events they created. Even > > in their own seperate programs? Can you still just use a regular C > > pointer on them regardless? Does this add data to an event object? > > there is a reference count in the object class, so, there is an extra int per > object. > I don't know what you mean "use a regular C pointer on them", they replace C > pointers, yes, you can create an Object *, but our functions can either except > Object * or ObjectPtrs or both, we have to decide that. > I've used other libraries that provide reference counting and so they don't > accept normal "c pointers". > Basically, using these intrusive_ptrs (which are just a type of "smart pointer" > btw) makes our programming job (memory management) easier, though we have to > think about synchronization [though maybe we can use volatile sig_atomic_t?] > > > I > > thought we had already settled on an Event class design? How do intrusive_ptrs > > work? It seems in certain circumstances there might be a performance loss > > (e.g. you have a block of 100 events in a memory pool, just delete the whole > > block once). Overall, I'd like to hear more about the design impacts and > > discussion of intrusive_ptrs before we might adopt them.. Seems this might > > play a part in the memory pool design too. > > Basically, instead of allocating data and assigning it to a Blah * you assign it > to a boost::intrusive_ptr x, and instead of passing around Blah * you pass > around boost::intrusive_ptr. > every time a variable of type boost::intrusive_ptr points to some data it > increments the reference associated with that data. Every time that variable > falls out of scope (ie the block ends), the reference count is decremented.. > once it reaches zero the memory is deallocated [or in our case would probably be > put back into the associated memory pool]. > > Anyways, I figure these are worth a discussion, I like them, I'm going to be > using them or some other smart pointer instead of c pointers as much as I can in > my own projects in the future.. but if other people in the mint group aren't > into them then that is fine.. I can change the scheduler easily, but I think you > all should really check them out. > > > I like this design.. That would give you a periodic accuracy of 1 ms, > > and a triggered accuracy of ~nanoseconds. You basically sleep in 1 ms > > chunks. The only consequence is, to still relinquish CPU you could never > > do a <1 ms periodic event without having some dropped events somewhere. > > Assuming a thread control accuracy of 1 ms, I don't think there is any > > way around this though... The simple version, ~1 ms, sound like a good > > start. > > yeah, I figure the simple version is good for now and will get us going, if we > find that we need something more hardcore we'll change things up then. > > -Alex > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From alex at neisis.net Sun Jul 15 19:18:38 2007 From: alex at neisis.net (Alex Norman) Date: Sun Jul 15 19:18:50 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <1079b050707151912n4c09afd8q770d6b8074279a01@mail.gmail.com> References: <469AB702.10002@umail.ucsb.edu> <20070716002916.GJ4821@silverninja.net> <469AC2A4.7020603@umail.ucsb.edu> <20070716015730.GL4821@silverninja.net> <1079b050707151912n4c09afd8q770d6b8074279a01@mail.gmail.com> Message-ID: <20070716021838.GM4821@silverninja.net> I am suggestion that we consider it, yes. -Alex On 0, Wesley Smith wrote: > Are you suggesting using them for memory management with events? > > wes > > On 7/16/07, Alex Norman wrote: > >On 0, Rama Hoetzlein wrote: > >> > >> > > >> >just because we use intrusive_ptrs doesn't mean you can't still create a > >> >Blah *. > >> >though for events I figure it is a good idea to use intrusive_ptrs > >instead > >> >of * > >> >for our functions, they make our interface easier to work with (and also > >> >make > >> >the "easy" interface easier).. I don't know what is so restrictive about > >> >this.... though, I figure we should talk to the rest of the people about > >> >this. > >> >just check out intrusive_ptr, my vote is for using them instead of * as > >> >much as > >> >we can and therefore having everything be a subclass of "Object". I > >like > >> >the > >> >idea of never calling delete and also not having memory leaks. > >> > > >> > > >> It sounds like you're suggesting all future system and user events > >> requiring intrusive_ptrs. > > > >I'm suggesting that we talk about it, I think it'll be a good idea. > > > >These intrusive_ptrs do not affect memory allocation, you still use new, > >and > >delete is still called when objects fall out of scope for the last time, > >they > >really just affect memory deallocation. > > > >> This means all users would have to adopt > >> intrusive_ptrs if they want to work with the events they created. Even > >> in their own seperate programs? Can you still just use a regular C > >> pointer on them regardless? Does this add data to an event object? > > > >there is a reference count in the object class, so, there is an extra int > >per > >object. > >I don't know what you mean "use a regular C pointer on them", they replace > >C > >pointers, yes, you can create an Object *, but our functions can either > >except > >Object * or ObjectPtrs or both, we have to decide that. > >I've used other libraries that provide reference counting and so they don't > >accept normal "c pointers". > >Basically, using these intrusive_ptrs (which are just a type of "smart > >pointer" > >btw) makes our programming job (memory management) easier, though we have > >to > >think about synchronization [though maybe we can use volatile > >sig_atomic_t?] > > > >> I > >> thought we had already settled on an Event class design? How do > >intrusive_ptrs > >> work? It seems in certain circumstances there might be a performance loss > >> (e.g. you have a block of 100 events in a memory pool, just delete the > >whole > >> block once). Overall, I'd like to hear more about the design impacts and > >> discussion of intrusive_ptrs before we might adopt them.. Seems this > >might > >> play a part in the memory pool design too. > > > >Basically, instead of allocating data and assigning it to a Blah * you > >assign it > >to a boost::intrusive_ptr x, and instead of passing around Blah * > >you pass > >around boost::intrusive_ptr. > >every time a variable of type boost::intrusive_ptr points to some > >data it > >increments the reference associated with that data. Every time that > >variable > >falls out of scope (ie the block ends), the reference count is > >decremented.. > >once it reaches zero the memory is deallocated [or in our case would > >probably be > >put back into the associated memory pool]. > > > >Anyways, I figure these are worth a discussion, I like them, I'm going to > >be > >using them or some other smart pointer instead of c pointers as much as I > >can in > >my own projects in the future.. but if other people in the mint group > >aren't > >into them then that is fine.. I can change the scheduler easily, but I > >think you > >all should really check them out. > > > >> I like this design.. That would give you a periodic accuracy of 1 ms, > >> and a triggered accuracy of ~nanoseconds. You basically sleep in 1 ms > >> chunks. The only consequence is, to still relinquish CPU you could never > >> do a <1 ms periodic event without having some dropped events somewhere. > >> Assuming a thread control accuracy of 1 ms, I don't think there is any > >> way around this though... The simple version, ~1 ms, sound like a good > >> start. > > > >yeah, I figure the simple version is good for now and will get us going, > >if we > >find that we need something more hardcore we'll change things up then. > > > >-Alex > > > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Sun Jul 15 19:25:34 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sun Jul 15 19:25:41 2007 Subject: [Tdg] basic working scheduler In-Reply-To: <20070716021838.GM4821@silverninja.net> References: <469AB702.10002@umail.ucsb.edu> <20070716002916.GJ4821@silverninja.net> <469AC2A4.7020603@umail.ucsb.edu> <20070716015730.GL4821@silverninja.net> <1079b050707151912n4c09afd8q770d6b8074279a01@mail.gmail.com> <20070716021838.GM4821@silverninja.net> Message-ID: <1079b050707151925p7608aa87s568fd6dd2d1ef437@mail.gmail.com> Are there any threading issues with intrusive_ptrs? wes On 7/16/07, Alex Norman wrote: > I am suggestion that we consider it, yes. > > -Alex > > On 0, Wesley Smith wrote: > > Are you suggesting using them for memory management with events? > > > > wes > > > > On 7/16/07, Alex Norman wrote: > > >On 0, Rama Hoetzlein wrote: > > >> > > >> > > > >> >just because we use intrusive_ptrs doesn't mean you can't still create a > > >> >Blah *. > > >> >though for events I figure it is a good idea to use intrusive_ptrs > > >instead > > >> >of * > > >> >for our functions, they make our interface easier to work with (and also > > >> >make > > >> >the "easy" interface easier).. I don't know what is so restrictive about > > >> >this.... though, I figure we should talk to the rest of the people about > > >> >this. > > >> >just check out intrusive_ptr, my vote is for using them instead of * as > > >> >much as > > >> >we can and therefore having everything be a subclass of "Object". I > > >like > > >> >the > > >> >idea of never calling delete and also not having memory leaks. > > >> > > > >> > > > >> It sounds like you're suggesting all future system and user events > > >> requiring intrusive_ptrs. > > > > > >I'm suggesting that we talk about it, I think it'll be a good idea. > > > > > >These intrusive_ptrs do not affect memory allocation, you still use new, > > >and > > >delete is still called when objects fall out of scope fo